In this tutorial you will learn how to use SWFObject script to set up automatic redirection from a Flash website to a non-Flash backup website when it’s viewed on an iPad.
Final Result Preview
Here’s a very simple mock-up of a Flash website we’ll be using in this tutorial. If you try to access that page using iPad you won’t be able to see any content.
And here’s the final result we’ll be working toward. if you access it with iPad you’ll be able to see the animated page.
When the wind of change blows, some people build walls, others build windmills.
– Ancient Chinese proverb
I think iPad is a great device, even though I can understand why the introduction of the Flashless tablet made quite a few people mad. I admit it did make me mad at first: just before iPad appeared in my local Apple store I finished a Flash website I considered my personal masterpiece, and I was taken aback when, trying to open it with iPad, instead of my ultra-cool Flash animation I was redirected to the backup non-Flash site I set up “just in case”. I confess it took me some time to adapt my mind to iPad, but gradually I’ve learned to believe that, like all pioneering works, it had to break out of the comfort zone, and I guess I’m cool with that.
Of course what helped me to arrive at that philosophical attitude was the number of people who hired me to set up similar redirections for their existing Flash websites. They either couldn’t afford to, or didn’t want to replace their fancy, well-designed Flash sites with simpler but more iPad-friendly ones, so the option of setting up automatic iPad redirection to a simpler, pure HTML site appealed to them.
We’ll have to wait until HTML5 is fully implemented to see the new Internet where third party plugins like Flash Player gradually lose its importance. In the meantime, the release of the iPad tablet has created a new temporary niche in web development: iPad-proofing existing Flash websites. There are thousands of excellent Flash websites out there that could benefit from such service; it’s a great work opportunity for guys like you and me.
There can be many different ways to iPad-proof a Flash website, some better than others. This tutorial offers just one possible simple solution. So let’s get down to business.
Step 1: Prepare the Backup Website
It could be a complete non-Flash website containing the HTML version of all the content copied from the Flash site, or just a single web page with only basic information and a message to the visitor, something along the lines of “you are viewing our website on a device that doesn’t allow Flash content to be displayed. To access all the features, please open our website using a computer with the latest version of the Flash player installed.”
fx.js file located in the Scripts folder among the downloadable files for this tutorial.
Step 2: Flash Website Source Code
We need to find out what code was used to embed the SWF file of the original Flash website into its HTML page. We can do this by opening the page in the browser and selecting the View Source option. Alternatively, we can open the page in any text editor or specialized HTML editor.
The snippet of code that embeds a SWF file in the HTML page is easy to recognize within the source code. Activate the Find function and search the page for “swf”. Doing so will reveal the name of the swf file embedded in the html page. The code surrounding the name of the swf file is the code that embeds it in the html page.
SWF files can be embedded in an HTML page in a number of different ways. Describing them all would make this tutorial endless, so if you’re curious you can just Google it. I’ll only mention some of the most popular ones.
Using HTML tags
Basic HTML tag-based code for embedding a SWF file may look like this:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="800" height="580" id="FlashWebsite" align=""> <param name=movie value="FlashWebsite.swf"> <param name=quality value=high> <param name=bgcolor value=#FFFFFF> <embed src="FlashWebsite.swf" quality=high bgcolor=#FFFFFF width="800" height="580" name="FlashWebsite" align="" type="application/x-shockwave-flash" pluginpage="http://www.macromedia.com/go/getflashplayer"></embed> </object>
Chances are, that Flash site was made a while back: from the codebase attribute of the object tag we can see that the SWF is to be played by the 6th version of the Flash player.
The code is mostly self-explanatory, it’s very clear what parameter does what. One thing to mention is that as you can see, for some seemingly mysterious reason most of the parameters are indicated in the code twice. This is easy to explain: the code targets two different Internet browsers separately.
<object> tag with all its attributes and parameters targets Internet Explorer. The
<embed> tag targets the currently deprecated Netscape Navigator (that browser ignored the object tag). Hence, the repetition of the same information.
I should also mention that classid attribute of the
<object> tag tells Internet Explorer that it should load the ActiveX plugin if it’s not installed; pluginpage attribute of the
<embed> tag tells Netscape Navigator to display the link to the plugin page.
Using AC_RunActiveContent.js file.
The code embedding the swf file using AC_RunActiveContent.js may look like this:
There’s also a line of code within thetag of the page that may look like this:
The purpose of the inclusion of the AC_RunActiveContent.js file was the change made by Microsoft Corporation to Internet Explorer browser in 2006. As a result of that change (brought about by certain legal matters known as “Eolas patent problem” and not directly related to technical aspects of web programming), the visitors who opened Flash websites using Internet Explorer had to click the embedded content before being able to see or interact with it.
The code for embedding a SWF file into an HTML page with ufo.js may look like this:
<head> tag may look like this:
The arguments of the ufo.js are self-explanatory. The file was very popular, but is currently deprecated.
Using FlashReplace.js file.
The code for embedding a SWF file in an HTML page using FlashReplace.js may look like this:
<head> tag. It may look like this:
As you can see, FlashReplace.js is really easy. The first argument is the name of the HTML tag whose content is to be replaced with the swf file; the second argument is the name of the swf file, the third argument is the arbitrary id you can assign to the object you’re embedding, and the last two arguments are the width and height of the SWF file.
Using swfobject.js file.
The code for embedding a SWF file in an HTML page using SWFObject.js may look like this:
The snippet of code you just read is a very basic example of how the swfobject.js may be implemented. The code may be much more complex. For more information, check out this swfbject.js tutorial and consult the developers documentation.
<head> tag may look like this:
Step 3: Redirect to the Backup Website
If the existing Flash website is using SWFObject.js to embed swf file, you’re in luck: we are going to use SWFObject.js type of embedding to set up redirection to the non-Flash web page. If any other kind of embedding scenario is used, we’ll have to erase the old code from the HTML page and replace it with the SWFObject embedding. We are going to use SWFObject to redirect iPad visitors to the backup non-Flash website.
For the purposes of this tutorial, we are going to use a training page that has the SWF file embedded using the AC_RunActiveContent.js file. If we open the FlashWebsite.html page in a browser, we’ll see the familiar SWF file embedded in the page.
Let’s open the page called FlashWebsite.html in any text editor or any specialized HTML editor.
We should remember or write down the important information about our SWF file, such as its name (FlashWebsite.swf in our example), width (800), height (580) and background color (#FFFFFF).
Now let’s replace the line that references the AC_RunActiveContent.js file in thetag:
with this line:
We have now created the reference to the SWFObject library.
Let’s locate a code that looks like this:
We’ll select that bit of code and erase it. What we have now is the empty
<div id="container"> </div>
Below that tag, let’s paste the following:
Note that the argument in parentheses for the single added parameter (
so.write("container")) matches the name of the empty
<div> tag: “container”. That argument tells the browser where to place the Flash content. The swf file will be embedded inside the empty
<div> tag marked with the id “container”.
Note: the fifth argument in the parentheses of the SWFObject function, “9″, refers to the major version of the Flash player. When it’s of no particular importance, I prefer to give browsers some slack and to not demand the laterst version of the Flash player, so I set it here to 9, even though the current version today (2010) is 10.
Let’s save the HTML page and open it in a browser. It should look like this.
So far, nothing seems to have changed. The Flash animation played when embedded using the AC_RunActiveContent.js file, and it plays in quite the same way now, being embedded with swfobject.js file. If we tried to open that page with iPad we still wouldn’t see any content.
The complete bit of code with the two new arguments added should look like this:
The first, empty argument we’ve just added is called
xiRedirectUrl, and it’s used by SWFObject script to redirect users who complete the ExpressInstall upgrade. We are not using the ExpressInstall here, so we leave the argument empty. The second argument, called
redirectUrl, is used by SWFObject to automatically redirect the users who do not have the required version of a Flash player installed – which is exactly the function that we needed all along. iPad tablet doesn’t have ANY version of Flash player installed, so it qualifies!
Step 4: Test the Redirection Locally
Before uploading the files to the server, we should test redirection locally. To be able to do that, we’ll simulate the iPad by setting the version attribute of the SWFObject to a non-existing version of the Flash player. Let’s go wild and set it to a 1000 (that version of the Flash player should be available sometime around 3000 A.D. if things go well at Adobe).
The code should look like this:
Don’t forget to save the file.
Let’s reset the version value back to “9″. The code in the FlashWebsite.html should again look like this:
Make sure to save the file again.
Step 5: Upload Files to a Server
Using any FTP client software, let’s upload the following files to a selected directory on your server:
You do not have to upload the AC_RunActiveContent.js also located in the Scripts folder to your server, even though if you’ve accidentally done so, that file would in no way interfere with the performance of all the other files you’ve uploaded.
Step 6: Test the Redirection with iPad
You’ve just learned one of possible ways to iPad-proof an existing Flash website. There are many ways in which that goal can be achieved, and not all of them involve automatic redirection. I’d like to ask you all to share your ideas about the subject of iPad-proofing Flash website in the comments to this tutorial. Thank you for reading!