Streamezzo S.A. - All rights reserved
Copyright 2001-2010
Best Practices - Introduction
This article provides you a guided tour of the best practices for designing a Rich Media Application with Streamezzo Rich Media Solution. You will find here an overview of the key aspects to take care of when developing your own appealing rich media applications.
Here you will be introduced with general good practices and recommendations on the following design keys:
- Application content optimization, to minimize the transfer, computation and rendering delays
- Dataflow optimization, related to streaming and incremental updates
- Portability and Adaptation, related to device heterogeneousness (screen sizes, texts display…)
- Cache management on both client and server side
- Errors management on client-side
- Debugging (process, emulation, logs…)
Application content optimization
The content of an application can be optimized in order to minimize the transfer, computation and rendering delays. This can be achieved for example by taking care of de-activating useless (non-visible) elements in the scene graph, avoiding useless transformation of elements by providing pre-transformed items, or decreasing the frame rate when applicable.
A work can also be done on media assets (i.e. bitmaps, video and audio streams) by setting properly parameters like the size, the compression, the number of colors, the transparency or the bit rate. The possible optimizations for these items are listed and detailed in Streamezzo Authoring Guidelines, a document provided within Streamezzo Workbench Developer.

Dataflow optimization
To allow early decoding and scene construction while loading, Streamezzo Solution offers Rich Media progressive download. A Rich Media Scene is composed of a serie of Access Units (consistent data packets). Each Access Unit can transport instructions enabling to add, replace, and delete content from the currently rendered scene; this is the incremental update principle. Thus the developer is able to send first the structure of the scene and then add content to it, for example send a table border and then progressively add the images into the table. Thank to this solution the end-user gets an early visual rendering without having to wait for the complete scene to download. As Access Units can be time stamped, advanced scene construction or even animation can be achieved.

Moreover, mobile networks usually offer a real bandwidth smaller than the theoretical one. You should be aware of this point and count on the real bandwidth value for your services requirements.
Portability and Adaptation
The devices on which you wish porting your application can differ from each other in many ways: different graphic specificities (screen resolution, system fonts), different capabilities (system, memory, decoders), different inputs (keypad, joystick, touchscreen).
Streamezzo Rich Media Technology provides easy ways to manage these differences with the help of a few tips. Note that the porting issue must be taken into account at the beginning of the project.
The item having the most significant impact on the global design of the service is the screen resolution, commonly called “screen size” in our documents. We usually sort various screen sizes into families. You then will need to be able to:
- Describe and organize your assets and in a second step specify several sets of assets (per screen size family)
- Adapt and layout in a generic way those assets (no magic number in the RSP code)
- Set some device-specific properties also without having to modify deeply the RSP code
Streamezzo Software Suite proposes several tools to achieve these steps:
- Skin management: A Skin references all the static assets of the application: bitmaps, text, colors, and shapes. A Skin is defined for a given screen size and is localized (i.e. can vary upon languages).
- Layouting & Adaptation: The Streamezzo Layouting module will allow you to specify the page layout. The page layout is a set of containers; each container has a logical ID and its own adaptation rules. The actual size of the containers is computed at request processing and then, instead of having size computations in the RSP code, you can refer to containers size and positions.
- Device fine tuning: Once your page is fully set up to adapt itself as well as possible, 90% of the job is done. Now we all know that there are still some specific device adaptation that may be required in order to adapt some identified variables of your page to one specific device. To make this phase as easy as possible and to avoid having to modify the RSP code on a device by device basis we propose to externalize those properties in some properties files. One can define one property file per device.

Cache management
Cache is used to store application content for a specified period of time and enables to retrieve it quickly during application runtime. Cache can be located on the client side or the server side.
Storing the distant scenes of the application in the client cache will avoid the transfer delay from the server to the device. Cache managed on the device does not depend only on the time-to-live parameter but also on the space available on the device.
Cache managed on the server offers two levels. Server cache level 1 is meant to store in a database the entire response to a given client request while server cache level 2 is meant to store distant assets used by the application. The distant scenes of the application stored in the server cache are stored as they are generated so that the scene generation delay will not impact next accesses to it.

Errors management on client-side
The content can dynamically handle the errors raised by the device system on the client side. Such errors can be handled one by one (more than 20 specific error codes listed), by error type (System errors, Network errors, HTTP network errors) or in one unique way for all errors. Once an error is trapped the content can display an appropriate pop-up or message to the end-user, or adapt the application behavior appropriately (redirection, for example)...

Debugging
An application can be debugged during development or at runtime. During development, Streamezzo Workbench Developer includes an integrated emulator and facilities that will help you debugging the application.
- The client emulator renders the application scenes and enables interacting with them, for a given device.
- The Scene Graph view enables checking the real-time scene graph structure
- The cache views enable checking the current client cache content and queue
- The log view enables checking operations performed on client
- The console enables checking operations performed on server
Workbench Developer offers 2 types of emulations:
- Local emulation (Emulate): Workbench Developer acts as both the client and server
- Distant emulation (Run): Workbench Developer acts as the client and requests a real Rich Media Server instance, as a device would do

Get started!
Following this guided approach, anticipating all potential issues and evolutions related to your rich media application, will lead to the best user experience and a fully evolutive – at the lowest cost – solution.