Results

Over the last year, we have been doing a lot of work with Flash Lite 3. In the past we have shown off some of the applications we have built including Finetune Mobile, and Mightyverse, but this time,  I am going to spend a bit of time talking about development challenges. I am going to try and spread this out over a few posts, one topic at a time.

Optimizing Shared Object Data:

In both of the applications we worked on in Flash Lite 3, storing local data was a requirement. Both apps have to cache data such as previous search queries and results, and make this data available from session to session of usage. When most Flashers walk up to Flash Lite 3 and discover that they only have a maximum of 4k of local storage data, they often get a little frustrated. In one case I had to go back to Mightyverse and explain that we could not cache search result data because of the limitation.

Once you get over the frustration of this limitation, you realize you have to adopt a very conservative approach when dealing with Shared Objects. Every byte counts, and there are some really simple ways you can save space for more data.

First off, avoid storing objects where possible, instead try and store basic data types such as string and numbers individually in slots. There are some cases where this is not possible, but if you can avoid it, you should. Serializing an object adds extra overhead and takes up critical space.

For example, if I am trying to save a search term(my name), I might try and save it as an object like so:

[code lang="actionscript"]

so.data.querydata={query:"Tony MacDonell"}

//95 bytes;

[/code]

This is handy, becuase if I have other data about the query to save, I can add it to this object. In the Mightyverse case, I might want to save the language to seach in with it:

[code lang="actionscript"]

so.data.querydata={query:"Tony MacDonell",language:"en"}

//110 bytes

[/code]

When you are dealing with only 4k of space though, you may want to think twice. If you save the two strings as different slots, the size is smaller:

[code lang="actionscript"]

so.data.querydata="Tony MacDonell"

so.data.language="en"

//100 bytes

[/code]

We can still tear the size down even further by shortening the actual slot names. They are taking up space on disk as well:

[code lang="actionscript"]

so.data.a="Tony MacDonell"

so.data.b="en"

//85 bytes

[/code]

This helps a lot but it can quickly make your code unreadable. if you are working on a team, unreadable is something you certainly want to avoid. The way to get the best of both worlds is to let your SWF file take the memory hit instead of the serialized data by using constants (the AS2 simulation of them at least):

Somewhere in the class that is writing the shared object define constants that you will use for your slot names:

[code lang="actionscript"]

static public var QUERYDATA:String="a";

static public var LANGUAGE:String="b";

[/code]

Then use them when assigning the values to the shared object:

[code lang="actionscript"]

so.data[QUERYDATA]="Tony MacDonell"

so.data[LANGUAGE]="en"

//85 bytes

[/code]

Keeps things as small as possible, but still readable. If you are dealing with a lot of data that needs to be stored, these tiny savings will add up. Using this technique will squeeze every last drop of extra space that you can get out of Shared Objects for mobile development.