Roku Developer Program

[edwardaux]

hi all... have been wading my through the various documentation pages and have a few examples working. I'm now starting to think a bit about how my channel will be architected internally.

It seems that the general concensus is that we should have a single scene. That's where I'm heading... I'd love to hear thoughts if this is wildly inappropriate.

Regarding screens and transitioning between them... I've seen a few examples where the main scene has all the screens declared (but not visible) and then just toggles them visible (or not) depending on the user's actions. Does this scale? For example, if my channel has, say, 20 different screens are there any performance (or other) implications in having the main scene being the central holder?  (what about if I end up having 50 screens?)  Or, is the main screen better to just have the couple of screens that the user can get to from the home screen, and then have those screens contains the sub-screens?  The latter seems like navigating between screens could become cumbersome. Thoughts?

Along the same lines, if I want to maintain a historical navigation stack to handle pressing back on the remote, the scene (or something, anyway) will need to maintain a stack of screens to go back through. Is this the general convention? Any suggestions on good patterns to follow in this space?

Apologies for the novice-level questions... just trying to get some good patterns in place before getting cracking. Thanks a lot.

[georgejecook]

I too would like an answer to this

[destruk]

Why would you have 50 screens?  Would the end user have to go through all 50 of them to do one thing?
Generally you have layers, and four or 5 actual screens, where the content is simply changed as needed when they are displayed.  If you are linking the device with full account and billing interaction then you might have 10 or 15 screens, but I don't see any reason to have 50 individual screens.

As for the layering, that is left up to you.  You are looking for the back button, or an event to happen, or a timer to go off, or some other keypress to go back in the stack and make the necessary (if any) modifications to the displayed screen content.  As each screen is able to have it's own key or event handler, you can track what caused the screen to be displayed and pass back that data to the calling layer.

[georgejecook]

I've just been experemeing with creating the notion of a base scene.. I think that's what I'll go with.

 * 1 Screen and 1 scene as per the best practices (some Roku engineer recommends this in a post here, which I stumbled upon
 * Base class for my scenes (which are actually groups) - this seems to be working well so far and will allow me to remove some annoying boilerplate.

The next bit I really want to work out is how best to do network/async stuff. I know the pattern of have a task and communicate with it; but that just seems bloody tedious.. My current thinking is a global util network call function, which is async and invoked with the call method which includes in it's payload the name of the current scene - the listener for this util method will then look up the relevant scene, and invoke it's OnURLRequestResult interface method (again via interface functions) with the payload...

That to me seems the most sensible approach I've yet come across - would love to here what other's do.. bummer that there is no real component inheritance. My base methods are essentially placeholders. One does wonder what this platform would've been like with Python/C# as the language, I must confess.

Anyone see a problem with this approach btw?

'ThirdScene.brs
function init()
    ? "[THIRD SCENE]"
end function

'***********************************
' Key handler overrides
'***********************************

function OnPressOk() as boolean
    ? "PRESSED OK"
    return true
end function 

function OnPressDown() as boolean
    ? "PRESSED DOWN"
    return true
end function


function OnPressUp() as boolean
    ? "PRESSED UP"
    return true
end function

'BaseScene.brs
function init()
    ? "[BASE SCENE]"
end function


function onKeyEvent(key as String, press as Boolean) as Boolean
    result = false
     if press then
        if key = "left" then 
            result = OnPressLeft() 
        else if key = "right" then
            result = OnPressRight() 
        else if key = "up" then 
            result = OnPressUp()
        else if key = "down" then 
            result = OnPressDown()
        else if key = "OK" then 
            result = OnPressOK()
        end if
    end if
    return result
end function

'***********************************
' Key handler abstract methods
'***********************************

function OnPressLeft() as boolean
    return false
end function

function OnPressRight() as boolean
    return false
end function

function OnPressUp() as boolean
    return false
end function

function OnPressDown() as boolean
    return false
end function

function OnPressOK() as boolean
    return false
end function