dpdk Open Source

Providing data to your flash movie can be done through javascript, through loading data from xml, UrlVariables (post and get) or flash remoting with the actionscript message format (amf), or by passing FlashVars to your movie at embed time in your html page. We are using a software design pattern known as a Registry to be able to have easy access to our externally provided parameters known as FlashVars throughout our application.

One of the main benefits of FlashVars is that they make for easy configuration of your application. Instead of using an xml file or another method, just pass in some flashvars and you’re ready to go. No loading of xml, checking if the load succeeded or checking for IO errors. No parsing of the xml data structure etcetera. Just get your FlashVars and go! We use it for setting paths to external files, the implementation of clickTags in banners is another use case, or for passing in language settings to be able to retrieve the right xml language file (yes, xml has it’s place too, but not for something as simple as this). Another great use case is when you want to mirror sites on different sites (eg: a portfolio site and the live site) where you can then easily pass the absolute paths of your files and communication gateways. There are a multitude of configuration parameters that are potentially unrelated that we can easily pass to the swf movie embedded in the html page.

There are multiple reasons to use a seperate object for controlling access to your FlashVars.
The first is that the default implementation is to use the root.loaderInfo.parameters object, but this is only accessible when you are a displayObject that is both visible and on the displaylist. This is a nuisance because an object really doesn’t want to check if it is visible and on the displaylist before accessing a variable.
Another reason is that it is preferable to make the presence of FlashVars explicit in an accessible object that has some easy methods on it to do some checking for existence and validity of the expected parameters, so we do not have to duplicate this in potentially multiple places in our application.
Yet another reason is that is now we still have access to the parameters, but in a place that we now know is in a valid state (unlike root.loaderInfo.parameters)  and that the parameters are passed to this object so that we can always expect they are there.

The implementation is easy. Every project has a startup class that kickstarts the application. Most probably this is the Document Class in as3 flash projects. This class is visible and on the displaylist when it starts up, and is the best candidate (but not the only one) to make the FlashVars accessible via a single object (and not something as obscure as root.loaderInfo.parameters).

Let’s go crazy with some code:

import nl.dpdk.utils.FlashVarsRegistry;
 
//get a local reference to the Registry
var registry : FlashVarsRegistry = FlashVarsRegistry.getInstance();
 
/*
since this is the class that handles setup,
we know that it is visible and on the displaylist,
so it's safe to pass root.loaderInfo.parameters
*/
registry.setFlashVars(root.loaderInfo.parameters);
 
//we now have a configured object, that was it!
 
//somewhere else, possibly in another class *anywhere* in our application:
var registry: Registry = Registry.getInstance();
var language: String;
//get the language parameter, and do a check first by using a method on the Registry. use default if it's not there.
language = registry.isValid("language") && registry.get("language") != "" ? registry.get("language") : "NL";

Now that was easy. As you can see, we can check if the parameter exists, and we get the value of the FlashVar by passing it’s name as a String to the get() method of the Registry.

So, it’s very easy to use, it’s accessible from everywhere in your application in a uniform and safe way, and it has some convenient methods on it to use it. The reason it’s accessible from everywhere is that the Registry is a variation on the Singleton design pattern. The Singleton design patternallows for global access of data. The Registry variation has some methods to control the data and in this case can be called ‘dynamic’ as it accepts any kind of (String) value. Without falling into the trap of saying a Singleton is good or bad, we just feel that the usage is justified in this case.

For embedding your flash file in an html page while also passing in some FlashVars it’s easy to use swfobject. Here is some sample code:

// flashcheck
if (!swfobject.hasFlashPlayerVersion("9.0.124")) {
	location.href = './noflash.php';
}
//create the flashvars object
var flashvars = {};
//create the parameters object to configure the flash movie itself
var params = {};						
//add some FlashVars														
flashvars.gateway = "http://speelderolvanjeleven.nl/amfphp/gateway.php";
flashvars.language = "NL";
 
params.allowscriptaccess = "always";
params.quality = "high";
params.bgcolor = "#000000";
params.wmode = "transparant";
//embed the swf by using javascript, while targetting a css element (main-flash)
swfobject.embedSWF("witlicht.swf", "main-flash", "100%", "100%", "9.0.124", "", flashvars, params);		
//use for extra features	
swffit.fit("main-flash", 980, 600);

Here is a little disclaimer to wrap it up. By no means we wish to imply that the FlashVarsRegistry is where you should always keep and get your externally passed parameters, other solutions might be better suited for this. But for rapid application development, you really do not want to create a lot of classes just to have a great structure for your application’s configuration data.
In our case, we use the Registry to get the parameters and distribute them to their appropiate places, and just use the Registry in a very small number of places. The usage is justified by having an explicit place to handle your externally passed in data and by the methods that the Registry exposes, as well as it’s safe usage (no runtime errors) in your app.

happy coding!