Another look at the development of applications for smart TV

Despite the fact that Smart TV appeared on the CIS market and began to gain popularity quite a long time ago (~ 2010), the technologies / approaches for developing applications for them are far behind the times, sometimes wrapping around with pleasant memories from 7th or earlier years.

I would like to share the results of my research into the field of developing applications for SmartTV, highlight some of the shortcomings and, of course, talk about the solutions found and just cool things.

What are applications for smart TV?

In the "application for Smart TV" I put the definition of a web application, thus tailored specifically for TV. By and large, the differences are not so much, for the most part it is the incompatibility / absence of some API on different devices, besides, we should not forget that the TV is not a computer and its resources are more limited.

Key (as for me) differences:

• Limited resources.
• Special navigation.
• Mostly unexpected behavior on different devices.
• A bit confusing testing methods.
• Unexpected deployment options and application updates.

If the first three points are a bit understandable and many have already encountered them, then the remaining ones have a number of problems that everyone must solve on their own. Such as running tests in the application environment on individual devices, options for updating and running the final application.

But I want to tell about the first two.

Why?

There are so many great tools for developing web applications, but most of them were not created even with the idea that it would be used on TVs. On the other hand, the tools designed for televisions are not very suitable for developing web applications: some have lagged behind in time, some have been developed in the best traditions and practices of shaggy years or have been moved from other languages ​​without thinking about the current stage of development of front-end development. Perhaps it is painful to realize, but, damn it, it's 2017 in the yard!

I’m very close to healthy (or unhealthy) minimalism, I don’t like, you know, to develop using a 10kb library to inflate to a megabyte when developing hello world 'a. Of course, we can safely say that there is a lot of cool functionality, but I consider it more correct to keep only used.

But it's obvious! - you say. Not for everyone, not for everyone, I saw what it consists of and how some very popular applications work.

Thoughts

• When it comes to web application performance, the first thing that comes to mind is virtual-dom , the optimal algorithm for mutation of the tree of elements. It would be nice to apply this practice to develop productive applications for the TV.

  
  
• Navigation , a stumbling block of almost all developers of applications that are controlled by the console.

It looks something like this:

I would very much like to get rid of / reduce the number of references to the movement of buttons when developing applications, avoid selectors and create heaps of listeners for moving from element to element.

• To the above, I would like to add a concise syntax for describing such elements and at the same time, not to lose control over them, for example, like this:

 <div focusable={true}></div> <div></div> <div focusable={true} onEnterx={() => alert('Ola!')}></div> 

And so that all this was transparent and in itself worked and was updated with mutations - that would be cool! Is not it? So, I have already implemented all these ideas and then just give an example of use.

Sample application

I will use babel for a nice jsx syntax control goes to spatial-virtual-dom wrapped in cakejs and some qunit for ease of demonstration.

It may seem a bit specific, I hope, I managed to uncover all the spells in the comments:

 /** @jsx h */ //  /** *  import {s...} from 'cakejs2-spatial;  `npm i cakejs2-spatial` */ const {spatial, Cream, create} = cake; /** *      */ const h = spatial({ keys: { LEFT: 37, RIGHT: 39, UP: 38, DOWN: 40, ENTER: 13 }}); /** *  ,     */ const app = create({ element : document.getElementById('application') }) .route('*', 'rectangles'); Cream.extend({ //  _namespace: 'rectangles', render : createRectangles() }); function createRectangles () { let isFocusable = true; return function () { return ( <div className="rectangles"> <div focusable={isFocusable} className="rectangles--left"></div> <div focusable={isFocusable} className="rectangles--left"></div> <div focusable={isFocusable} className="rectangles--right"></div> <div focusable={isFocusable} className="rectangles--right"></div> <div focusable={isFocusable} className="rectangles--right"></div> <div focusable={isFocusable} className="rectangles--left"></div> <div focusable={isFocusable} className="rectangles--left"></div> </div> ) } } 

Sample Application (CODEPEN)

Testing is difficult, we need shortcuts (PR velcom):

 QUnit.test('Spatial test', function( assert ) { const rectangles = app.tree.children[0]; assert.ok( 7 === app.tree.sn._collection.length, 'Should spatialize 7 elements'); assert.ok( null === app.tree.sn._focus, 'Should not focus any of them'); app.tree.sn.focus(rectangles.children[2].el); assert.ok(rectangles.children[2].el === app.tree.sn._focus, 'Should focus third children'); app.tree.sn.move('left'); // element floats left assert.ok(rectangles.children[3].el === app.tree.sn._focus, 'Should move focus left'); }); 

Sample Tests (CODEPEN)

Results

• The size of libraries does not exceed several tens of kilobytes, in a compressed form ~ 10 (depends on the deflation)
• Productive mutations, here is the implementation of js-repaint-perfs for the cake.
• Transparent implementation of navigation, out of the box.
• For add-ons, there are events from navigation and DOM itself.

Links

• Implementing TV remote control navigation (MDN)
• cakejs2-spatial (NPM)
• spatial-virtual-dom (github)
• Demo of another application using this stack
• Contact for questions (Twitter)

I apologize for the readme. Thank!