Designing Multiplatform Smart TV Applications part 2: Problems & Solutions

In my previous blog post here I wrote about designing multiplatform Smart TV applications by drawing the big picture and giving you some generic ideas what needs to be considered when apps are written to Smart TV platforms with a view to support multiple different platforms with a single codebase. This time I’m diving deeper into the details of the implementation, trying to give you an idea of the actual steps needed to be able to support all the platforms without the need of countless if-elses, duplicated code and huge amount of testing for every small change.

Getting Started – Plan carefully!

One of the key things for success is the planning: recognizing the problematic parts, the pieces of code where separation is needed for the different platforms and designing your code so that as much of it can be kept common as possible. It is also important to plan the platforms you’re targeting and learn the related details and limitations for those: the browser versions, Javascript and CSS limitations, video playback, DRM restrictions and so on.

Spending time planning your app structure will pay off in the long term. You will need to spend a lot less time on doing same changes for many parts of the code, solving issues where something works on one platform but does not for others and testing everything for each platform separately when you have planned your app so that you can have as much common code as possible and only the parts that are necessary to differ between platforms will do so.

Using Javascript frameworks like React or Vue may help in structuring your app but keep in mind that many TV platforms use an older browser version and may not support for example latest ES6 features, so using the very latest tech stack is not necessarily the way to go – be prepared for compatibility and performance issues with the latest framework versions at least. Build tools and transpilers / compilers like Babel will help with the ES5 compatibility but underlying runtime issues may sometimes be very tricky to hunt down and solve.

Platform-specific implementations

While you should be able to keep a big part of your code common to all platforms, there are a couple of things that might need a platform-specific implementation regardless of how well you plan your application. Some of these things require a native API implementation and there is no alternative available while especially for the video player there are common options too which can be utilized depending on which platforms you are targeting.

For strictly platform-specific things, like finding out platform capabilities / preferences (UHD capability, Mac address, TV Model etc), handling remote control keys and native virtual keyboard and testing network connection status, it’s a good idea to come up with some common interface implementation for everything and set up / detect the platform you are using in the start of the app. That way, you can keep all your platform dependent code in one place and have all the UX and functional code as platform independent as possible. This also enables you to add new platform implementations later quite easily since you do not need to find every possible place of the code where you need to add special handling for the new platform.

Having said that, the more extensive and complex your application grows and the more platforms you’ll get onboard, the more likely it will become that you will at some point need to have some ifs to handle certain parts of UX and functional code differently for some platform or TV model. You can choose to be perfectionist with your app structure to a certain point, but my suggestion is to find the right balance: sometimes spending countless hours on trying to create a perfect app structure to support all platforms can be counterproductive if you aim to save time and money by only having a single codebase to maintain.

Video Player

Video player is probably the biggest area of your app where you need to think about the platform dependency. Most platforms have their own “native” solution for playing videos but many of them also support a generic MSE / EME-based HTML5 video player on some level. And then there is a wide range of 3rd party players, both free / open source and commercial solutions which are usually based on MSE / EME framework.

Choosing the player is not necessarily a straightforward task and depending on the platforms you want to support you may end up with multiple players especially if you are going to stick with the free alternatives. Commercial solutions may provide a larger scale of supported devices and better support for the incompatibility issues but regardless of whether you are going for free alternatives or commercial solutions on your player selection, you will need to consider the platforms you want to support, the video formats / DRM you have at your disposal and the features you will need (live streams, multiple audios, subtitles etc).

The process of selecting the player(s), the combinations of working video formats, DRM systems and features for each player and all the possible limitations and issues you may face with players on different platforms is way too broad subject to deal with here and is also heavily dependent on the environment you are going to be working in, so it would be difficult to even write a definitive guide. However, our experts at Sofia Digital have a vast experience on both implementing apps with different players and testing many player solutions and we are happy to help you with our experience.

Handling browser limitations (CSS, Javascript etc)

Whereas the previous areas I’ve discussed in this blog are more a question of planning & preparing for implementing your app, this chapter is more hands-on about the issues you may face due to working with older browser environments and what to do to fix and avoid them. The two major parts where you are likely to come up with these issues are JavaScript and CSS, so those are the areas we are going to concentrate here.

