Saving users’ data with Flash SharedObjects (a.k.a. Flash Cookies)

March 17, 2010

Ever wonder how you can persist data for a user in your Flash SWF applications? The simple answer is to use a local SharedObject or as it is commonly known the Flash Cookie. These objects are stored to the users local machine much like a cookie with it’s access limited to current domain and optional path, allowing you to save data that can be shared between different SWFs on your site if you so desire.

Shared Objects storage on the local computer

The Shared Object is stored in an .sol file on the users local computer. These files are stored in the Flash Player directory of the users profile and much like cookies are accessible only to by SWFs with the same domain and local path. The default size limitation for a .sol file is usually around 100Kb however this can be modified by the user and if more space is required they will have to approve it. Don’t worry to much about that part right now we’ll touch on that later.

Obtaining a Shared Object

To create or obtain an existing Shared Object we utilize the getLocal method. This method returns the Shared Object with the given name and path for the domain. If for some reason the Shared Object could not be created then an error will be thrown, some possible reasons for this would be that 3rd party storage is disabled.

Understanding the getLocal function

The getLocal function takes up to 3 parameters with only the name being required.

name: The identifier of the Shared Object

localPath: The full or partial path to the swf that determines where it is stored locally. By setting this to a generic path that is used by multiple swfs in your domain you can have saved data from one swf be read and used by another swf.

secure: Boolean identifying if the SWF is accessible only over HTTPS. If true then an HTTP request to the SWF will not allow the Shared Object to be created or read from. (default value is FALSE)

To create/obtain a Shared Object with a specified name you would use the following code:

Reading and Writing data to the Shared Object

Now that you have instantiated your local Shared Object you will want to store and read that data you wish to persist across usages of your SWF application. Access of the data stored in the Shared Object is done through the data property. You simply specify the named property and set a value to it or output it into another variable or parameter.

To illustrate lets assume we want to save the Users high score into the Shared Object.

sharedObj.data.high_score = 1000;

If we wanted to read the saved high_score value then we simply would access it the same way:

var highScore = sharedObj.data.high_score;

Write Immediately with Flush

When the SWF application quits or exits is when the Shared Object would normally get written to the local file system. However if you want to save your data immediately you can utilize the flush method. This method will cause the data to be written immediately. If the write could not be performed an error will be thrown, or if the size of the Shared Object is above the the users defined maximum size then they will be presented with a dialog box to confirm/deny the additional space. If this occurs then a pending status will be returned and you will need to listen for a netStatus event to determine if the save was successful. Please note that the dialog boxes minimum size is 215 x 138 and your SWF will need to be larger then this to display the full dialog box.

If your Shared Object has a maximum size that it can grow to you can pass this value to the flush value. What this does is make it so that Flash will ask for the inputted amount of space so that it doesn’t ask with each save as the size of the Shared Object increases.

Erasing your Shared Object

To delete your Shared Object you utilize the clear method. When called it empties the data in your SharedObject instance and will also delete the file saved on the user’s local computer.

sharedObj.clear();

Saving user data in Flash is a relatively simply task. Although you may not utilize them in all applications they can come in handy with games and user settings. Allowing you to present the user with a consistent experience in that application as well as other applications in that domain.