I can’t access my Apple TV at the moment to test, but are you getting multiple “Up” phases during the swipe? Or is it a series of “Down”'s followed by one “Up”?
Rob
Hi Rob,
I just tested with 2795 after updating my device to tvOS 9.1, and the issue is still the same as described at the top:
When I e.g. swipe DOWN:
Dec 6 23:19:56 Apple-TV KeyTest[180] <Warning>: keyName: right
Dec 6 23:19:56 Apple-TV KeyTest[180] <Warning>: keyName: down
or
Dec 6 23:22:28 Apple-TV KeyTest[180] <Warning>: keyName: left
Dec 6 23:22:28 Apple-TV KeyTest[180] <Warning>: keyName: down
or
Dec 6 23:21:45 Apple-TV KeyTest[180] <Warning>: keyName: right
Dec 6 23:21:45 Apple-TV KeyTest[180] <Warning>: keyName: down
Dec 6 23:21:45 Apple-TV KeyTest[180] <Warning>: keyName: left
So I get the main direction “down”, accompanied by a “left” or “right” or even both - these are the variations of my downswipe, so if I swipe down and slightly to the left I get an additional “left”, if i swipe a little bit to the right I get an additional “right”. Or even both.
It is of course impossible to swipe exactly down. 
I guess these variations of the main swipe direction should be filtered out.
Best
Andreas
What I did was ignore left and right. I’m only paying attention to up and down.
Rob
Hi Rob,
Yes, but that won’t work for me or any games that e.g. use a 5x5 grid to select one of 25 levels for a world, like in “Where’s my Water” or “Freeze!”, to name just two great examples in one sentence. 
The Apple guidelines state that it’s not enough to just walk sequentially through all levels in a screen like this, the user must be able to navigate freely up, down, left right.
But for this I will just wait till it is fixed, got enough other things still to do to convert the game for tvOS.
Best
Andreas
Hi Michael,
I was quite happy when I saw the daily build notes for .2796:
- tvOS: Removing directional key events.
Well, and then, when I tested it (with .2796 up to .2799) I saw that this was meant literally:
Not only the wrong additional directional key events for each swipe were removed, you removed all directional key events, the only events I get reported now are “buttonA”, “buttonX” and “menu”.
Ok, this certainly takes care of the bug in a way, there are no multiple key events anymore.
But I was hoping for something more like a fix, so if the user swipes to the right we get back a “right” key event, nothing more, nothing less.
But enough said, hope you have a nice christmas vacation and maybe tackle this problem in January.
Best
Andreas
We removed it until we could come back and implement it correctly.
For now, please look at axis events.You can look at these values and write a lua wrapper to synthesize your own up/down/left/right events.
Damn, now the navigation in my app is broken.
It was a very convenient feature imho.
Any idea when we can expect this to return?
Cheers,
Tommy
I don’t have an ETA. Perhaps I should do a tutorial on using axis events to make your own key events that lets you adjust the sensitivity of what triggers an event until we can get something more formal from engineering.
Or if you’re not needing a specific feature of a daily build, don’t update yet.
Rob
Hey, you removed a key feature! 
[Sorry, as a German I couldn’t resist the pun.]
Certainly there is the workaround to look for the swipes myself by interpreting the axis events. And I guess I will do that for the next time. And yes, a tutorial would always be welcome, will save me some time.
But in the released game I would like to have support for the original keys returned by tvOS. The users will be used to them and it will not be possible to emulate the exact feeling of the swipes with your own custom implementation.
Thanks and best
Andreas
[EDIT: Strange, whenever I post something using my iPad Air and Safari after posting all line breaks are removed. When I edit the post again all line breaks are still there, they just disappear when the post is published.]
[EDIT 2: Even stranger, after I edited the post and added the first EDIT and published the post now all line breaks show up. Feel free to test.]
Thanks for bringing up the forum line breaks issue. I thought it was just me.
It seems to happen when using the mobile theme, regardless of the browser used.
I’ll pass this on to the web guys.
Merry Christmas, and best of luck with Freeze 2
Such a tutorial would be much appreciated, thanks
Cheers
Agreed.
local resetAt0 = true local function onAxis(event) if #objects \< 1 or not event.axis or event.axis.type~='y' then return end if resetAt0 and event.normalizedValue ~= 0 then return end resetAt0 = false if not rect then focusedObject = 1 createFocusedRect(objects[focusedObject]) end local dy = event.normalizedValue rect.y = objects[focusedObject].y + dy\*rect.height\*0.3 if math.abs(dy) \> 0.5 then if dy \> 0 and focusedObject \< #objects then shiftedThisEvent = true focusedObject = focusedObject + 1 createFocusedRect(objects[focusedObject]) end if dy \< 0 and focusedObject \> 1 then shiftedThisEvent = true focusedObject = focusedObject - 1 createFocusedRect(objects[focusedObject]) end resetAt0 = true end end
This code was taken from an internal test app, so it’s not production code. “objects” is an array of the items to toggle between. createFocusedRect() is a function that simply creates a hollow rectangle around the object that’s selected. You would show your selected buttons in whatever makes sense for your app. “focusedObject” is just the index of the currently selected item. This sample only does the Y axis. But you could style X axis processing off of this.
In the mean time, I’ll try to put this into some self-contained function, but this is pretty easy to implement.
Rob
Looking forward to this Rob. I’m currently in the middle of a project, which is on hold until this key event thing can get sorted out.
I’m not sure how successful a stand alone function will be actually. The above works pretty good. I dropped it into my app and adjusted it for my table of objects and how I track them and it manage the previous button state.
Rob
Hi all,
right now (daily build 2016.2818) there are no key events for directions “up”, “down”, “left”, “right” dispatched if you listen for the Apple TV remote keys using:
Runtime:addEventListener( “key”, onRemoteKeyEvents )
If you still would like to have the direction keys when the user swipes on the little touchpad just drop the code below into your project. It detects swipes and dispatches the missing key events.
Many thanks to Rob for his code snippet from above!
Best
Andreas
local resetAt0 = true local function onAxisEvent( event ) local mappedEvent = { name = "key", phase = "down", keyName = "" } local delta = event.normalizedValue if not event.axis or (event.axis.type ~= 'y' and event.axis.type ~= 'x') then return end if resetAt0 and delta ~= 0 then return end resetAt0 = false if math.abs(delta) \> 0.5 then if event.axis.type == "x" then if delta \< 0 then mappedEvent.keyName = "left" elseif delta \> 0 then mappedEvent.keyName = "right" end elseif event.axis.type == "y" then if delta \< 0 then mappedEvent.keyName = "up" elseif delta \> 0 then mappedEvent.keyName = "down" end end resetAt0 = true end if mappedEvent.keyName ~= "" then Runtime:dispatchEvent( mappedEvent ) print( "DISPATCHED: " .. mappedEvent.keyName ) end end Runtime:addEventListener( "axis", onAxisEvent )Nice!
Just one word of caution:
Whoever uses this workaround needs to pay close attention to the fixes done by Coronalabs:
As soon as the normal key behavior is fixed and the system key events are thrown again for up / down / left / right you then will get all directions twice - you then need to take out my temporary fix.
A permanent solution would be to change the custom keys thrown to “customUp”, “customDown”, “customRight” and “customLeft” and then listen for these keys names. It then would be no problem if one day the normal key events are thrown again, because “up”, “down” etc. are ignored.
Best
Andreas
Andreas, thank you very much for the code snippet. I was able to get it working immediately.
One question I have is how do you modify this so that when the user swipes right AND the finger remains down the “right” event keeps repeating. Imagine if you will the behavior when the on screen keyboard is shown, you can continue swiping across multiple letters while holding your finger down (no need to keep physically swiping right across each letter). I am needing to replicate this. Any help is appreciated!
Hi Jon,
I’m traveling right now for a week, and I don’t have my Apple TV with me.
So just an idea:
The problem is to know when the swipe ended. And there is no kind of “fingerUp” event.
But maybe you can check if the touch traveled more than a absolute normalized distance of 0.3 multiplied with a counter that starts with 1 and is incremented after each key event dispatched.
In the beginning you check for the touch travel distance of > 0.3 * counter (and counter = 1 by default), and if the distance is > 0.3 you dispatch the first key and inc the counter.
Then you automatically check again for distance > 0.3 * counter (now this is evaluates to checking for > 0.6, because counter is 2) and if this value is reached you dispatch the next key event and inc the counter again, etc.
For the breaking condition to break this distance check you can test if the touch traveled a minimum distance between two events. Or check if the time between two events is too big. Both cases would indicate that the user stopped the swipe. Now you reset everything, and you start again to watch for the next swipe.
I guess with this method you get what you want, and then you can play around with the numbers a little bit, e.g. use a check for > 0.4 if the method is too sensitive.
Good luck, and when you solve it feel free to post your solution, I would be interested to see how you solved this!
Best
Andreas