Advice for developers: embrace the good, the bad, and the ugly.
For any developer thinking of changing career direction or expanding into new technology areas, the learning curve can be daunting. No matter how widely and deeply your education and professional experience have propelled you into the wide world of software technology if you move into an adjacent field, new processes and techniques need to be learned. You even need to learn a new vocabulary, in order to understand customer requirements for a start.
If you have spent most of your career developing Android mobile applications, transitioning into the technically complex TV applications world can be quite challenging. In this article we take a look at the differences you may face when developing Android TV applications compared with working in the more familiar (even comfortable?) Android mobile world. Even though both development ‘playing fields’ are based on the same core technology, the essence of the game, and the rules, are quite distinct.
There are several fundamental differences between developing for remotely controlled devices (we can’t really just call them “TV sets”) compared to developing for mobile devices, and you will soon become aware of them. But here’s the heads-up:
The new stuff you will encounter in Android development for TV:
- User interaction in the ‘TV’ environment is achieved by handling Remote Control key-initiated events, as opposed to handling simple touches, clicks, or swipes made on the device in the mobile world. This introduces extra complexity and an extra ‘risk’ step as regards integration and device reaction time…
- UI elements are focusable – this is a completely unique concept when developing remote-controlled apps compared to how mobile apps are used. The entire process of handling the focus of the UI elements can be a challenge in itself and is quite a ‘culture change’ from mobile. You need to develop the underlying logic of how to highlight focus elements and also to devise and develop the logic of how the user moves between elements and blocks of elements with the 5-key RCU.
Framework shift: Android TV provides the “Leanback Framework” for developing applications that are meant to run on remote-controlled devices. The physical and mental/intellectual differences in the user experience of using a mobile compared to watching the living room TV must not be underestimated.
The good stuff – now here’s the cool part you’ll love:
- Simplified design. Given the fact that your apps are going to be remote-controlled in the TV context, the user interaction is much simpler. Hence the design is simplified, and easier to use for a wide variety of people. Moreover, Google has its own guidelines regarding TV applications, and compliance is necessary if Google Certification is desired. This relates to how the UI shall look and feel, performance benchmarking, etc.
- No screen orientation issues. Yippee, no more handling of orientation changes – this is one major headache removed!
- No hassle with multiple-screen support. No more requirement to create dozens of layouts to support multiple screen orientations and resolutions.
- No battery concerns and no network (data) usage concerns. Set-top boxes (STBs) are pretty much always plugged into the mains power socket, and as the network connection is either wired or Wi-Fi, there’s no data plan affected. So you don’t have to worry about whether a user streams/downloads on mobile data or on the Wi-Fi/home network. This extra always-on stability is quite useful, to developers as well as to viewers.
- The application you will be developing in the TV environment will pretty much appear “exclusively” on the STB. This means it’s not competing with other apps for hardware resources. Instead, the TV app competes with other STB-based tasks and functions, such as middleware, OS processes, and other items that consume memory, bandwidth, etc.
The ugly stuff – it can’t all be good news:
- The TV environment comes with some serious limitations. Some STB devices will run AOSP which means no proprietary drivers and a lot of things have to be implemented “from scratch”.
- You might inherit legacy Android versions. Some STBs you encounter in a TV deployment will run an old Android version – such as KitKat or Lollipop – whatever the latest Android version is. The fact is, if you are looking at a major cable TV or OTT deployment, there may be thousands of devices in people’s homes that run all kinds of out-of-date technologies. This means that your cool APIs won’t be available to the developers, and the latest zippy apps can’t be used by some users. Sorry, this comes with the territory. While many people upgrade their mobile phones obsessively each year, that old reliable set-top can stay exactly in the same spot for ages.
- Hardware limitations: Most STB devices, which can be deployed into potentially millions of homes, have much lower-end hardware components compared with low-end mobile devices. Moreover, an STB does much more than just run Android and your app (eg, it has to scan for available tv channels, transcode analog into digital stream formats, or, record a stream, among other things). All this means there is less hardware resource available, which in turn means the slower performance of your app.
- Less flexibility and code reusability: A typical STB application is custom developed for that particular STB and remote control, all specified by the service provider or operator.
- When developing for an AOSP-based STB there will be a tight dependency on the AOSP / firmware development team since they will provide the drivers and additional APIs missing on AOSP (unlike in the more ‘all-in’ Android TV proposition). In the TV environment, if something needs to be added or changed, or if an API needs to be made available to third-party Android app developers, all these dependencies need to be managed and resolved by AOSP developers. means that there is another dependency outside of your responsibility (as well as beyond your control and possibly even your influence) as an app developer. It’s another area in which, in some cases, you may have to rely on someone else for development and to move your app forward.
Conclusion
We say to our fellow members of the international developer community, rejoice, the Android TV revolution is here and it is transforming the TV industry as we speak! Consumers around the globe are beginning to experience next-generation digital entertainment, and a whole new user journey, on their TVs and mobile devices. We encourage you all to take a closer look at transferring your Android mobile development know-how into multiscreen TV. Yes, there are differences which are good, bad, and ugly. But if you can take it all in your stride, and adapt, developers with expertise in Android can look forward to their innovations being experienced by more people than ever, enabling a new era in TV in viewers’ living rooms as well as on the go.
