May 2, 2019

SmartTV - Behind the scenes

SmartTV - Behind the scenes

SmartTV - Behind the scenes

We love modern smart TVs. CRTs are a thing of the past, now we can simply choose and install almost any application we can imagine. Showmax is one of those apps. Although they may seem like easy, plug-and-play things, they aren’t.

When we decided to write new versions of our smartTV apps, we knew that we needed to deal with a variety of platforms and providers. We started with Tizen, an operating system for Samsung’s TVs. As with other producers, this one provides an SDK that contains an interesting IDE, Tizen Studio. We were excited, so we downloaded it, installed it, and… we hit a wall.

We had a small fight with the SDK, and found out that versions 2.x (which were the most up-to-date at that time) would not work for us. After a little research we decided to try a quite simple solution – downgrading Tizen Studio (in fact, 1.2 is not that bad).

Dealing with Tizen

Usually, when you start to work on a project for a specific platform, you are trying to use officially-recommended tools and SDKs. In our case, we wanted to have a cross-platform code base, so it would not be easy to maintain it in platform-specific IDE. Also, these tools - most of them, anyway - do not support useful external extensions like custom code linters.

Writing web apps for smartTVs does have a few advantages over native solutions. Two that we like:

  • You can test and debug the project on a locally-installed browser, like any other website.
  • There’s no need to install an additional emulator - it’s heavy and doesn’t support all of the features from the physical device.

Web devstack combinations like React, Redux, webpack, and Babel, are increasingly popular - and we like handy solutions like watch and update (known as “Hot Module Replacement”). But, with the previously-mentioned tools for smartTVs, things look a little bit different. To test even a simple change on Tizen, we need to deal with a few more things:

  • Make the change and bundle
  • Build the project to a wgt file (Tizen web application format)
  • Remove the previous version of the package from Tizen Studio
  • Import the freshly-built wgt package
  • Connect to the previously-added TV via Connection Manager
  • Export the imported project to the TV

Note that Tizen is available in a few versions on multiple platforms, and during the import you have to manually choose the correct version. The default selection is actually wrong.

the exception occurs when we try to resend the app to the physical TV

In our experience, some older Tizen versions have a problem with uninstalling the previous application. In some cases, the application has to be uninstalled from the TV manually and then sent to it again.

Every single time, click, click, click…

Annoying, right? Luckily for us, most of the SDK provides some form of CLI tools (e.g. Tizen, sdb), so we can find commands that work, put them all together into a smart-build script, and enjoy the results of our work much faster across all TVs. With a single command, we can simply debug our app on TVs and enjoy Web Inspector.

Debugging a debugger

The Web Inspector dev tool makes the life of every front-end developer much (much) more bearable. As it happens, such tools are also available on smart TVs.

Most TV makers use WebKit engine (or it’s fork) to run web applications - the same engine that is implemented in few of the most popular desktop/mobile web browsers. So, as a front-end developer, you probably know the tool from your daily routine and expect some sort of standard behavior from it. Well…sorry. Regular Web Inspector lets us use Console to write some part of the code and run it directly in a browser. What could go wrong?

Post image

Each version of Tizen (and other, similar systems) is delivered with a specific WebKit version – usually the most recent available during a release. And, then it isn’t updated. If we run Web Inspector attached to the TV application, it will load its scripts from an instance installed in the TV. So, debugging some piece of code on a TV from 2015 with older WebKit while we have a 2019 version and installed newer Chrome/Chromium on desktop may cause some difficulties. Even the simple Enter key does not work there.

Inspect the Inspector

Luckily, Web Inspector allows you to debug it manually, so it’s simple to find out that the callback function for the Enter key is looking for the keyIdentifier property in the provided event data. It was changed during WebKit development, and now the property is simply called key - which means you can fix it by yourself.

keyIdentifier -> key. Could not be easier. Saving this change should solve the issue.

Pimp my remote

Testing and playing with the app on physical devices requires a few more TVs than we usually have in our homes. Different production years, firmware updates, and more lead to situations like this:

The main technology still used in home TV remote controls is infrared light. It’s invisible, and customers expect it to have the widest range possible. But, when you press the power button (or any other button), a signal is sent to pretty much every TV in the remote’s range - causing interference and, in a lot of cases, utter confusion. To handle this, we needed to somehow limit remote ranges. A piece of dark paper and tape proved to be quite helpful.

Not the proudest prototype

It is possible to use a bluetooth remote - but unfortunately, it’s not provided with every TV. Also, phone applications have limitations - for example some of them have to be in the same WiFi network as the TV you want to connect to.

Sometimes the simplest technologies can fulfill our expectations, but we weren’t satisfied with this sort of temporary solution. We were looking for something a bit fancier - and the 3D printer delivered.

3D-printed remote control funnel

At some point, even physical remotes are not enough. When you have to walk for a few hours just to make sure a button on the remote has been pressed, well, that just doesn’t work.

We found a nice third-party tool, The CandyBox, created by Suitest. It lets us easily manage the TVs by providing collision-free infrared signal targeting via infrared blasters connected to devices. That way, you can use an application on your phone like a normal remote control. It basically sends a request over a network to the box. When The CandyBox receives the request, it sends a signal to the infrared blaster, and that’s it. No more wild dancing around the TV wall!

Wrapping it up

Front-end development for desktop browsers has become much easier in the last few years with modern frameworks and standardization of supported technologies and languages. Of course it’s still not perfect, but now we do not need to worry too much about the differences between browsers and their engines - not like we did five years ago.

The same thing is happening in the mobile world with things like Progressive Web Application as an idea slowly becoming the standard. But smartTVs are different. With breaking change firmware updates and new models released each year, it’s not exactly a given that things that worked well before will continue to work. Development for SmartTVs is still challenging - just the way we like it.

Share article via: