Difference between revisions of "Data Persistence"

Revision as of 22:59, 22 March 2008

UNDER CONSTRUCTION --Wayn3w 05:59, 17 March 2008 (PDT)

Sometimes widgets take information from users that should be stored for later. For instance, if a user changes the color of a screen by pressing on it, then when the widget next loads it should still use this color.

Persisting to Chumby Servers: the Chumby API

• persists across Chumby reboots
• may take longer because of network fetches
• a tad more complex

Widgets can can save and restore their parameters by exchanging XML with the Chumby network. When a widget first loads, the parameter _root._chumby_instance_url (_root._chumby_widget_instance_href ?) stores the name of the server that the widget exchanges XML. The flow usually proceeds this way:

• widget construction: request any saved parameters via XML.load (will be notified by XML.onLoad)
• XML.onLoad: read the parameters from the resulting XML, perform necessary actions.

Later, when data needs to be saved to the server:

• widget XML.sendAndLoad

It would be nice to have a function called _chumby_exit:

Persisting Locally: Mobile Shared Objects

This involves using objects of the SharedObject class. An excellent tutorial for the using them is Persistent data: Saving user preferences and game scores. Things to note about them are:

• they are stored in /tmp/pdata, but it is not easily readable
• they will be removed when a Chumby restarts.
• flashplayer does not support shared objects, so this will have to be tested on the Chumby.

General Approach

• Since it uses a callback rather than listener pattern, the handler will not have the context of the instance. hence if the callback needs to invoke a method on an instance, then it will have to refer to an instance that is stored globally.

MTASC Issues

MTASC has an older, incomplete definition for SharedObject. The file SharedObject.as (on Linux stored in /usr/share/mtasc/std/SharedObject.as) will have to be edited to include the following code:

static function addListener(objectName:String, notifyFunction:Function): Void;
static function removeListener(objectName:String): Void;

With this definition of SharedObject, it is not possible to have private data -- that is, data on the shared object that will not persist. This is not a detriment, because in an object-oriented project there will be other places to store private data. Note that this makes it difficult to derive a new class from SharedObject.

Debugging

trace() is your friend.