Deploying multiple versions to match the player.

If you're using Flash MX 2004 (Pro or not) and targeting Flash Player 6, you might want to consider publishing two SWFs: one for 6, and one for 7. Doing this will make it possible to provide optimized performance for almost 100% of your audience. I'll give you a quick how-to in just a minute, but firstly here are the sample files so you can follow along at home. You can also see a live demo, by visiting my trusty card sorting application page.

What was the inspiration for this article? Almost a year ago, I came across an extensive comparison of player perfomance statistics over at Oddhammer. Going through the data, two things became clear: Flash MX 2004 export provides an automatic speed boost over files exported with MX; and Flash Player 7 prefers files of its own native version.

Don't change a thing, just publish with MX 2004

When MX '04 first came out, I remember reading somewhere that you'd get a little performance boost just by opening an .FLA and publishing back out to F6 player. According to the Oddhammer tests, it seems to be true.

7 likes 7

Though many of the differences are miniscule, Flash Player 7 will perform better with SWFs that are published specifically for F7 player. When compared to SWFs compiled with the original MX IDE, the difference is huge. All the more reason to go back through and at least publish those old .FLAs from MX 2004.

The Quick How-To

For the rest of this article, I'm going to assume you know how to publish different versions of a SWF. The task we'll be performing is to filter for the user's available Player, and use server-side scripts to serve up the best matching file. There are several different ways to attempt to detect the Flash player, and none of them are perfect. In this case, I'm using a modified form of the "Flash Detection Kit" (FDK) that Macromedia provides. It uses old-school Actionscript to detect the Flash Player version. Instead of just looking for a simple "yes/no" minimum version, I've decided to categorize the site visitors into four groups, based on the Flash Player they have:

• No player, or less than 6.0.40


• At least 6.0.40, but less than 6.0.65 (needed for Flash Remoting support on all browsers)


• At least 6.0.65, but less than 7 (send them to a .SWF that's been optimized for .65)


• 7 or higher (if they've got 7, of course they get the .SWF for 7)

Your specific needs might differ, but most of the apps I work on use Flash Remoting, so 6.0.40 is my cut-off. While I was in there customizing the FDK code, I chopped out the bits I'm not using. It makes it a little less flexible, but customizing is still pretty quick. Let's look at just the first few lines, where we set up the variables to represent these four different groups:

//the url that the visitor should be sent to if they do not have the required version of Flash.
noflashURL = "noflash.php";
//-------------------
//the urls that the visitor should be sent to if they have the required version of Flash.
//In our, case it's a single script that will interpret the "pv" GET variable and load the appropriate SWF.
goodURL = "flash.php?pv=640";
betterURL = "flash.php?pv=665";
bestURL = "flash.php?pv=7";
//-------------------

As you can see, I've set up four different variables to represent the different URLs. Again, feel free to modify and use the sample files for your own needs. If you're not comfortable using PHP or some other server-side language, just create four different HTML files that embed your different .SWFs.

So if you've spent weeks or months (or years, anyone?) coding a Flash app that reaches a wide audience, take the extra 30 minutes to ensure that all your visitors have the smoothest experience possible.  And if you're already doing something similar and have some thoughts to share, you know where the comments are...

One Last Warning

I hope it goes without saying that you'll want to test the various different .SWFs. I don't have the definitive list of differences, but I'll share one F7 difference (a.k.a. BUG) that tripped me up. There were a few instances in my code where I was appending a string to a variable that was previously not declared. Something in a FOR loop like this:

myString = myString + " hello";

In F6 players, the final output was correct, but in the F7 player, the word "undefined" was actually prepended to the string! The text sent into my database looked like:

undefined hello

Now maybe somebody out there has a documented explanation, but the point is -- make sure you get the archived players from Macromedia's site (or use a fancy player switcher) and test your different versions!