Roku Developer Program

[Rek]

"TheEndless" wrote:

"Rek" wrote:

"RokuJoel" wrote:
On older devices, firmware 3.1 you might be able to get away with kicking off an http event on msg.isScreenClosed() when the home button is pressed.

- Joel

Can you offer some insight as to why there is no callback to the application when closing? I would love to have this in my own app, and I'm sure there are many developers who feel the same.

If I recall correctly, the original explanation was that it was to prevent channels from hanging the box indefinitely by including bad code in the close event.

What would be an example of "bad code" that would cause the box to hang indefinitely? Additionally, why would that code only be troublesome in a callback for the channel closing, and not in general app use? Seems fishy...

[RokuMarkn]

The user presses HOME, that causes some kind of call to your exit handler. Now suppose the exit handler goes into a loop? Or decides to conduct a long conversation with a slow server? The user is stuck with a hung system. This can't happen in normal code because HOME will always exit the channel no matter what it's doing. One might envision a system where a second HOME press while in the exit handler would force an exit, although it kind of defeats the purpose of the exit handler.

--Mark

[TheEndless]

"RokuMarkn" wrote:
The user presses HOME, that causes some kind of call to your exit handler. Now suppose the exit handler goes into a loop? Or decides to conduct a long conversation with a slow server? The user is stuck with a hung system. This can't happen in normal code because HOME will always exit the channel no matter what it's doing. One might envision a system where a second HOME press while in the exit handler would force an exit, although it kind of defeats the purpose of the exit handler.

--Mark

A suggestion I've made in the past was to allow for up to X seconds for the channel to exit cleanly, then force kill it, if it doesn't. That would allow for a well written exit handler to do its thing without the concern of bad code causing problems.

[Rek]

"TheEndless" wrote:

"RokuMarkn" wrote:
The user presses HOME, that causes some kind of call to your exit handler. Now suppose the exit handler goes into a loop? Or decides to conduct a long conversation with a slow server? The user is stuck with a hung system. This can't happen in normal code because HOME will always exit the channel no matter what it's doing. One might envision a system where a second HOME press while in the exit handler would force an exit, although it kind of defeats the purpose of the exit handler.

--Mark

A suggestion I've made in the past was to allow for up to X seconds for the channel to exit cleanly, then force kill it, if it doesn't. That would allow for a well written exit handler to do its thing without the concern of bad code causing problems.

I second that. Provide a reasonable period during which the app has the opportunity to exit cleanly; maybe 30 seconds or so. That would be plenty of time to perform a normal cleanup. If the app has not stopped after that, it can be killed.

With that solution, only apps which actually have bad code will be force killed, and it will only hang the box for 30 seconds. This means poorly written apps may perform a bit poorer on shutdown, but removes a significant limitation from all of us who do not have poorly written apps.

[Komag]

I think 30 seconds, even 5 seconds, it just too long. Roku needs to guarantee that users will have a clean Roku experience. I would think 1s or maybe 2s is as long as most people will accept without feeling like something is wrong and, even if it cleared up after 5s, feeling annoyed and negative toward their Roku. It MUST be reliable and FAST.

So, would 1s-2s be enough to send a quick exit diagnostic or data?

[Rek]

"Komag" wrote:
I think 30 seconds, even 5 seconds, it just too long. Roku needs to guarantee that users will have a clean Roku experience. I would think 1s or maybe 2s is as long as most people will accept without feeling like something is wrong and, even if it cleared up after 5s, feeling annoyed and negative toward their Roku. It MUST be reliable and FAST.

So, would 1s-2s be enough to send a quick exit diagnostic or data?

I agree, 30 seconds is far too long for a correctly behaving app. I only suggested such a high number to give some lenience in case the exit handler needs to issue a network request or some such potentially long task. But, that would be for the developer to decide: "Does my app become unresponsive if I do this?". If the developer cares about the quality of his/her channel, they will make sure the exit handler executes quickly.

I really don't think Roku should be making this decision entirely based on bad developers. The public channel approval process should catch applications that do not shutdown cleanly, and simply not be approved if they fail. Private apps are installed at the user's own risk. That's how Roku currently "guarantee(s) that users will have a clean Roku experience". Given the fact that the Roku firmware can be crashed from brightscript with regular application code [1][2], the approval process is the only thing preventing bad code from getting to users. Why not just include a shutdown test to the approval process? Private apps can continue doing whatever the heck they want; some might be crap, but that's no different from today.

I fully agree that the Roku experience should be reliable and fast, and that channels which fail to shutdown quickly are not good, but if they don't become public, I don't see how it makes any difference to the overall Roku experience.

It should also be noted that writing a clean exit handler isn't exactly rocket science -- I imagine very few channels would actually suffer from the whole "infinite loop on shutdown" problem.

[1]: viewtopic.php?f=34&t=67818&p=432714&hilit=golf#p432714
[2]: viewtopic.php?f=34&t=84163

[RokuMarkn]

A general rule of thumb in user interface design is the user should get feedback within about 250 milliseconds after pressing a button. The button click serves as some feedback, but I think a significant delay (more than a second) would be very detrimental to the experience. A possible way to implement this would be to immediately return to the home screen when HOME is pressed, but let the app continue to run its exit handler in the background. If the user selects another channel before the exit handler returns, we would kill the background app, or perhaps if the user was very fast with his fingers and didn't give the exiting app enough time, we could hide the exit handler in the splash screen of the new app.

(This is just an idea off the top of my head -- as far as I'm aware Roku has no plans to implement anything like this.)

I wouldn't assume that writing a "clean" exit handler is easy, even for an experienced programmer. You have to consider things you don't normally consider when writing an app. Just communicating with a server for any reason makes it a "bad" handler, but I doubt most programmers would think of that if they hadn't been through an exercise like this before.

--Mark

[Rek]

"RokuMarkn" wrote:
A general rule of thumb in user interface design is the user should get feedback within about 250 milliseconds after pressing a button. The button click serves as some feedback, but I think a significant delay (more than a second) would be very detrimental to the experience. A possible way to implement this would be to immediately return to the home screen when HOME is pressed, but let the app continue to run its exit handler in the background. If the user selects another channel before the exit handler returns, we would kill the background app, or perhaps if the user was very fast with his fingers and didn't give the exiting app enough time, we could hide the exit handler in the splash screen of the new app.

(This is just an idea off the top of my head -- as far as I'm aware Roku has no plans to implement anything like this.)

I wouldn't assume that writing a "clean" exit handler is easy, even for an experienced programmer. You have to consider things you don't normally consider when writing an app. Just communicating with a server for any reason makes it a "bad" handler, but I doubt most programmers would think of that if they hadn't been through an exercise like this before.

--Mark

If the Roku can continue running the exit handler in the background and show the home screen anyways, that pretty much solves the problem... just lower the timeout to around 5 seconds. As you suggested, if the user opens a new app while the exit handler is still executing, just increase the display time of the new app's splash screen by whatever time remains. Again, this should be an edge case -- most apps will not take the full 5 seconds.

I agree that good user experience will not have the user waiting for feedback (in our app we shoot for 60fps -- 250ms is more than 10x higher than our target response time) -- but again, we're talking about what inexperienced or un-saavy developers will do accidentally, and using that to base fundamental application design.

I can write a private app right now that lags for 5 seconds on every button press and reboots the box if the app is running for more than 30 seconds. Obviously no one is going to install it, and I assume it wouldn't be approved as a public channel. Maybe we should disable button presses? No that's silly... it makes much more sense to just rely on users uninstalling apps that don't work well.

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.

[TheEndless]

"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...

[Rek]

"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.