Roku SDK 2.0: New Tools, New Challenges

Roku recently released SDK 2.0, a major update of its development tools for the popular set-top box. The SDK provides new, more flexible tools for rapidly creating channels that mimic the Roku home screen, while also allowing expanded flexibility to create innovative, custom user experiences.

Ratio’s engineering teams have been heads-down implementing this new SDK in soon-to-be released channels for clients. With the official release of this SDK in October, we thought we’d take a brief pause to share what we’ve learned to date.

Everything old is new again.

At the core of the Roku SDK is still a niche language called BrightScript, a descendant of BASIC highly customized and optimized for (and by) Roku. While you won’t find a long line of developers clamoring to dust off their BASIC skills (likely last used in a CS-101 homework assignment), the language is relatively easy to pick up, save a few oddities. While SDK 1.0 relied almost entirely on BrightScript, SDK 2.0 uses it for the bulk of model and controller tasks such as creating view controller logic, data structures, and retrieving data from web services.

 

Enter the Scene Graph.

In SDK 1.0, developers were limited to a set of pre-defined components and screens for creating Roku channel visuals (unless they wanted to delve into the infinitely more complex and time-consuming custom 2D drawing interface).  SDK 2.0 introduces an entirely new paradigm for user interface (UI) development called Scene Graph.

In broad terms, Scene Graph allows developers to create UI elements using an XML layout that defines a visual tree of components as well as a data interface and view controller logic. The view logic is actually inserted into the XML as a script node with a CDATA element containing (you guessed it) BrightScript code (this code can also be written in external files that are linked to the script node). A note from the Ratio devs: working with external files linked to the XML file creates better separation between view and its logic, as well as a better overall developer experience (color syntax and IDE support).

Scene Graph provides both pre-defined, optimized components and building blocks that allow for a wide range of innovation. These are represented as a series of “nodes” with various functionality. Four renderable nodes – Label (text), Rectangle, Video, and Poster (bitmap image) – join abstract nodes designed to group UI elements or represent data (these include Group, LayoutGroup, ContentNode, and many others). Roku also provides a handful of “widgets” (buttons, keyboards, dialogs, etc.) and more complex, highly optimized components that recreate Roku’s home screen functionality. The most powerful of these is the PanelSet which provides smooth animation and a drill-down hierarchy for displaying catalogs of content.

 

This changes everything.

Scene Graph and SDK 2.0 allow for exciting new possibilities in custom Roku development. The basic building blocks and optimized components combine to create a more flexible and performant framework. For example, developers can use the PanelSet component to quickly create a UI that resembles the Roku home screen very closely. This includes smooth animations and out-of-the-box UI elements that have a decidedly more modern look than SDK 1.0’s skeuomorphic screens.

We’ve also experimented heavily with entirely custom approaches using a combination of optimized controls and basic building blocks. There are limits and caveats (see below), but forging your own path is infinitely more possible in SDK 2.0.

The Button Widget is one simple example that highlights the ability to create custom controls (when the defaults just won’t do). While most SDK 2.0 components are highly customizable, we found the SDK-supplied Button Widget did not work well with many of our custom designs due to certain elements and behaviors that were not exposed in its interface. In SDK 1.0, we would have been left to adjust our UI to work around this widget’s behaviors. In SDK 2.0, we simply created a custom button component from scratch. We matched some functionality of the core Roku Button, but were able to apply our own approach to what a button is and how it behaves. This ability to customize and innovate exponentially increases our ability to build channels that are fresh and effective.

 

Things to know before you go.

After developing several channels using Roku SDK 1.0 and 2.0, we’ve compiled a few helpful hints to get you started:

Performance: your mileage may vary.

Scene Graph applications run on Roku set-top boxes, so it’s important to understand the unique requirements of that ecosystem. Roku devices have limited memory and varying graphics processing power (some have dedicated GPUs, some do not). It is entirely possible to use Scene Graph to create a UI that does not perform well on current generation Roku devices with less capability. We recommend testing across the complete spectrum of Roku models currently being sold to ensure performance, compatibility, and reliability.

