Difference between revisions of "Data Persistence"
| Line 9: | Line 9: | ||
== Persisting Locally: Mobile Shared Objects == | == Persisting Locally: Mobile Shared Objects == | ||
| − | This involves using objects of the SharedObject class. | + | This involves using objects of the SharedObject class. An excellent tutorial for the using them is [http://www.adobe.com/devnet/devices/articles/persistent_data.html 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 |
| − | * will | + | * they will be removed when a Chumby restarts. |
* flashplayer does not support shared objects, so this will have to be tested on the Chumby. | * flashplayer does not support shared objects, so this will have to be tested on the Chumby. | ||
=== General Approach === | === 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 a reference to the instance that stored globally. | + | * 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 a reference to the instance that is stored globally. |
=== MTASC Issues === | === MTASC Issues === | ||
| Line 26: | Line 26: | ||
=== Debugging === | === Debugging === | ||
| + | trace() is your friend. | ||
Revision as of 05:51, 17 March 2008
UNDER CONSTRUCTION
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.
Contents
Persisting to Chumby Servers: the Chumby API
- persists across Chumby reboots
- may take longer because of network fetches
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 a reference to the 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.
