Create powerful Flash applications with shared objects

Shared objects allow for data persistence in Flash applications the same way cookies allow persistence in Web pages. Learn how to leverage shared objects to create more robust Flash apps.

Macromedia introduced shared objects with Flash MX. Shared objects are useful for storing user preferences, tracking visitor patterns, and storing data between sessions, making them the perfect tool for creating smart Flash applications and custom user interfaces. This article examines the anatomy of a shared object and explains how to integrate them into your own Flash MX applications.

What is a shared object?
Shared objects are similar to HTTP cookies, in the sense that they are chunks of data stored on a user's machine. There are two types of shared objects: local and remote. I'll focus here on local shared objects that are generated by the Web browser's Flash player.

Like cookies, shared objects are used to maintain data persistence. The object data is stored in an .sol file on the user's hard drive in the same directory as the Flash MX player. The files are stored in folders corresponding to the domain that generated the Flash movie.

The breakthrough with shared objects is that Flash can now write to a user's hard drive. In older versions of Flash, developers had to rely on a combination of Flash and client scripting (JavaScript) or server scripting (ASP, PHP, CF, etc.) to generate cookies or server-based text files. They're also easy to create and delete by way of an ActionScript API.

Before trying to invoke a shared object, it is important to check the user's Flash player version. Shared objects are compatible only with Flash 6.0 and higher. The player version may be determined with JavaScript or straight Flash.

Shared objects versus cookies
Since HTTP cookies and shared objects do have many similarities, it's useful to see how they match up. Here is a list of key comparisons.

File size
All Web browsers are designed to limit the number and size of cookies stored on a hard drive. The cookie specs are outlined in the HTTP state management mechanism documents found in RFC 2109. A typical browser is limited to 300 cookies (20 cookies per domain). Usually, the size of a cookie is limited to 4,000 bytes.

Flash shared objects, on the other hand, have no size limitations. However, there is a disk space consideration: If your Flash application wants to store an object that is larger than 100 KB, Flash displays a dialog box for the user to accept or deny the request.

Both cookies and shared objects enforce security based on the sandbox model (local input/output access) and domain-based authentication. For example, Flash is able to read and write data locally only to shared objects. Shared objects can be accessed only by Flash. Cookies are generally accessible with HTML, JavaScript, or VBScript. You can read up more on Flash MX security in the Macromedia white paper.

Cookies can easily be eliminated in a browser and usually have a short lifespan. Shared objects can remain on a hard drive for a good period of time and have no built-in mechanism to make them expire within a stated date and time.

Data types
You are limited in the kind of data you can store in a cookie. A shared object can store a variety of datatypes, including strings, XML, numbers, Boolean values, null values, arrays, and objects. You can also store complex types of data, such as custom class instances.

Shared objects in action
To demonstrate the capabilities of shared objects, I've designed an interactive Flash MX Jukebox. This Web-based application will store whatever music preference the user has. Then, when the user decides to return to the Web site his or her favorite loop will play in the background. All the loops used in this example were created using Fruity Loops software.

I first created the graphical elements (title, buttons) and defined the movie's width, height, and background color. The basic elements needed include a single layer and a single keyframe on the main timeline. I added in the following ActionScript in the first frame of the movie:
// Add the sound clips
myLocal_so = sharedobject.getLocal("sobj");
loopOneObj=new Sound();
loopTwoObj=new Sound();
loopThreeObj=new Sound();

Next, I created a local shared object (called sobj) and three instances of the sound object (loopOneObj, loopTwoObj, and loopThreeObj). Then, I needed to attach (or link) sound loops to each of the sound objects. At this point, I had to figure out whether this is the first time the application has been executed by the user. To handle this, I created a property called first, which contains a Boolean value (true or false). If the user hasn't tried out the jukebox, the application will start soundclip#1 club as a default and loop it 999,999 times:
if (!=1){
_root.loopOneObj.start(0,999999);; }

If the shared object has been instantiated, I check the value of the counter property (which stores whatever loop is the current one). Next, I start playing the loop corresponding to the value of counter. If the user has decided to mute, the music loops and the counter will be equal to zero:
if ({
if ({
if ({

To control the startup and muting of sound loops, I need to add custom buttons on the stage and assign ActionScript event handlers to each one. The code below is for the first play button. Once the user clicks it, soundclip#1 will play and all other sound clips will stop. I've set the custom counter property to 1. If the user decides to leave and then return to the application at a later date, soundclip#1 will start up automatically:
on(press) {

The flush() function tells the Flash player to immediately commit the changes to the shared objects. By default, the changes are made once the player is unloaded:

A similar function is assigned to each of the other buttons, with the appropriate sound clip starting and values assigned to counter. The following code is assigned to the Mute button. It stops the sound clips (if any are playing), sets the counter to zero (indicating that no loops are selected), and commits the changes to the shared object:
on(press) {

A great new feature
Shared objects are useful for developing highly interactive Flash applications, and the core functionality can be tapped in various ways. For example: instead of storing strings in a shared object, perhaps you could store Binary Large OBjects (BLOBs) and multimedia in binary form.

Editor's Picks

Free Newsletters, In your Inbox