Roku Developer Program

[RokuMarkn]

"Rek" wrote:
(in our app we shoot for 60fps -- 250ms is more than 10x higher than our target response time)

The fact that you're running at 60 fps doesn't mean you're responding to user button presses in 17 ms. Given that the duration of an IR code is more than 50 ms, it's not possible to respond 17 ms after the _start_ of the button press.

--Mark

[Rek]

"RokuMarkn" wrote:

"Rek" wrote:
(in our app we shoot for 60fps -- 250ms is more than 10x higher than our target response time)

The fact that you're running at 60 fps doesn't mean you're responding to user button presses in 17 ms. Given that the duration of an IR code is more than 50 ms, it's not possible to respond 17 ms after the _start_ of the button press.

--Mark

We don't account for the length of IR control pulses... I was speaking from the time the event is produced from the message port. Out of curiosity -- what is the total time for a WiFi remote to get from the start of a button press to a roUniversalControlEvent being queued on a message port?

[squirreltown]

"Rek" wrote:
just increase the display time of the new app's splash screen by whatever time remains.

I would not be in favor of this. If your app needs to pull graphics or sounds from the net, its probably taking long enough to start up as it is. Run Netflix lately?

[TheEndless]

"Rek" wrote:

"TheEndless" wrote:

"Rek" wrote:
Other platforms have to deal with this too -- android, for example, will show a dialog box with something along the lines of "App not responding", giving the user a button to kill it, or wait for it to finish.

Android also has background threads, which would be awesome to have on Roku, but that's a different topic altogether...

The Roku firmware can use background threads, they just don't expose that to brighscript applications. I don't know the inner-workings of the Roku, but a system-level dialog should be possible.

I know.. it's usually not an issue with standard SDK screen based apps, because the UI for those runs in its own thread independently of the Brightscript code, but for 2D API apps, where you're drawing the UI in the same thread as you're responding to user interaction, processing API responses, and tweening animations, the lack of threading capabilities can cause some real headaches.

[Rek]

"squirreltown" wrote:

"Rek" wrote:
just increase the display time of the new app's splash screen by whatever time remains.

I would not be in favor of this. If your app needs to pull graphics or sounds from the net, its probably taking long enough to start up as it is. Run Netflix lately?

Netflix is a special case since they don't use brightscript. Besides, this would only be adding the "remaining" time in the exit handler to the splash screen.

Example:

1. App A is opened.
2. User presses Home button.
3. Regular execution stops.
4. atexit is called from a background thread.
5. App A closes and shows the home screen.
6. User navigates to App B's icon on home screen.
7. User launches App B.
8. App B's splash screen is displayed.

Let's say it took 3 seconds to get from step 2 -> step 8, if the exit handler's timeout is 5 seconds, we would only be waiting 2 extra seconds here. This is also THE WORST CASE SCENARIO -- typical apps will not take 5 seconds to shutdown.

It really should be clear that we're discussing behaviour of BADLY WRITTEN APPS. Properly written exit handlers should not take even 1 second to finish. In fact, the timeout could probably be lowered further to only 1 second if it's really that concerning (if there are really THAT many bad roku apps out in the wild).

[Rek]

"TheEndless" wrote:
I know.. it's usually not an issue with standard SDK screen based apps, because the UI for those runs in its own thread independently of the Brightscript code, but for 2D API apps, where you're drawing the UI in the same thread as you're responding to user interaction, processing API responses, and tweening animations, the lack of threading capabilities can cause some real headaches.

You're preaching to the converted on this one my friend. We also use the 2D API, and we've had to implement rudimentary threading with callbacks and a master run loop -- about 2 weeks of effort that would've been saved if there was a threading API (not to mention real threads would be much more powerful).

[sjb64]

If I remember right I used to deal with this in some old Silverlight development, as I had 3 seconds to do whatever I needed on a user initiated exit. This made any web service type calls such as logging, analytics, or a session close event very problematic. Our solution was to do any local work we needed, save our state to a registry type marker, and process it on the next spinup. This took a fraction of the time we were allotted, and worked well enough overall.

[TheEndless]

"sjb64" wrote:
If I remember right I used to deal with this in some old Silverlight development, as I had 3 seconds to do whatever I needed on a user initiated exit. This made any web service type calls such as logging, analytics, or a session close event very problematic. Our solution was to do any local work we needed, save our state to a registry type marker, and process it on the next spinup. This took a fraction of the time we were allotted, and worked well enough overall.

The problem with that is it's always one app session behind. You'll never get the exit events from the last time the user used the app.

[sjb64]

I totally agree, that's was what I meant by worked well enough overall. We were always one session behind on the results, but still gave us a good overall view of the stats we needed, and sessions would autoclose after 20 minutes of inactivity, so this would in some cases release the session before then (when those users come back within 20).

btw, I've been working on our Roku app for the past several months, and your posts have been beyond invaluable on countless occasions. First chance I have to say just how much I have appreciated your insights and advice.

[EnTerr]

"TheEndless" wrote:
Android also has background threads, which would be awesome to have on Roku, but that's a different topic altogether...

It is indeed. Android is a good example of what NOT to do. 🙂 If Android does something one way - and other platforms (iOS, Windows mobile etc) do it differently - it's safe bet to go with "don't do the Android thing". Android started from the wrong premise, "let's turn phones into multitasking computers - that's what people need"