Principle

Streamezzo frameworks provides straightforward facilities to store contextual data during the application lifetime.

More than only storing some raw text data, the provided features enable to save and restore the context of a scene graph, i.e. the current structure (nodes with their attributes) mounted in memory. Indeed, as all data manipulated within a Streamezzo-enabled Rich Media Application is stored in the current scene graph mounted in memory, the provided features enable to read / write the data from the scene graph nodes, i.e. store the current value of a node attributes, which will then make it possible to restore the same value to the attributes of a node with the same id (DEF).

Such data can be:

• Saved, i.e. read nodes attributes values that are then stored as data in reserved space
• Restored, i.e. read this data from the reserved space then reaffect the values to nodes attributes
• Cleaned, i.e. remove this data from the reserved space, when it becomes useless to keep it

Features

All granted features are updates, i.e. instructions that can be specifed within a RSP to update the current scene graph (just like Insert / Delete / Replace updates do).

A (serviceID, groupID) allows identifying a unique storage area, so that multiple saves can be operated without overriding already saved data when not expected.

• Save: stores a selection (*) of the attributes of specified nodes, contained in the current scene graph
  • serviceID: int intended to identify the application that has stored this data
  • groupdID: int intended to gather stored data as part of the same 'group', i.e. nodes data that must be saved altogether
  • nodes: a list of ids (DEF attribute) for nodes which current attributes values must be saved
• Restore: valuates attributes of nodes contained in the current scene graph with data stored with the Save update; those nodes must have the same id (DEF) as the saved ones
  
  • serviceID: use same value as specified for Save update
  • groupdID: use same value as specified for Save update
• Clean: removes data stored with the Save update
  • serviceID: use same value as specified for Save update
  • groupdID: use same value as specified for Save update

(*) Here are the attributes which value is saved according to the type of node:

When one will need to save a context, he will need to:

• Allocate an id (DEF) to the node which must be saved; it is important to identify if the saved node will need to be restored either only in the current scene (in such case the DEF can be set with a local scope) or in another scene (in such case the DEF must be set with a global scope)
• Trigger Save when needed, listing the DEF values of the nodes to be saved

When one will need to restore a context, he will need to:

• Allocate the exact same id (DEF) - including same scope (local / global) - to the node which must be restored
• Trigger Restore when applicable
• (Eventually trigger Clean when the saved data has become of no use)

Specific notes:

• When the Save / Restore update is executed, only the subset of existing nodes and their related data are stored / restored respectively.
• When multiple Save updates are executed using the same couple (serviceID, groupID), the current Save update will try to store data concerning the list of DEF values specified in the nodes attribute of the current Save update plus the ones previously stored during the last executed Save update.

Example

A typical usage of the Save / Restore clean facilities consists in restoring a menu with its previous selection state when the end-user comes back to this menu, i.e. end-user selected option at position #i in a menu, menu scene is leaved for the next scene (associated to option #i)... end-user navigates within the application... end-user goes back to menu scene, menu is displayed with option #i selected.

In the fairly simple provided sample code below, we illustrate something similar:

• a scene displays a basic 2 items menu and allows selecting either item #1 or #2, then accessing next scene (at this time the selected item information is saved)
• another scene (the one that is accessed from the previous one), indicates which was the selected item on the previous scene (restoring the selection information)

Coupling the code of those 2 scenes as a single scene would enable to address the 'back to menu with selection restoration' use-case.