Flash

This tutorial is going to talk about setting up your flash microsite on the web server and how to handle any changes to the site. So let’s say your project is finished and the client is happy; you slap the swf up on the server with SWFObject and an HTML file and that’s it right ? Right ? No. That’s never it.

All web projects evolve, some more, some less, but the amount of times I have created a solution on the server and have never ever changed can be counted on the fingers of one hand. In fact, I could count them without the hand, because the answer is ZERO ! Nada, Not a single one. It just doesn’t happen, ever.

So what’s the big deal, make the changes, slap em up, refresh your cache and bingo, new working version. But here’s the rub, you can’t guarantee the client or the customers are going to do that. In fact with browsers like firefox that automatically cache, you can instead guarantee the opposite. And you can’t just expect them to figure it out. You need a solution. And just to top it off, let’s imagine another scenario, you send up a new solution that has added some new functionality, but theres a huge glaring bug in it that managed to slip past your QA process. Same thing, all those visitors who accessed the buggy version are now cached on it, you need some mechanism to roll back the solution to the previously working version.

The following set-up is a simple solution that I have used hundreds of times, it works with swfaddress deep linked sites, it works with roll back. It just works.

For starters we always use a loader swf – the smaller the better, say about 5k optimum. Just because you have a loader doesn’t mean you have to let the visitor know theres a loader, it’s just a mechanism to solve cacheing.

Because we are evolving the site, the main SWF file, let’s call it ActualSite.SWF is not good enough, so we are going to assign a delivery number to the file, now we have ActualSite23.swf for the 23rd evolution. The way we know how to discover this unique file name is by loading a file from the server that contains it. You don’t have to use an XML file, a straight text file will do, but I prefer XML as it means I can add other stuff to it if I want to. Before you get too excited though, the XML file itself can get cached to so we need to employ a cache BUSTER mechanism. This means making the browser imagine that it is a new file every single time it loads the file. We do this by adding a HTTP GET variable to the URL of the XML file. As in filename.xml?cacheBusterVariable=231154, here the number is a time stamp of when the operation occurs delivered programmatically via action script. Then the next time you load it it will be filename.xml?cacheBusterVariable=231543 as the time has increased, therefore always loading a new version. But hang on, I hear you say, why all these extra hoops, can’t we just use this mechanism to always load the SWF fresh each time. Yes, we could indeed, except that cacheing isn’t evil, we WANT to cache as much as possible so that when a user returns to a site they have less waiting.

Here are the steps that occur now:

  1. The HTML file loads up SWFObject
  2. HTML then creates a SWFObject object in the page
  3. SWFObject checks to see if the customer has the correct player
  4. If the player version is correct, the no-flash DIV content is replaced and we load the Loader.swf
  5. The Loader.swf loads very quickly and immediately loads the site.xml file with a dateTime cachebuster
  6. The site.xml file reveals the name of the latest project SWF e.g. ActualSite23.swf
  7. A loader loads in the ActualSite23.swf (optionally giving %Load)
  8. We add the content of the loader to the stage and lose the loader resources
  9. The ActualSite23.swf is on the screen and the onStageAdded event is fired.

NB: Another real advantage of this is that the site will not suffer any down time during upoad, the XML file is the only aspect that is changing and because its so tiny the chances of anyone failing to load the site during the upload is virtually zero.

Now lets look at our two situations mentioned earlier. First, we have an evolution to the file, we increment the delivery number so we now have ActualSite24.swf (which has of course been fully tested and QA’d on a seperate server – more about this later) Here are the steps required to “up” the evolution.

  1. Send the new ActualSite24.swf to the server
  2. Edit the site.xml file and place the new delivery number in it
  3. Send up the new XML file
  4. Test the new evolution to make sure it is working live

That’s it. But wait, while testing it you spot a new bug out of nowhere, what to do, panic? Run around the room cursing Vishnu and evil ways (insert deity of choice there) No, all we need to do is perform a rollback which is simply:

  1. Edit the site.xml file and place the previous delivery number in it
  2. Send up the new XML file
  3. Test the older version to make sure it is working live. Done

Can you ask for anything simpler?

Are there any pitfalls? Well one minor issue is the cache buster URL will not work in the player if you are publish previewing. Either comment out the bit of code that adds the new ending when testing locally or if you wanted an elegant solution you would pass up a local flashvars variable in the HTML file SWFObject to say use the cache buster and if that variable didnt exist (like when testing just in player) don’t use the cache buster extension.

Now, finally I am just going to mention quickly another extension to this method, sandboxing. I did ask you earlier if you had fully tested the new evolution, and you may have an identical setup development server with exactly the same configuration, in which case fine and dandy. If you don’t have that, then you need to test from the live server. For a sandbox configuration all you need is what we described above already – a seperate loader swf sandbox.swf, which loads in a seperate XML file – siteSandbox.xml and a copy of the HTML file which references the new loader SWF, call it sandbox.html.

Now the process has a few extra steps, for the new evolution of the mainsite24.swf. First we update the siteSandbox.xml file with the new delivery number, then we upload the new mainsite24.swf and the siteSandbox.xml to the server and test away.

As soon as the tests are finished and we are happy, then all we need to do is update the site.xml with the new delivery number and hey presto, it all works.