Roku Developer Program

[renojim]

I guess Roku implemented some kind of "app kill" when the Home key is pressed on the remote. It used to be that if your app was several layers deep in a hierarchy of screens, each screen would get an isScreenClosed() event. My app would exit its main event handler while loop when it received the isScreenClosed() for the top level and then save some stuff to the server. Now, the app gets killed long before that last event if it's exited using the Home key. So, if there's anything you want to do when the user exits your channel, you may not be able to do it.

After some more testing, even if you only have one layer your app may be killed before you get a chance to do anything as the channel is exited via the Home key. I don't think I like it!

Edit: It's even worse than I thought. I try to save the current progress into the video when a user exits the video screen, but if the user exits via the Home key, there isn't even a chance to do that. I sure hope there's a fix for this!

-JT

[RokuKevin]

Yes. Firmware version 2.6 has new behavior around the Home key. It will forcefully kill the current application and exit to the home screen. Your practice of cleaning up on exit used to be a very good one, but unfortunately not all apps behaved as well as yours and those that did not clean up properly and exit in a timely manner made for a confusing system pattern as background tasks from old apps flashed on the home screen.

In order to provide consistent system behavior we changed the home button to forcefully kill apps. This means that cleanup that used to be done as apps gracefully exit can no longer be relied upon. You must now develop apps with the knowledge that they could be killed at any time....

So.... things like playback position should be periodically reported back to your server. If you are tracking positions in lists, that should probably be immediately updated to the user's profile on your server.

This is a big change, and we understand that some channels may need to change to account for the new behavior. We have found that most channels do not rely on a graceful cleanup anyway, but we apologize to those that did rely on it.

Sorry about rolling this out without adequate warning. We will try to do better around messaging these kinds of changes to developers in the future.

--Kevin

[renojim]

Kevin,

Thanks for the response and explanation. I understand the idea of forcibly killing the app. It took me a while to get my apps to behave properly on exit and I definitely went through several iterations before I got it all right. Many times they didn't exit properly and would flash screens inappropriately. I guess we should expect that our app could get killed at anytime and be prepared for it? I'm not sure it matters, but is there any amount time after the Home button is pressed to do anything, or is it pretty much an arbitrary amount of time? Is it possible to have an isHomeButton() event to do some last minute things, or do you think that opens the door for another way for badly behaving apps to screw things up?

As you said, it would be nice if developers were informed about significant changes like this one before the firmware is rolled out.

Thanks,
-JT

[kbenson]

"renojim" wrote:
I'm not sure it matters, but is there any amount time after the Home button is pressed to do anything, or is it pretty much an arbitrary amount of time? Is it possible to have an isHomeButton() event to do some last minute things, or do you think that opens the door for another way for badly behaving apps to screw things up?

I second that some sort of cleanup handler, with a set amount of time to act before forcibly killed, would be useful. Equating this to UNIX signals it could work like this:

Set an alarm, send a normal kill signal (catchable) to the process
If alarm is hit, forcibly kill (uncatchable signal) the process
If app returns before alarm, remove alarm and continue
If home is pressed again while alarm is active, immediately forcibly kill and remove alarm

Focus would stay with the app until it relinquished control or was forcibly killed, and it's in the developer's best interest and the best practice to display a notice on the screen that the application is cleaning up/saving state if you catch the exit signal. Any time an app catches the exit signal but does not relinquish control (that is, whenever an app has to be forcibly killed), a notification on the home screen by the system that the previous application did not exit cleanly would be useful. This helps enforce best practices by developers and curb bad practices by users (such as always pressing home twice if certain apps take a bit longer to relinquish control).

That would allow developers to correctly apply cleanup/sync routines on exit, while retaining both the ability forcibly stop applications and keep the home screen clean.

-Kevan

[kbenson]

Any info on whether some change to this is even being considered, or is dead on arrival?

[RokuKevin]

We had considered all the above options. We came to a conclusion that the Roku box is an appliance that could have the power pulled at anytime and applications should be saving state periodically because of this. We want applications to be periodically saving state anyway, and killing the apps enhances overall system robustness...

So, we do not anticipate any changes to the model of the Home key killing applications.

--Kevin

[kbenson]

Okay, fair enough. As long as I know not to wait for any change in the foreseeable future, I'll code accordingly.

Thanks for the clarification!

[SolveLLC]

is the app kill function available to the SDK? There are times in an application that we don't want to traverse the layers to exit.

[kbenson]

"SolveLLC" wrote:
is the app kill function available to the SDK? There are times in an application that we don't want to traverse the layers to exit.

Well, the STOP command drops you to a debug console. I don't remember whether that returns the interface to the main display or not, but the Brightscript reference manual state that both errors and the STOP command bring up a debug console, so I assume that at least while not in devel mode (side-loaded), that it just stops.

Other that that, you _could_ cause a crash. Just do a divide-by-zero. That will certainly stop execution.

myexit = 1/0 ' Boom!

P.S. I'm making assertions as to whether this is the correct way to do this, or whether there's other unintended side-effects, just that it will exit your program.

[SolveLLC]

"kbenson" wrote:

myexit = 1/0 ' Boom!

P.S. I'm making assertions as to whether this is the correct way to do this, or whether there's other unintended side-effects, just that it will exit your program.