Many of the more complex SceneGraph node classes are designed to automatically respond to remote control key press events, and configure themselves in response to data changes.
The SceneGraph API was designed to create components that encapsulate the appearance, behavior, and data of custom screen elements. These custom components can then be used in a Scene node program flow that creates the custom components as needed, in response to user selections, or changes in data received from and/or sent to a server. These custom components are analogous to BrightScript components with data interfaces that render screens and screen elements, such as roPosterScreen; in fact, the SceneGraph PosterGrid node class is itself very similar to the BrightScript component roPosterScreen. But by using the SceneGraph API, you can combine several node classes into a custom component with its own encapsulated behavior in response to user input and data received from your server.
To continue with a VOD application example, a typical VOD application will first offer a set of video content categories for user selection, such as "New Releases", "Drama", "Comedy", and so forth. This should drive the development of a SceneGraph custom component that displays these categories, which will read the data from your server that you make available to the component to display the categories, including icons, text, graphic images, in either JSON or XML format. The data provided for that component should also include data to pass to another custom component, through the <interface> element or other means, to allow user selection of further sub-categories or video content items. All of the previous BrightScript component "screens", including "screens" for registration, search, license display, can be developed as encapsulated SceneGraph components, which can (and typically will and should) include their own components developed to provide specific appearance and functionality to several major components in your application.
You can then select the nodes to comprise your custom component from the SceneGraph API node classes, to either create or modify them using BrightScript in the <script> element, and/or declare/define them in XML markup in the <children> element. For example, for a list of categories, you might want to use the LabelList node class, or perhaps the MarkupList node class, since you intend to include graphic images as part of your list. You will also use two Poster node classes somewhere in your component for your icon and poster graphic images, perhaps as part of another custom component that is the definition of the itemComponentName field of the MarkupList node. You complete the component by adding <interface> element fields as needed to get and set data that is either needed for the component, or passed to other components and/or the Scene node BrightScript program flow.
MarkupList.zip is an example application of the completed custom list configuration. In the example application, note that the file markuplistcontent.xml is the ContentNode node component that supplies the data to populate the list; normally this data would be in a XML/JSON file that would be downloaded from your server to the application and converted to a ContentNode node using a Task node (or equivalent). Also note that the icon and poster files are included in the package images directory, rather than your server, and the markuplistscene.xml is only provided to allow the example to run as a standalone application.
These examples download and convert a MRSS XML feed containing all the data for the application to a ContentNode node field added to the Scene node <interface> element. In this case, the data for the application is downloaded and converted in the source/main.brs file after the application Scene node is created but before it is shown, rather than using a Task node in the actual SceneGraph application.