Firstly, it is essential to understand that the browser versions in TV devices are often 1-2 years older than the device itself and browsers versions are not often updated at all during the lifespan of the device – the device may get software updates for several years, but the browser version will stay the same. So, if you want to support 5-year-old devices, you may need to deal with the limitations of 7-year-old browser versions. The older the devices you want to support are, the more limitations and issues you are likely to get of course, but even the quite recent devices may still have significant limitations for the latest web technologies, CSS tricks and other things you might want to be able to utilize in your app.

As far as the JavaScript goes, there is a quite clear separation of things that should work and things that might work but is not guaranteed to do so. In short, ES5-compatible code will almost certainly work even in the oldest devices you would think of supporting nowadays whereas running ES6 code on TV browsers is more or less likely to cause issues. However, you don’t necessarily need to try to write your whole app with ES5-compatible code – you can write your code as you please and use tools like Babel to make sure the code you will be running on TV gets converted to ES5.

While tools like Babel will take care of the ES5 compliance for the code you are writing, it won’t help you with functionalities and methods that are missing from the old JavaScript engines. When you are dealing with older TV browsers, at some point you are more or less likely to end up with some structure or mechanism that just isn’t there. Luckily, nowadays someone usually has already ended up with the same problem before and written a piece of code to patch this deficiency, a polyfill. With modern development platforms like Node, polyfills are very easy to find and use and there aren’t too many things in modern JavaScript that you can’t patch with one. However, keep in mind that each new module and polyfill is going to add size to your app so you shouldn’t add a bunch of polyfills just for the sake of being able to use all the latest JavaScript gimmicks.

So, there are ways to go around the issues on JavaScript side in most cases, but how about CSS? That’s unfortunately a bit trickier area. There are naturally many ways of doing the same thing for CSS and many times you can just find an alternative way for something that doesn’t work but especially if you need to deal with devices from the mid 2010s, you will probably end up with some CSS thing that just can’t be done with all the TVs you want to support. If it is something that is essential part of the UX and just cannot be left out for the TVs that won’t support it, you may need to find some other ways of implementing it.

The ways to solve CSS issues differ depending on the use case but they often involve the use of images. However, using a bitmap image like PNG will more or less take away the advantages of CSS, being able to dynamically change colors of the elements etc. and require multiple images for the same element. And of course, adding images to your app will again increase size and memory consumption of the app.

One good option we’ve come up with is to use SVG. It’s an old technology which means it is well supported by even the oldest browsers and SVG elements are small and lightweight. Naturally, rendering performance for SVG depends on the platform and capabilities of its browser engine but we have not come across many devices where performance would be a problem when using SVG.

Testing & QA

While good planning and having a wide knowledge about the limitations of devices you’re running your app in will help you a lot in developing your app and get a result that is working in almost all HTML5-based platforms, you just can’t get away without comprehensive testing on actual TV devices. No matter how much you read the specifications and how well you try to follow all guidelines for writing an inter-operable app, only testing on the real devices will eventually reveal all the possible issues and incompatibilities. And this needs to continue for the whole lifespan of the application, too: bringing in new functionalities and making significant changes without testing it on TV devices is a recipe for disaster – you will eventually end up with more and more problems on customers’ devices and more and more contacts to your customer support.

Here at Sofia Digital, we are blessed with a test laboratory of well over hundred different TV models for all the major brands as well as many lesser-known ones. This makes our developers’ life much easier since we can use the devices to immediately test what we’ve developed as well as our team of testing experts to do larger scale testing & verification. If we run into a problem with any of our apps in the field, we can easily look for a similar TV model from our lab and reproduce the issue, making it much easier for the developers to fix it.

If you do not have the possibility to set up your own testing lab, we are happy to help you and introduce our testing lab and team of testing experts to you. My colleague Juha Joki, our Head of Testing & Certification Services, will be writing a complete blog post about testing Smart TV apps a bit later but don’t hesitate to contact us immediately if you want to hear more about our testing services and the test laboratory. Read more about our testing services »

About author

My name is Tommi Järvinen and I’m currently working at Sofia Digital as a team lead for Smart TV development teams implementing video-on-demand applications for variety of platforms for our customers. I have over 20 years of experience in TV application development in different roles and I have been involved in Smart TV application development from the early days of Smart TV apps.

Join us

Are you interested to become a Smart TV developer? We are currently looking for experienced developers to work on new projects, develop our products, participate in platform development and architecture design. JOIN US!