The basics of Flash deeplinking

Posted on April 20, 2009


Currently one of the most common libraries for deeplinking in my peer group is SWFAddress. In this article I explain briefly how deeplinking via Flash works using the principles from SWFAddress as a starting point.

Deeplinking is a hack using JavaScript and Flash’s ExternalInterface

SWFAddress is a Flash / JavaScript / HTML hack. It is quite stable and uses JavaScript in HTML to communicate to and from the browser. At the end of this article I show you the basics to make it work from Flash alone. (See sample here and full code here). As this article only goes into the basic principles, it will not dissect SWFAddress, nor the JavaScript SWFAddress uses to make it work.

Why use a solution like SWFAddress? Main Issue:
Without it the browser does not show where you are in a Flash site

A standard Flash website does not show where you are within that Flash site. So if you want to store a specific page within that Flash site in your favorites, it will simply not work. For sites with deeper content structures, this is a main issue and historically one of the two main reasons (SEO is the other) for clients NOT to use flash.

Main benefits of JavaScript/Flash deeplinking solutions

  1. It allows Flash to alter the URL shown in the address bar (so that it becomes available to the browser history)
  2. It feeds changes in the URL by the user back to Flash
  3. It enables users to store deep links within Flash sites as a bookmark (and share it to others)

Basics of SWFAddress

  1. JavaScript: SWFAddress heavily leans on JavaScript to get and set i.e. the current URL/URI and the document title you see in the titlebar.
  2. Hash+slash-locations: Watch the “#/” it is the key to prevent the page from reloading and simulates fake subdirectories like “/myDeep/Link”
  3. ExternalInterface.addCallback and In Flash 8, Macromedia added a direct way to communicate to JavaScript and from JavaScript to Flash.
  4. URI-to-content-mapping: SWFAddress offers the clean URI in the browser-bar. Next: you need to map this URI to your specific content pages. There are several strategies for that. I will sketch them later here.

Sample 1: an XML content block  (deeplinking in XML content)

  <contentblock URI="my/URI/location">
     <title>My title</title>
     <body>My body text [...] </body>

You get the content by filtering the XML with a matching URI as is used in the browser URL.

Sample 2: an XML file using the URI as file name:

filename: my/URI/location.html

File content of: my/URI/location.html

     <title>My title</title>
     <body>My body text [...] </body>

Flow from Flash to the browser

  1. The user clicks on something in the Flash movie.
  2. The Flash-movie presents the corresponding content block (which has a specific URI like “my/URI/location“).
  3. Via SWFAddress the URI of this specific content block is passed to the browser as a hash+slash location: “myPage.html#/my/URI/location

Flow from the browser to Flash

  1. The SWFAddress  JavaScript listens to changes in the URL.
  2. When this change occurs in the URL, the URI is separated from the URL and sent to flash using the callback function mapped to flash for JavaScript using ExternalInterfaces.adCallBack.
  3. Flash captures the callback and calls the function attached to the callback.
  4. Flash resolves the mapping of the URI to the content in Flash.

Content from one single source

I have seen scenarios where all site content is provided in one single XML. Each content block then is addressed by and linked to via an abstract URI.

Content on demand

In the scenarios I use in general, content is loaded on demand. This means that when the flash movie is loaded and ready, the content itself is not loaded yet. Loading the content will be resolved by using the direct reference to the script or XML file I call on the server. The URI could like this: “#/PHP/myContentPage.php?contentID=34“.


Introducing a link between JavaScript and Flash also introduces a vulnerability. There are relatively many steps happening in JavaScript being dependent of the browser to work. When the hack fails for some reason, the deeplinking will fail as well.

When you check the SWFAddress JavaScript (which is obfuscated) you will find several browser checks to avoid failure.

Deeplinking basis using Flash alone

In principle you do not need JavaScript in HTML to make a solution like SWFAddress work. Even stuff like browser dependent behavior and the related actions to do make it work could be done in Flash.

Below you will find the basic code to get and set the URI from Flash. Blue lines do the work with the browser URL. (Note: IE6 will not always show the adapted URL.)

var myUrl:String;
var myUri:String;

var changeListenTimer:Timer = new Timer(2000);
changeListenTimer.addEventListener(TimerEvent.TIMER, getUrl);

function getUrl(evt:*)
// GET PAGE URL'window.location.href.toString');
        // GET URI
        myUri=myUrl.substr(myUrl.indexOf("#")+2) // Remove the /#
        // GET BASE URL

function onUriInFlashChange(evt:*)
    var url:String =this.url.text+ "#/"+this.uriin.text; // From a textfield
    var request:URLRequest = new URLRequest(url);
    navigateToURL(request, '_self'); // second argument is target