Quick Tip: iPad-Proof Your Flash Website

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.

Introduction

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.

(One may argue that, even not being able to play Flash animations, iPad is more open toward JavaScript, but unfortunately that’s not the case. The majority of JavaScript-animated sites don’t play well on iPad. Test any of these ten JavaScript animated websites on your computer and then on iPad to see what I mean.

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.”

For this tutorial, I prepared a simple JavaScript-animated web page to serve as backup. iPad is capable of playing the animation moderately well. Creating iPad-friendly JavaScript animations is beyond the scope of this tutorial, but you can find some useful information about it on the home page of the $FX() JavaScript animation library (and you are also welcome to explore the source code of the JavaScript-animated page we’ll be using as our backup).

Note: to allow the JavaScript-animated page to play when uploaded on your server you will also need to upload the 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.

The <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.

AC_RunActiveContent.js is a JavaScript file that was still widely used only a few years ago. Some programmers still working with Flash CS3 Professional may still use it even now.

The code embedding the swf file using AC_RunActiveContent.js may look like this:

<script type="text/javascript" >
AC_FL_RunContent('codebase','http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0','width','800','height','580','align','middle','src','FlashWebsite','quality','high','bgcolor','#ffffff','name','FlashWebsite','allowscriptaccess','sameDomain','pluginspage','http://www.macromedia.com/go/getflashplayer','movie','FlashWebsite' );
</script> 

There’s also a line of code within the tag of the page that may look like this:

<script src="Scripts/AC_RunActiveContent.js" type="text/javascript"></script>

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.

AC_RunActiveContent.js file was a workaround that allowed users to skip that bothersome click and display the active content right away, by the means of generating the html tags within the JavaScript file. That file is typically located in the Scripts folder in the same directory as the HTML page where the swf file was embedded. Not to go into too much detail, the AC_RunActiveContent.js file is called via the AC_FL_RunContent function, and the attributes and values are passed to the file in pairs: ‘width’, ’800′, ‘height’, ’500′ and so on. You do not need to include file extensions with the names of swf files, the JavaScript file does that automatically.

Using ufo.js

UFO (an acronym that stands for Unobtrusive Flash Objects) is a JavaScript file used since 2006 for detecting versions of Flash Player and embedding swf files into HTMl pages. It was created by Bobby van der Sluis.

The code for embedding a SWF file into an HTML page with ufo.js may look like this:

<script type="text/javascript">
		var FO = { movie:"FlashWebsite.swf", width:"800", height:"580", majorversion:"8", build:"0" };
		UFO.create(FO, "container");
		</script>

The reference to the JavaScript file within the <head> tag may look like this:

<script type="text/javascript" src="Scripts/ufo.js"></script>

The arguments of the ufo.js are self-explanatory. The file was very popular, but is currently deprecated.

Using FlashReplace.js file.

FlashReplace.js is a lightweight (2.1 kb) JavaScript file created by Robert Nyman.

The code for embedding a SWF file in an HTML page using FlashReplace.js may look like this:

<script type="text/javascript">
    FlashReplace.replace("container", "FlashWebsite.swf", "Flash Website", 800, 580);
</script>

Obviously, as is the case with AC_RunActiveContent.js and ufo.js files, you will also find the reference to the JavaScript file within the <head> tag. It may look like this:

<script type="text/javascript" src="Scripts/FlashReplace.js"></script>

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.

swfbject.js was created by Geoff Stearns, Toby Boudreaux and Bobby van der Sluis. It is currently (2010) the most popular and widely used JavaScript library for detecting versions of Flash player and embedding swf files into HTML pages.

The code for embedding a SWF file in an HTML page using SWFObject.js may look like this:

<script type="text/javascript"><!--
			var so = new SWFObject("FlashWebsite.swf", "FlashWebsite", "800px", "580px", "9", "#FFFFFF", "high");
			so.write("container");
// --></script>

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.

The reference to the JavaScript file within the <head> tag may look like this:

<script type="text/javascript" src="swfobject.js"></script>

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 the tag:

<script src="Scripts/AC_RunActiveContent.js" type="text/javascript"></script>

with this line:

<script type="text/javascript" src="Scripts/swfobject.js"></script>

We have now created the reference to the SWFObject library.

Let’s locate a code that looks like this:

<script type="text/javascript" >
AC_FL_RunContent('codebase','http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0','width','800','height','580','align','middle','src','FlashWebsite','quality','high','bgcolor','#ffffff','name','FlashWebsite','allowscriptaccess','sameDomain','pluginspage','http://www.macromedia.com/go/getflashplayer','movie','FlashWebsite' );
</script> 

We’ll select that bit of code and erase it. What we have now is the empty <div> tag:

<div id="container">
</div>

Below that tag, let’s paste the following:

<script type="text/javascript"><!--
			var so = new SWFObject("FlashWebsite.swf", "FlashWebsite", "800px", "580px", "9", "#FFFFFF", "high");
			so.write("container");
// --></script>

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.

Let’s add two more arguments at the end of the series of arguments within the parentheses of the main function call. The first argument should be empty, just the quotation marks: “”, and the second argument should be the path to the backup non-Flash web page we want to redirect the iPad visitors to: “./JavaScriptWebsite.html”

The complete bit of code with the two new arguments added should look like this:

<script type="text/javascript"><!--
			var so = new SWFObject("FlashWebsite.swf", "FlashWebsite", "800px", "580px", "9", "#FFFFFF", "high", "", "./JavaScriptWebsite.html");
			so.write("container");
// --></script>

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!

Note: “./JavaScriptWebsite.html” is the local path to the JavaScript-animated backup page we use in this tutorial. That path will allow us to test the redirection locally as well as on the server. Working with your own projects, you can set the absolute path to your backup html page instead of the local path, or a local path to any directory or subdomain where you may choose to host the backup page.

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:

<script type="text/javascript"><!--
			var so = new SWFObject("FlashWebsite.swf", "FlashWebsite", "800px", "580px", "1000", "#FFFFFF", "high", "", "./JavaScriptWebsite.html");
			so.write("container");
// --></script>   

Don’t forget to save the file.

Now let’s open the FlashWebsite.html in a browser and take a look at the title bar of the web page. Instead of saying “Flash Website”, it should say “JavaScript-Animated Website”, and the last part of the URL should be JavaScriptWebsite.html instead of FlashWebsite.html. Congratulations, our redirection is working: the ultra-advanced animation you see in your viewport is done not with Flash but with JavaScript. It should look and behave like this.

Let’s reset the version value back to “9″. The code in the FlashWebsite.html should again look like this:

 

<script type="text/javascript"><!--
			var so = new SWFObject("FlashWebsite.swf", "FlashWebsite", "800px", "580px", "9", "#FFFFFF", "high", "", "./JavaScriptWebsite.html");
			so.write("container");
// --></script>

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:

• FlashWebsite.html
• FlashWebsite.swf
• JavaScriptWebsite.html

Upload the Scripts folder containing swfobject.js and fx.js files to the same directory on the server (to remind you, swfobject.js is the file that enables swf embedding as well as redirection, and fx.js file is the one that allows you to create and play JavaScript animation used in the backup web page which is suitable for being played on iPad).

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

Here it comes, the moment of truth! Fire up your iPad tablet and access the FlashWebsite.html page uploaded to your server. Voilà! You should see the JavaScript-Animated mockup page instead of the Flash page. We’ve just iPad-proofed a Flash website.

Conclusion

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!