Application Development Guidelines

Short description

Any application created for STB MAG is an ordinary, normal HTML-page. On this page using JavaScript, the process of pressing remote control keys and keyboard keys takes place as well as the execution of the corresponding actions. JavaScript API methods are used to work with video.

Application representation as HTML-page allows you to perceive work with an application as work with the usual site. It also allows you to use a standard set of tools for web development (any specialized IDE, DevTools, etc.).

JavaScript API

General description of how to use API and work with the player, an example of a simple application and partly outdated JavaScript API documentation is contained in document JS_API_MAG200_(Rev_1.20).pdf. It is applied to the STB software version prior to 0.2.18.
The description of JavaScript API methods applied to the STB software version from 0.2.18 is here.
Documentation for work with MAG set-top boxes is here.

Characteristics of used Software 

The app runs on a set-top box in the browser, powered by WebKit engine. Since working with a set-top box requires a special approach, the engine is modified to provide the necessary functionality at maximum speed. As a result, some of the new technologies and global objects that are presented in modern desktop browsers are unavailable (e.g., classList property, flash technology) or are partially supported (HTML5).

Application Requirements

It is crucial to ensure stable operation and good interface speed when creating the application. That's why all new applications must pass the mandatory testing for compliance before they are placed in the application directory. This is due to the fact that today a number of popular set-top box models have very limited resources (in comparison with PC). As a result, in the absence of optimization application can run very slowly or not work at all.

JavaScript code optimization

At the outset of application development, you must carefully approach the choice of used frameworks and libraries. Generally, libraries/frameworks are designed to work in desktop browsers. They help to rectify deficiencies that arise when working in different browsers. Also, libraries/frameworks help a lot in developing the application and provide convenient universal wrappers and abstractions. Overhead costs for such flexibility are practically invisible to the PC, but it is extremely painful for a number of set-top box models.

As an example, let's take a closer look at such high-level and the multi-purpose library like jQuery.
Though these same problems exist in the majority of modern frameworks and other libraries. Almost every method invocation of this library involves the execution of multiple functions. These functions are intended to maintain the necessary level of abstraction, a convenient functionality as well as to prevent some errors and to resolve issues that arise when working in different browsers or different versions of browsers. In practice, the difference in speed and amount of involved code when searching for a DOM element looks like this:

  Comparison

Given the specifics of the future application platform, such functional is redundant and could be completely replaced by faster methods. As an example, let's take a look at this comparison table: http://youmightnotneedjquery.com

It is also an option to use our framework for application development:
https://github.com/DarkPark/stb (ready to use application that demonstrates the work of the main components https://github.com/DarkPark/stb-demo).

Directly in the code, it is important to optimize algorithms.

For example:

• To use "use strict" directive. This will not only help to optimize the code but also alert to possible errors. Directive operation description.
• The use of results caching of working with DOM, if in perspective is still expected to work with the obtained element. Thus, there is no need to re-search the DOM tree for the previously found element.
• Completing the loop by using a break if the result reached. Frequently, the further loop work is meaningless and useless resource consumption.
• Combine several "if" conditions with the help of logical operations, where it is possible, to avoid unnecessary checks.
• Use querySelector, children, parentNode, addEventListener and many other features provided by the browser. Usually, they have a far greater speed than their multi-browser and multi-version js counterparts. Example.
• Use "for" or "while" loop instead of "forEach" for large arrays (> 1000 elements). Since in some cases, the absence of costs for function calls can lead to a significant increase in the speed in a large number of iterations.
• Use closures not to pollute the global scope as well as to facilitate the work of the garbage collector to clean up unnecessary data. Thus, it increases free set-top box resources.
• Use in code strict comparison. This eliminates the need to perform type cast on every comparison operation: "a === b" instead of "a == b"
• To create DOM element use document.createElement method instead of assigning html into innerHTML property.
• Use for mass adding of DOM-elements intermediate DocumentFragment. It will release from changing the whole DOM every time you add a new element. After adding to DOM, DocumentFragment will disappear, and its children will appear instead of it.
• Use ready-made sets of classes instead of the style.* property changes in run-time.

To view the style rules and tips on writing the code that we use, follow this link https://github.com/DarkPark/jscs

Interface

When creating an interface, you should turn attention to a few things that can affect the speed and smoothness of its operation:

• Browser redraws the page only after the completion of the js thread of execution. For example, if you make changes to the loop in the styles of an HTML page, then visually they will be applied only on after the termination of the loop, all at once.
• When you run intensive computations, the speed of the application can drop. If at this moment the animation is on the screen, it will freeze or glitch. Complex animation can lose its smoothness even at light load.

General optimization

In addition to the code is just as important to optimize resource usage. Optimized images should be used in the graphic. Too large or heavy images require a lot of processing resources; in turn, it will cause a drop in the application speed. It's also advisable to use original image size in the application because the scaling also takes time and resources. It is very undesirable to use single-pixel disseminated images for backgrounds.

The browser needs time to load and analyze the necessary resources when the application loads. You can reduce this time if you compress the code and CSS in the release version. It is also advisable to use a modular approach (CommonJS) of building applications that would allow you to break the application into the logical blocks. It is also advisable to combine your CSS files.

With a large number of small pictures (such as icons), you can combine them into sprites or, if they are simple enough - in a separate font.
In general, if you reduce the number of loading files, it will reduce the startup time of application in the browser.