Data Persistence

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

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.