"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.
I like your "double HOME" idea, Mark!
A lot, even. Because:
- It provides clear resolution from user's point of view, regardless of how the program may misbehave (intentionally or un-intentionally). User's comfort beats developer's, there could be no dead end. The spice must flow.
- It is clean on your side. Easy to implement as compared to background threads (stub-ing access to graphics/audio, dealing with CPU/network vampires, racy conditions etc) and won't affect foreground channel, for trivial reasons.
- Users are already used to pressing Home repeatedly on occasions (when screen saver is engaged - or to rotate the home menu to 1st position). Heck, i have been observed pounding Home repeatedly when rushed. Urging => just do it, regardless of developer convenience (you cannot force the viewer stay with you - ultimately they'll yank the power cable if they have to).
Developing on it a little bit, i imagine something like:
- User presses Home. Send the app an "Exit Pending/Requested" subtype of event* (via roSystemLogEvent?) and start a 1000ms "time to appeal" period
- If within appeal period the app responds back by calling `pleaseDontKillMe(PrettyPlease)`, suspend the death sentence and put the app on a 10 sec "probation". Otherwise kill it.
- If during the "probation" (or appeal) period a 2nd Home arrives, we are done - close the app, no further notifications/reprieves. Otherwise at end of probation expunge criminal record (we forget Home was pressed, live in the clear)
This way an app will have a chance to plead its case to the user (like show popup "please, please don't kill me now - i am saving game level/video progress right now, will be done in 5...4...3... etc") - but won't be able to tie them down (remember those ads in the web browsers that when tried to be closed would open new windows?).
It can also be implemented in stages - both on channel's and Roku's side. Meaning the app does not have to call back to delay exit - it has 1000ms to say save to registry its status. Or that at first iteration of API, Roku may not even do #2 - just send notification and kill a second** later.
(*) If they are not subscribed to that event, we are done: old behavior preserved; pre-exit notifications is an opt-in mechanism
(**) All times mentioned are somewhat arbitrary, obviously - but they illustrate the right magnitude of value.
