Roku Developer Program

[dhof]

What's the best structure for an app with 3+ screens. An example app:
Home Screen, Categories/Stars/Studios screen, Content based on Cat/Star/Studio chosen screen

- These 3 screens are in their own individual xml/brs file sets.
- The Home screen is a Rowlist with a menu bar in the 2nd row.
- The Cats/Stars/Studios screen is a PosterGrid
- The chosen Content screen is a PosterGrid with a menu bar before the videos. 
- There is an Overhang on every screen and the title relates to the content last selected.

I have 2 interface fields for previousScreens and the overhangNode. This allows me to show content and update the Overhang title whether i'm going forward or backward.

My questions:
1. Should I consolidate the functionality of these 3 screens into 1 xml/brs set? (I then wouldn't have to transport data around like i'm shuffling it down the line 1 file at a time)
2. What is the easiest way for data to traverse the entire app?
3. How to properly organize Back key functionality if I keep my current file structure (currently each brs file has BACK functionality)
4. If this is not even remotely close to the proper structure for an app, what is? 

[joetesta]

1. I wouldn't consolidate your components if you already have them broken out. You just need to assign them their specific content as they're traversed.
2. You could have a single top level page that holds the data, or you could also use m.global, add fields that are then accessible from anywhere later.
3. In the top level page you can maintain an array of traversed pages and if the user hits back, pop the last fields off to find the previous page until the stack is empty.
4. To me it sounds correct though there are some details unclear.
where do you have those interface fields / where are you attaching the new pages that you open?
If you attach the pages as child nodes of the top level page then your data will persist in that top level page and can be assigned out to initialize or update the child pages as they're selected.

[dhof]

That helped a lot, I think I was finally able to wrap my head around certain things, thank you!

What I currently have is 3 pages independent of each other and i'm passing data to them via the interface fields (each page had a prevScreens and overhangNode field ) though I was having trouble passing data backward because of a lack of reference to earlier components. And I just turn visibility on and off for them when users move to a different screen.

After going through some things based on your reply, it seems the most appropriate structure is having 1 "scene", appending my 3 pages to it, updating content and turning visibility on/off as I need. The assoc array is a good idea for keeping track of the users screen movement for the BACK button. I was thinking of doing that via an interface but this will obviously be much easier having it all at a top level page.

One further question: I will also have a Login page. I'm assuming this means I should make a 2nd "scene"? One for the Login and the other is my actual app content. main.brs would then have a statement pushing the user to the correct scene based on if they were logged in or not. Does this sound correct?

[joetesta]

Glad that helped 🙂

The way I do a login screen is to have it be a subcomponent of the main screen that gets opened first and other components with actual content don't get attached until the login succeeds.  But there's more than one way to do it.

And I actually use (and recommend) a simple array for the page stack used by the back button, that simple array can contain elements that are assoc arrays with the needed info to repopulate your pages.  But again there's more than one way!

[dhof]

Awesome! I'm sure i'll have some questions about Login screen architecture when I get to it but i'll focus on the main content for the time being. Thanks for your help Joe!