MDBitz Development Resources

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:

try {
    var sharedObj:SharedObject = SharedObject.getLocal( "user_settings" );
} catch(e:Error) {
    // Shared Object could not be created
}

If we wanted to create/obtain a Shared Object that had a defined localPath and was accessible only by HTTPS then we would use the following code:

try {
    var sharedObj:SharedObject = SharedObject.getLocal( "user_settings", "/shared/", true );
} catch(e:Error) {
    // Shared Object could not be created
}

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.

Sample basic example

try {
    var status:String = sharedObj.flush();
    if( status == SharedObjectFlushStatus.FLUSHED ) {
        // Successfull
    }
} catch(e:Error) {
    // Shared Object could not be saved
}

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.

try {
    var status:String = sharedObj.flush( 4096 );
    if( status == SharedObjectFlushStatus.FLUSHED ) {
        // Successful
    }
} catch(e:Error) {
    // Shared Object could not be saved
}

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.

Resources

• ActionScript 3 LiveDocs : SharedObject

FlashVars are a great way to pass information to your swf. The most common usage is to pass along the root path to use when looking up resources or configuration information. These parameters can then be accessed within your application by the use of ActionScript and are a great way to increase the customization and re-usability of your code.

To start things off lets look at a few possible ways to pass FlashVars into your SWF application. The first way is by use of the Object or EMBED tags. This is only for those developers still out there that haven’t started utilizing SWFObject to embed their SWFs into the page.

Object Tag Example

When using the Object tag you need to specify a param with the name FLashVars that has its values set to name=value pairs with an & separating the variables.

<PARAM NAME=FlashVars VALUE="base-url=www.mdbitz.com/&mode=single"/>

Embed Tag Example

To use FlashVars in an EMBED tag you simply define a FLASHVARS attribute with the values set the same as in the object tag.

<EMBED href="mySWF.swf" FlashVars="base-url=www.mdbitz.com/&mode=single" ></EMBED>

Most Flash Developers do not however still utilize the the Object and Embed Tags to display SWFs instead they most often use JavaScript libraries like SWFObject that handle the code output.

SWFObject Example

With SWFObject you simply pass an associated array that contains named values into your embedSWF call, and the library will take care of outputting the correct code.

var flashvars = {baseURL: "www.mdbitz.com", mode: "single"};
		var params = {wmode: "transparent", allowFullScreen: "false"};
		var attributes = {};
		swfobject.embedSWF("mySWF.swf", "mySWF", "800", "200", "9.0.0", "flash/expressInstall.swf", flashvars, params, attributes);

Obtaining the FlashVars in ActionScript 3

Now that you are passing variables into your Flash application you need to obtain and use those values. In ActionScript 3 we need to get the parameters out of the root LoaderInfo object.

var paramObj:Object = null
try {
    paramObj = LoaderInfo(this.root.loaderInfo).parameters;
} catch (error:Error) {
    // Flash Vars could not be loaded
}

The parameters property of the LoaderInfo class returns an Object that can be treated similar to an associated array. All you need to do to get your named properties is:

var baseURL = paramObj["baseURL"];

That is all there is to using FlashVars. You will find that once you start using them it will greatly enhance the re-usability of your applications and also reduce deployment issues from path errors.

While doing research into particle generators for a new Action Script 3 Flash project I am working on I came across the Flint Particle System. This library is an open source project with the goal of creating a base framework that is easily extensible by developers to create their own particle behaviors and effects.

I have just begun to utilize the Particle Framework but currently it appears to be very robust with built in support for both 2D and 3D particle systems. For 3D particle systems Flint has support for both the Away3D and Papervision3D libraries, making Flint a highly versatile tool that can be used across diverse projects.

The main power behind this particular particle system is the clean breakup of functionality into distinct elements. To begin we have 3 elements to a Particle System:

• Particle
  Defines the individual particles within the system.
• Emitter
  An emitter is responsible for the creation and management of the particles
• Renderer
  As the name implies the Render is responsible for rendering of the particles.

With these 3 main pieces you are able to create and manage particles within the system. For further control and manipulation of how the system behaves over time actions, activities, initializers, and zones are used.

• Actions
  An Action defines how the system is modified or how particles act within the system. Some available actions include Gravity, Random Drift, Follow Mouse, and Collision.
• Initializers
  The Initializer is responsible for modifying particles upon creation which can include modifying their initial position, rotation, velocity, and color.
• Activities
  Activities define how the emitter changes over time, the most commonly used one is to have the emitter move with the mouse.
• Zones
  Zones  are used by various actions and activities to define a region of space.

On the official Flint website flintparticles.org you can find many examples and a brief tutorial on how to utilize the library within your own Flash Projects. Once I have  played around some more with the library i will also post some examples here for everyone to see.