Roku Developer Program

[M_Babcock]

I'm fairly new to Roku development (though I have experience in XBMC and PlayOn plugin development; among professionally 7+ years in C++ and 3 in .NET), and I'm actually waiting for my XS and LT models to show up so I can dig into the Roku as a new toy development platform. I've briefly read over the docs provided by the SDK, and I think conceptually I have a grasp on what I need to do to get started. There is (at least) one general concept that I would have expected to be documented if it exists that is missing (from what I've seen at least): the ability to setup a background (service/daemon/etc.) process in the background to listen for incoming messages from external sources and raise events regardless of what is currently going on on the screen (display message boxes or otherwise interrupt the current session somehow).

Consider this hypothetical:

Let's say I wanted to create an IM/SMS app for the Roku which showed an incoming message on the screen (informationally only so no user interaction required) to let the person watching know that they've received a new message. It's a horrible idea in concept because it would become a horrible distraction if the user is any bit social (rather than preferring to be locked up in a closet with a laptop, a 12 pack of mt dew, and a bag of cheetos), but remember it is a hypothetical. To limit scope a bit, all of the IM/SMS communication would be facilitated through a server side process which worked the protocols (to keep the client thin), and the only job the Roku box has to do is receive the text to be displayed and display it for a brief moment.

Is their an API to facilitate this behavior? For the record, the pet project I have in mind has nothing to do with the hypothetical (thank god), but the end result is very similar.

[destruk]

Only one channel can be running at one time. So that rather limits the content you can provide in addition to a notification routine.

[MazeWizzard]

Brightscript is single-threaded, single tasking.

However you can, in some cases, "simulate" a BG task within your own application.

I used a finite state machine (FSM) as a background task and called it from within the event polling loop while processing remote control keystrokes. I made sure each state did as little as possible as quickly as possible. This required the use of globals that survived between the iterations to store, at minimum, current state info and anything being processed.

Of course, a FSM may not work in all cases. It requires being called from a polling loop and some of the components may not behave that way. You'll have to use your own common sense here and get some real-world experience with the components outside of your hypothetical case.

[RokuJoel]

Currently the only background task is the screensaver which runs in a separate thread, but it generally only works if there is no video paused or playing on screen.

Joel