[WORKAROUND] Apple tv remote swipes return multiple key values

Solar2D Apple TV and tvOS
#21

Agreed.

#22 
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

#23

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.  

#24

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

#25

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 )
#26

Nice!

#27

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

#28

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!

#29

Hi Jon,

I’m traveling right now for a week, and I don’t have my Apple TV with me. :wink:

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

#30

Thanks Andreas I’ll see what I can come up with

#31

Hi Jon,

found something, maybe this bridge was already crossed and you can use or adapt the code posted here:

https://forums.coronalabs.com/topic/57554-detecting-separate-swipe-without-lifting-finger/ 

If you are successful with this please tell me! :slight_smile:

Best

Andreas

#32

Andreas I haven’t ignored you :slight_smile:   I am still trying to get a workable solution, but not having any luck.  I wish CL would simplify things and ramp up the support for the remote, see how it is THE most important part of the platform.  

#33

Thanks for the report. I’m not sure if reading the touch pad as an Axis instead of key events would help if you’re trying to detect swipes.

Rob

#34

Hi Rob, I don’t exactly need swipes, I just want to know the correct direction of the user input when I listen for the keys. And I thought that listening for the up, down, left right keys will give me just this direction, the same as giving me the buttonA and buttonX key events. I of course can start to code my own translate-axis-movements-on-the-touch-area-to-keys method, but I was hoping that this would just be corrected SDK side. Or are you implying that it is already implemented the way it should work? That these double or triple key events are intentional? Thanks & best Andreas

#35

What I was suggesting is that if the key events are too sensitive, you could use the axis events and basically roll your own events that would give you more control.

Rob

#36

This is definitely an issue. Can you send a bug report with the attached project and post the case number back in this topic?

#37

Hi Michael,

done:  (Case 44134) Apple tv remote swipes return multiple key values

Thanks for looking into it. It’s great that Corona continually supports the tvOS Alpha, so we can continue to convert our games!

Best

Andreas 

@Rob:

Yes, if I would need more control I would implement my own swipe code. But I need these controls only for navigating the menus.

The rotating levels in “Freeze! 2 - Brothers” are now controlled using the accelerometer. And yes, there is some small lag as always with the accelerometer, but that doesn’t hurt - it really is fun to play the game this way (otherwise I wouldn’t publish it).

#38

Hi Michael,

I tested this issue with daily build 2795 (tvOS BETA), and the problem still exists. And it’s a bad one, the multiple keys returned per swipe makes navigating e.g. a level menu using directional swipes almost impossible.

As you decided to go to BETA, did you check this issue first? Or did you get a different result running the demo code on the device?

Thanks & best

Andreas

#39

Hi Andreas,

We definitely do see this issue, and it’s one we need to fix. It did not make it to the beta list.

I suggest using the raw axis values (listen to “axis” events instead of “key” events) for now.

  • Michael
#40

Hi Michael,

thanks for the lightning fast feedback - on a Sunday night! I now feel bad that you had to answer at the weekend!

Good to know that you see this issue. 

Thanks & best

Andreas