Principle

Streamezzo framework provides straightforward facilities that enable, when accessing a new Rich Media scene, reusing all relevant Rich Media data that is already available on device (i.e. mounted in memory) and retrieving only the necessary extra data (accessed locally on device or downloaded from server): only the incremental dataset can be loaded then injected into the current Rich Media structure.

Using extensively such feature enables:

• Optimizing the client-side processing time: reusable data is kept in memory, no more relevant data can be removed from memory, only extra data is loaded in memory
• Minimizing the amount of data to download from server (when accessing a remote Rich Media scene): only the extra data is transfered, so the latency related to the network traffic is reduced to the minimum

In the end, the end-user will experience the shortest possible delay when accessing the new Rich Media scene.

Feature

In order to specify a Rich Media Streamezzo Page (RSP) as being appended to the current Rich Media content, one simply has to activate the append mode in the header tag:

Note that by default, i.e. if append mode is not explicitely set to true, this mode is not activated, so the newly accessed Rich Media scene data will completely delete the current Rich Media data mounted in memory, i.e. start from a "blank page".

Once the append mode is activated, one will have to consider how to manage the previous Rich Media content in which the new Rich Media scene data will be injected into, i.e.:

• Remove no more relevant Rich Media content, using the Delete update
• Update still relevant Rich Media content that needs to be adjusted, using the Replace update
• Add the extra Rich Media Content, using the Insert update

Important note: In order to manipulate (i.e. delete, replace or insert) something somewhere in the current Rich Media content one will have to refer to a given node; in order to make it possible for the newly accessed Rich Media scene to reference such node that is present in the current Rich Media content, one must specify a DEF (id) value for it and specify this DEF with a global scope, meaning it will be encoded as is (for optimization purpose, an automatic encoding is applied to local DEf values, for a given Rich Media scene, which makes them not accessible from other scenes).

Designing all scenes (RSP) considering their possible interactions (the defined navigation among them, so how they can be "stacked" one over the other) is key to ensure once a new Rich Media scene is accessed the resulting aggregated Rich Media data remains consistent, at anytime.

Typical example

A usual matter is to consider an application header and footer as having the exact same display - and eventually the exact same related interactions - along the whole application usage. In such case it is convenient to load the corresponding Rich Media content only once and reuse it when accessing the next Rich Media scenes.

Considering the simple storyboard displayed above, the applicable design would consists in:

• Loading the header and footer data in the first accessed scene (main.rsp); here it is even better to have this scene stored locally on device for instant access (as long as it is applicable to keep it static), so only the data corresponding to the incremental part of the other scenes (supposed to be dynamic) will be downloaded from the network
• When accessing the Electronic Programming Guide (epg.rsp), this scene will:
  • clear out the useless data (i.e. from "main.rsp" simply the logo, from "video.rsp" simply the video, in the present example)
  • inject the extra data (i.e. the EPG part)
• When accessing the video (video.rsp), this scene will:
  • clear out the useless data (i.e. from "epg.rsp" simply the EPG, in the present example)
  • inject the extra data (i.e. the video part)

Here is the commented corresponding RSP code (Workbench Developer project available for download at the botton of this page):

main.rsp

epg.rsp

video.rsp