When in doubt, build it out.

The default SDK 2.0 components and widgets are sealed, so there is no way to refactor and recompile them to work around undesired behavior (this means you may have to recreate components to bend them to your will). While this is not recommended with more complex components like PanelSet, our UI designs have led us to build out custom versions of the Button, Overhang and some other more basic components. The good news is that SDK 2.0 makes this possible and even simpler in some cases.

One other note from the Ratio devs: Video is a base-level renderable node that includes all functionality needed to play videos, but, as of this writing, it does not include default player controls or remote button listeners. You’ll have to listen for player and button events to create a progress bar, fast forward and rewind, “trick play” image display, time code, etc. The only UI that seems to be built in to the Video node is a title and “retrieving” progress bar that displays on startup and when the video playback is buffering (we’re still trying to figure out how to change that progress bar to any color other than purple).

Developing on Roku: clever engineering required.

Developing for Roku is a novel experience for most software developers. Images, Brightscript and SceneGraph files are packaged as a zip and dropped directly onto any Roku that has been development-enabled through a series of remote control presses. These are all text files that can be created with any text editor. There are plugins for Eclipse and Visual Studio that provide varying levels of code highlighting, exporting, and console viewing capabilities.

Testing and debugging is its own particular challenge. To test channels, you must first deploy the build to a Roku then telnet into various ports (one per thread) to listen for debug output (“print” statements) and the occasional full-stop exception. Through telnet, you can access the Brightscript Debugger. This allows a developer to inspect and print object values, step into methods (not step over), and generally poke around at what’s happening in the execution loop. Overall, however, it is still an incomplete debugging environment. Our wish list of future features still includes: the ability to “step over,” and better IDE integration (including autocomplete, referential integrity checks, and more code inspection options).

While it has not been updated significantly, the Roku developer environment does give a developer the basic tools required to effectively develop a channel (once you get the hang of it). Be on the lookout for typos (in “magic strings”, node names and method names). Also, watch the semicolons. New Roku developers like to insert semicolons at the end of each line which, BrightScript does not allow.  Most compiler errors we can’t explain are caused by stray semicolons.

Tasks: a powerful new concept, still needs work.

The Task node class allows a developer to specify a function to be spawned in a different thread, and run asynchronously with respect to both the scene rendering thread and the main application thread.

Tasks provide a few basic lifecycle controls that allow a developer to control the execution of a task logic. It would be great having some out-of-the-box features that allow a task to play seamlessly with PanelSet and in general, application navigation.

Some things you can do that you probably shouldn’t.

What follows are some pretty “in the weeds” technical details that will make more sense after a first pass at building a Roku SDK 2.0 channel, but their effects are dramatic, so they are worth mentioning. First, although you can pass around associative arrays as fields in SceneGraph component interfaces, it’s not recommended; the system actually copies these arrays in and out of the fields and attempts to reduce them to primitive types. This can lead to some system logging, which slows down the UI thread noticeably. The most performant way to pass large (or even moderate) amounts of data to SceneGraph components is to use Nodes (either a ContentData Node or a custom Node).

It’s also possible to create circular references (and thereby memory leaks) by passing around references to the current context (represented as “m.top”). The SceneGraph components redefine m.top per component. A telltale sign of this issue is a message on exiting the channel in the debug console that list the number of orphaned objects (or a long delay in the channel exiting). These leaks can create serious performance issues – so be on the lookout!

A brave new world.

At Ratio, our designers, developers, and clients are excited about the new possibilities presented by Roku’s latest SDK. The new framework has already allowed us to create fresh and innovative user interfaces for our clients, and we are looking forward to designing and building the next generation of streaming television experiences on Roku. It’s not perfect, but the Roku SDK 2.0 is a huge step in the right direction.