HbbTV Development – How to Make an App Compatible on Every Device
Recently we shared our tips for a smooth QA process. We’ve received positive feedback from a lot of people and thus decided to share with you some more of our know how and insights. This time around we would like to drop a few tips concerning the app–device compatibility.
First thing to ensure, when striving for the greatest compatibility, is having the right technology at hand. As there are various versions of HbbTV (1.1.1, 1.2.1., 1.3.1 and 1.4.1), it is crucial to have a television with the oldest version (usually from years 2011/2012), as well as with the newest; and both terrestrial and satellite set-top boxes. And, of course, know their limitations. According to the client’s request for compatibility, it is necessary to create the app for the oldest HbbTV version they require and check it on the newest one. The simplest way is to order TVs from the oldest to the newest version into a test set with known problems and instruct the developers on what they are allowed to do. We are solving this issue with our Playout Kit.
But that doesn’t mean you have to always strictly develop on the ‘lowest level‘. Some older TVs might support HTML5, even though it is not implemented in HbbTV till the version 1.3.1, so you can use several functions without any restrictions. Also note that if the function doesn’t work in the older versions, but won’t cause a crash of the app (e.g. with CSS – a shadow under objects), you can use it. But it is necessary to take into account the proposed UI.
The last tip concerning versions revolves around the know-how. Naturally the developer has to be familiar with the HbbTV and what version supports which CSS or HTML. However, for a full compatibility it is also necessary to go through the OIPF documentation standard.
A special attention is then required by an app with a multimedia player (especially video), as it causes the biggest problems in compatibility. Each player has a set of possibilities depending on the HbbTV standard and what codecs and video format will the client use. Again, the lowest standard decides, e.g. if choosing MPEG Dash, which is supported since 1.2.1, for compatibility with standard 1.1.1 you have to implement also MP4. Also, don’t forget to check the before-mentioned OPIF standard on how the inputs and outputs are defined, as that greatly reduces the amount of the testing time.
The interface and design are of course a very custom matter. Yet, there are some practices that can be generalized – and you have to pay attention to them. Specifically:
- Safe area. The logical resolution of this plane is 1 280 pixels horizontally by 720 pixels vertically, but according to the type of the TV, there might be parts that aren’t visible in the active window. For SONY, it is 20px, for Panasonic 35px. So keep in mind such restrictions.
- Fonts. The basic is font family Tiresias Screenfont (or equivalent), or Letter Gothic for disproportionate fonts. Also, on some TV’s specific fonts can’t be displayed correctly. It can be solved by using downloadable fonts (similar to the Tiresias family), but as they are supported from version 1.3.1., it is a problem for lower versions. Nevertheless, a combination of both approaches is recommended for a full compatibility.
- Transparency. Older technology works worse with transparency, RGBA and transparent .png files, so use these as little as possible.
- Remote control. Be aware of the control buttons and their use, as the models differ from each other. A typical problem is applying some functions to the numerical buttons that are usually switch channels. That is not recommended, as it may disable their main function, unless it is strictly necessary. Another example is a ‘Back’ button, which is often completely missing from the remote and it is therefore advisable to insert this function somewhere into the application by default.
There are three possibilities when it comes to a persistent data storing. The main are: either in cookies or a local storage. Newer TVs have a local storage; if that is not supported, the data are stored in cookies. Usual practice is to use both at the same time to secure full compatibility. The third variant is the safest - each TV with a unique ID stores its data on a specific server, externally from the application itself. However, not every television possesses such ID and it is thus necessary to implement the first two methods.
Each application has a life cycle. It begins with a user that switches to a certain TV channel with an HbbTV signalization. If a condition of autostart is met, there also needs to exist a way out of the application to get the user to the previous state (before they entered the app), including the settings applied before entering the application; e.g. in the case of a keymask setting it is necessary to do a full restore.
Also, making sure some steps are reproducible via alternatives (e.g. if the command ‘destroy application’ doesn’t work, ‘window close’ will solve it) will move your application and its usability to a whole other level.
Generally, the trick to an app compatibility is in a smart combination of possibilities of the newest TVs, with just the necessary interference according to the options of the older versions. It is therefore for the most part a matter of experience. We at Mautilus has more than 10 years of experience in this field and will be happy to help you build the best app possible. Just