Challenges of Building Roku Applications
Part 2 of our OTT series
By Mark Zou and Mike Hakak
This is the second part of our OTT series. In the first blog of the series, we shared our Roku App Kit.
There are multiple Roku streaming devices; the first (the Roku DVP) came out in 2008, and since, many other devices have been released with newer and greater elements of functionality. This means that to publish Roku channels, the channel must be able to support both high-end devices and low-end devices. This isn’t easy and developers have struggled to build on Roku.
How does a developer ensure a channel looks as good as possible — including all high-end animations, graphics, etc. — on a low-end device but isn’t so watered-down that it looks poor and overly simplistic on a high-end Roku device?
In an ideal world, application designs account for both low-end and high-end devices, and strike a perfect balance between the two. The best product experience is the one that scales the app experience to the given device. However, app User Interface (UI) and User Experience (UX) designs are typically catered to higher powered devices that can achieve all the visual fidelities, which are harder to achieve on low-end Roku devices. Take a look at the Netflix example:
There are two key reasons for this:
- Memory Limitation: the amount of textured memory is very limited on many low-end devices. Meaning, the device will have issues displaying large images, and a large number of items on the screen.
- UI Thread Execution Timeout Limit: spending time on UI thread initialization and rendering collection items (such as RowList items) can easily lead to timeouts on the UI thread, which can cause the app to crash. In development mode, the timeout is 3 seconds, which is already too long to block the UI. Further, any attempt to run functions inside of a render node from a task thread doesn’t solve any problems because the execution of render node functions will automatically switch the thread context back to the UI thread. It’s also hard to synchronize data and timing in such cases.
The engineering challenge is how to accommodate as much of the design as possible on low-end devices, without causing out-of-memory errors, UI thread execution timeouts, and excessive interface unresponsiveness.
The good news is that we came up with some helpful strategies to deal with each issue so you can build a Roku channel that looks just as good on both high-end and low-end devices.
Strategies:
1. Reduce any unnecessary memory usage by request image assets based the app resolution
When building an app from the ground up, all sizes, translations, and font specifications are dynamically calculated based on the app’s resolution setting. We started with 1080p as the default design values for width, height, translation, font size, etc. As we detected different resolution settings (such as 720p), we rescaled all of our UI components by a factor — this factor can easily be calculated:
factor = targetResolution ÷ 1080
In the case of SD resolution, you would have to calculate both height and width factors as the aspect ratio is no longer 16:9. This way, when creating a poster, you’re creating it to the needed size.
You can also use an image resizing service if image memory is an issue. That way, you can directly request images with the size needed. This practice reduces wasted memory and/or the need for Roku to run internal scaling algorithms.
2. Time slicing UI component creation
We call this the “UI breathing technique.” The idea is simple, let the UI thread take an execution break every so often, basically to achieve time slicing. We did this by creating a universal timer component that would constantly generate a “pulse” throughout the lifespan of the application. Any UI component can register to this “pulse” and perform a small chunk of the task with each heartbeat. The frequency of this “pulse” can be set to reflect the power of the device, which will maximize the device’s potential power.
Through our experimentation, it became clear that the best way to apply such a “breathing” technique is to break down the item components used by collection-type UI components, such as RowList. The rationale is that if each item creation is broken down, then all larger UI elements will be broken down by default, automatically relieving the UI thread in most scenarios.
The best way to break up an item component is to break up its init() subroutine and its onContentChanged() event handler, as these functions are often the most time-consuming. You can set up an array of methods needed to perform an initialization or content change, and then execute them one at a time on the universal “pulse.” This means that the actual init() subroutine or onContentChanged() event handler will only be responsible for setting up the execution array and nothing else.
This kind of “breathing” technique will allow the developer to have near unlimited command over the UI thread, while still providing a decent UI responsiveness.
Here is a visualization of the UI breathing technique:
Hopefully, these strategies will help you build and publish Roku Channels that look and operate just as well on a wide range of Roku devices.
Mark Zou is an Agile Software Engineer at TribalScale, with over 8 years of OTT industry experience. He has worked with industry partners such as DIRECTV (now AT&T), and he’s an advocate for engineers having a design thinking mindset.
Mike Hakak is an Agile Software Engineer at TribalScale, where he enforces a versatile skill set that he has applied in the IT industry for over 15 years. His unquenchable thirst for experience has led him to take on roles as a Recruiter, Business Analyst, Software Engineer, Sales Negotiator, Project Manager, Consultant, and Mentor.
Join our fast growing team and connect with us on Twitter, LinkedIn, Instagram & Facebook! Learn more about us on our website.
