sharedObject question .. 1 or multiple ?

[Applauz78]

Just wondering whats better to do..

Have 1 shared object for my app to hold various variables... or have a seperate shared object for my needs. 

eg. Shared Object for Highscore .. Shared Object for Achievements ..  Shared Object for Settings

Thoughts ?

[Colin Holgate]

It’s an interesting question, shared objects have a default size of 100kb, but I’m not sure if that is per sharedobject or per app. Hopefully you can keep below 100kb per app anyway.

I choose to have separate shared objects, but each of those might do more than one thing. The kinds of things I track are user progress, what help screens they’ve seen, are they a first time user. I just find it easier to have separate files than to have one app file that I then have to extra the data from. But, for tracking help I have one file, and not one per mini game.

[Spacorum]

I personally prefer to save separated shared objects. One for the configuration of the app itself. If it was a game, I would set scores on a different one. And token information (to keep Twitter/Facebook users permanently connected) could also be stored this way. 

This is the function I´m using to save different values on different shared object files:

static public function saveSharedObject(fileName:String, soNode:String, soContents:Object):void
{
     var so:SharedObject = SharedObject.getLocal(fileName);
     so.data[soNode] = soContents;
     so.flush();
}

How to call it:

static public const SHAREDOBJECT_SETUP:String = 'soSetup';
static public const SHAREDOBJECT_TWITTER:String = 'soTwitter';
static public const SHAREDOBJECT_FACEBOOK:String = 'soFacebook';
UtilitiesPaths.saveSharedObject(ApplicationLibModel.SHAREDOBJECT_SETUP, 'useSounds', applicationMobileLibModel.useSounds.toString());

It´s quite clean for me. The first param is the name of the shared object file (I store them in constants). The second one is the name of the variable to store on that file. The third one is the value of the variable (in this example, its a boolean variable binded to a checkbox that enables or disables app sounds).

[Colin Holgate]

Here’s a sharedobject tip:

When iOS gets low of available storage sharedobjects and other ways to save data will fail. You should put flush() into a try/catch. so that your app doesn’t crash.

What you then do on error is up to you. I’ve using sharedobjects to know if the user has got to a given level. If that fails it makes users stay on level 1. So, if there is an error I unlock all of the levels.

You could choose to show a warning to the user, to tell them that storage is low, if you want them to clear some space to make the app work properly again.

[Spacorum]

Never thought about that possibility. I´ll better show up a popup message on a try/catch if the flush() method fails due to low storage, as you said. Thanks, Colin!

[Colin Holgate]

The other thing that fails it reading the sharedobject. It doesn’t cause an error that crashes the app, but it does give you null values for your stored data. That’s when I decide to unlock levels.