Best Practices - Overview
When developing for the ActiveVideo CloudTV™ H5 platform, it is important to understand which of the standard development and design practices should be followed, as well as to be aware of some things you may want to completely avoid. Following the best practices mentioned here will help avoid pitfalls, create clean and reusable code, and optimize performance. Some of these apply to web design and design for low bandwidth situations in general, while others are specific to developing for the CloudTV™ H5 Platform.
Designing for TV
Despite being web-based, applications for CloudTV are not the same kind of applications that you would find on any website. Applications must be navigated through the use of a remote control as opposed to a mouse and a keyboard. Event listeners must be used to trap key presses by the remote and the user interface needs to respond accordingly. The use of CSS focus states enables a user to keep track of their on-screen location, as the platform does not come equipped with a floating cursor, such as a computer would use.
Data entry is something that should also be limited with CloudTV applications. Most remote controls do not have full alpha-numeric keyboards, so the use of an onscreen keyboard is required for text input. Anyone who has used an onscreen keyboard will attest that they can be cumbersome when entering large amounts of text.
Screen resolutions for TV are considerably limited when compared to those found on personal computers. One benefit for the design of applications on TV is the exact resolutions are known ahead of time and can be developed for and tested against. Having the style sheets either scale with the application by the use of percentages on objects or applying different style guides for the various resolutions are both acceptable solutions.
See 'Dev Guide: Designing for TV' for tips on design best practices including: navigation, color, resolution, typography, audio/video, and writing.
Embedded Objects / Third Party Browser Plug-Ins
Runtime Generated Graphics
Do not use OpenGL, WebGL, 3D transforms or any type of object or control that would normally utilize thegraphics processing unit (GPU) with a standard web browser. CloudTV runs without the aid of a GPU and, if graphics are rendered in three dimensions, the effort on the CPU is increased exponentially which, once again, does not scale to the level required. Currently there is no 3D graphical work around, so you must continue to use rasterized images (.jpg, .png, .gif) and well-known and reliable illusions and methods used with them, to create depth.
Also avoid the use of the WebKit Canvas element. When using standard graphic display options like <img src=img.jpg> or <div style=background: url(img.jpg)> every macroblock drawn on screen is cached in the system and can be recreated without having to re-render itself. However, when canvas is used and a graphical area is updated during runtime/realtime, that image cannot be cached and every subsequent time that the same area is drawn, the engine is forced to redraw those same macroblocks each time. Thus, Canvas is not an efficient use of resources and greatly limits the scalability of the platform.
Testing and Debugging
Applications should conform to web standards and can be developed mostly using Chrome or another HTML5 compliant WebKit browser. However, you should always test your application on either CloudTV Player or on the client device (cable box, blu-ray player, roku, etc.) CloudTV Player can emulate the same client you are deploying your application to, and should always be referenced whenever erroneous behavior is discovered and reported for support. Proper and constant testing will ensure that your application functions correctly, appears the same, and performs at the quality you expect.
Developing for CloudTV is similar to developing for mobile platforms. You should use efficient coding techniques whenever possible to avoid overloading the CPU and to have your application render and animate as good as possible in low bandwidth scenarios. This will allow a higher number of concurrent sessions per Stitcher. For details on this, see
- Avoid writing to HTML elements if they already contain that same information — this would cause the platform to rerender those elements.
- Use display:none instead of visibility:hidden or opacity:0 — again, this will avoid unnecessary rendering.
- Preload UI graphics (use ResourceHandler library in AVHTML Library).
- Use CloudTV Player's 'Dirty Area' feature to analyze what is updating on your application and to identify any unexpected updates that could be improved. To turn on Dirty Rects in CloudTV Player, select View > Dirty Area. It is important to use this feature because it may highlight differences in how rendering occurs in the CloudTV Platform.
- When scrolling through a list, avoid other updates to the screen like animating advertisement banners. This will minimize the amount of the screen that is being updated at one time.
- Allow the Platform to cache external resources. The platform will do this automatically as long as you do not prevent this behavior by adding a random query parameter to your API queries (for example, in www.myexternaldataxyz.com/data.json - do not add ?param=xxyy.) One of the only exceptions to this would be when you are accessing an asset with the same file name that is being refreshed on a regular basis. In this case, you would want to pass the parameter to assure not hitting a cached version.
AVHTML Library and Project Structure
We offer an optional framework, AVHTML, simplifying coding common tasks such as logging, tracking, sending messages to clients, querying funnel, etc. You can use the default project structure provided by the Application Project Template, including avconfig.js, avlocalize.js, and overriding config files to take maximum advantage of the AVHTML Library. For more information on using the framework, see ActiveVideo Framework Libraries (Optional) - Overview.
Always include a debug screen that can be accessed via a secret code sequence. This will allow users to report the application version number or other important information when reporting bugs. If an issue with your application arises in the field, you will want to be able to determine the exact version number of your application that the user has access to, in order to debug.