Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Komag
Roku Guru

Do we need to support remote control apps?

I was just testing my game with my phone using the official Roku remote app, and it controls differently:
Tapping a direction works as expected.
But holding a direction has a long delay before the Roku gets the signal, for some reason (I'm assuming it's some sort of delay built into the phone app). If there's any sort of quick action in the game where holding a button is part of the gameplay (such as charging up for a more powerful shot/swing), this will cause problems.

Also, opening up the keyboard (in the app) and pressing letters and stuff sends unexpected signals (it crashed my game!). I've fixed this by more carefully coding what ids I'm expecting to receive and work with, but what if future changes in the app break my game?

But the question remains, for channel publication, does the channel/game need to pass testing with phone apps? I don't have any Apple product to test that app, for example.
0 Kudos
6 REPLIES 6
EnTerr
Roku Guru

Re: Do we need to support remote control apps?

It is not required per se - or at least i don't it is listed in the "Channel Checklist" linked to at the very end of http://sdkdocs.roku.com/display/sdkdoc/Developer+Guide

Up to your will, it's probably a good idea to try and see if channel can work reasonably well with a remote app. Some changes might be minimal, like avoid crashes on unexpected input. Not sure what you mean by "tapping a direction" and "holding a direction" though. Are you using the "Roku" app and is it in "swipe remote=on" mode (default is off)?

PS. Last night, when i was putting finishing touches to a channel - after having dealt with the "Roku 3 has no Replay button" curveball by adding handling of simultaneous-button-press contraptions - i thought about checking it with a remote app and quickly realized that is not going to fly. But for me it was question of developer pride - i have published a Roku remote app and now making a channel that won't work with it?... that's kind of lame. So back to the drawing board i went - and what i settled on was key sequences instead - so for example "Replay" is now "*" followed by "Back". And that works with most (all) remote apps - and in addition cuts down on restarting a level by mistake, now you need to press two buttons for that instead of one
0 Kudos
Komag
Roku Guru

Re: Do we need to support remote control apps?

I can't find any option like "swipe remote=on" anywhere. It's the main official Roku app for Android.

Tapping is touching a "button" on the remote and letting go quickly. When I have my console printing out port messages, it prints out, for example 3 then 103 very quickly when I tap "Down". But when I touch and hold "Down" (3), the console doesn't print out a 3 for something like a whole second, then it finally comes and my character in the game finally starts to move, and when I later let go of Down the 103 shows up immediately.

How were you doing simultaneous buttons? I thought we didn't have any access to that!
0 Kudos
EnTerr
Roku Guru

Re: Do we need to support remote control apps?

I was talking about the iOS app, it has 2 different modes - traditional buttons and pad for swiping. I guess i assumed Android one has that choice too.

Try an alternative remote app and see if behavior is the same - this is to see where the difference lies, is it in the app or in the ECP host somehow. Oh, how about trying http://remoku.tv ?

We cannot handle simultaneous button presses in BrSc, that's true. But even if they added that, it will be limited to the "radio" remotes only. In couple of threads before we discussed the IR remotes and things don't look good there, something like on a PRESS/release sequence X-Y-y-x, you receive X-x-X-x; on X-Y-x-y get X-x-Y-y. But is that necessarily a tragedy? Look at the runaway success that "Retaliate" game is - and all it is using are the 4 D-pad buttons...
0 Kudos
Romans_I_XVI
Roku Guru

Re: Do we need to support remote control apps?

😛 😄
0 Kudos
Komag
Roku Guru

Re: Do we need to support remote control apps?

Revisiting this with more details:

(Apps are tested on my Android phone)

(App) Official Roku App:
- Direction buttons still have a delay before sending a "button down" event if you press and hold a direction, but it does work correctly at least, and when you finally let go of the direction it then properly sends a "button up" event
- All other buttons DON'T work correctly! They send NO signal/event when pressing and holding, but rather the both button down and button up events when you let go of the button. I assume these are using the lazy "keypress" ECP command, instead of properly using "keydown" and "keyup" commands
This is game breaking for me since I have programmed different behavior for long-press buttons for in-game actions.

(App) Remoku:
- All buttons seems to use "keypress", even the directions. Broken

(App) Roku Buddy:
- Same, broken

(Website) http://remoku.tv/
- Works correctly! Nice surprise there 😄 There is still some small delay in the signals, but not terrible. Unfortunately, many button presses seem to go undetected at all. But when they work, they work correctly, with independent keydown and keyup commands, so my long-press controls work exactly as programmed, nice.

I haven't yet tested any other Roku Remote apps
0 Kudos
EnTerr
Roku Guru

Re: Do we need to support remote control apps?

Right. I cannot vouch for the others but as the author of one of the remote apps for iPhone, i can speak about my app - and (as far as i remember):
  • i send keydown on touch-down and keyup on "touch-up" of the D-pad arrows (up/down/left/right), << and >> only

  • i send keypress for all other buttons, on un-touch

I remember four years ago i put lot of thought into this. And testing. The arrows and FF/REW got the up/down treatment because of the "auto-repeat" way they are used in UI. (Keypress then gets synthesized for them by the firmware.) Keypress for the others is sent on "touchUpInside" from a button, because that's how it's done customarily in iOS (on lifting the finger or "un-touch from inside", to avoid false trigger by an involuntary "smear" tap). It also allowed me the trick of different handling for a long-press of Home or a channel icon.
0 Kudos