Programming Flex 3: Chapter 20, Embedding Flex Applications in a Browser
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9

Managing New Flex Application Builds

It is important to remember that when you embed Flex applications in HTML pages, web browsers will likely cache the .swf files. That is both advantageous and disadvantageous. The upside is that because a Flex application gets cached, users will not have to download the .swf file upon subsequent visits to a site. However, the downside is that when you deploy updates to the Flex application, it is possible that users will still see cached versions instead of the new version.

One of the simplest and most effective ways to deal with this caching issue is to append a variable to the name of the .swf file that you are embedding and increment that variable value with each new build. This simple strategy will ensure that users can use cached versions of the application until you deploy a new version, and at that point they will be forced to download the new version when they next visit the site. To add a variable to the .swf file reference you should add a question mark (?) and a name-value pair following the name of the .swf file. For example, if you normally reference a file as example.swf, you could instead reference the same file as example.swf?build=1. When you deploy a new build, you need only update the build variable such that the reference is now example.swf?build=2. This way, you don't have to change the name of the .swf file (simplifying build scripts and versioning), but you still can address the caching issue.

Section 20.2: Integrating with Browser Buttons and Deep Linking

Web browsers are designed primarily to render HTML content. Traditionally, web sites and web applications were built around the page metaphor whereby each page was a unique HTML file. The implications of this are important because the way in which browsers are designed to navigate the Web is built around the page metaphor. For example, browsers have Back buttons that allow users to navigate to the page they were viewing previously. Additionally, browsers inherently support a concept known as deep linking, which is simply a matter of allowing a user to navigate directly to a URL such as http://www.adobe.com/go/flex. The deep part of the deep link is the path following the domain name (/go/flex).

Users are accustomed to using the Back button and deep linking. These features are such an important part of the web experience that you may even wonder why we're mentioning them in this chapter. After all, you may think these features are incredibly obvious. However, the new generation of web applications, including Flash, Ajax, and Flex applications, breaks these features. The result is that users of these applications can feel frustrated when they habitually use the Back button or copy and paste a link and these actions don't work as expected.

Exactly how do these behaviors break in Flex applications? First, consider how the Back button works. The browser maintains a history of pages the user has viewed. When the user clicks the Back button, the browser simply goes to the previous page in the history. Flex applications don't use pages, though they may have many distinct screens or states. When the user navigates through the sections of the Flex application, she may feel that clicking the browser's Back button should move her back through the sections of the Flex application. However, because the Flex application resides in one HTML page, the default behavior of the Back button will be to simply take the user back to the previous HTML page she had viewed, and it will not navigate through sections of the Flex application.

The same issues affect deep linking as well. When a user navigates through a Flex application, she may get to a section she'd like to bookmark or email to a friend. Most users are accustomed to being able to simply add a bookmark or copy and paste the URL from the browser's address bar. Yet, as a user navigates through a Flex application, the URL in the address bar doesn't change. That means distinct sections of the Flex application don't have distinct URLs that can be bookmarked or emailed. The result is that returning to a Flex application's URL means returning to the starting point of that Flex application, not to a specific section.

The solution to the Back button and deep linking dilemmas is to use a bit of JavaScript to update the URL as the user navigates the Flex application. Every time the URL changes, the browser will register a new element in the history, which enables the Back button functionality. This also helps to provide unique URLs corresponding to different sections of the Flex application, which allows deep linking.

Normally, when you change the URL in a browser a new page loads. However, there is an exception to that rule. Changing the anchors will not cause a new page to load. An anchor in a URL is indicated by a pound sign (#). For example, consider that your Flex application is at http://www.example.com/index.html. If you update the URL with JavaScript to http://www.example.com/index.html#a, the page will not reload, but the Back button will be enabled and you also will have created a distinct, new URL that you can use to access the same Flex application.


This excerpt is from Programming Flex 3. If you want to try your hand at developing rich Internet applications with Adobe's Flex 3, and already have experience with frameworks such as .NET or Java, this is the ideal book to get you started. Programming Flex 3 gives you a solid understanding of Flex 3's core concepts, and valuable insight into how, why, and when to use specific Flex features. Learn to get the most from this amazing and sophisticated technology.

buy button

Flex 3 includes an mx.managers.BrowserManager class that is intended to create a simple solution both for Back button integration and deep linking using the aforementioned technique. The BrowserManager solution is not as elegant as it could be, but it does work, and in the next section we'll look at how you can use it.

Working with BrowserManager

The BrowserManager class is a Singleton class for which the getInstance() method return type is set to mx.managers.IBrowserManager, an interface. That means that when you want to work with BrowserManager you should declare a variable of type and assign BrowserManager.getInstance() to that variable.

The BrowserManager instance does the following things, which are of interest in this section:

  • It allows you to set the new URL fragment (the value following a # sign) using a setFragment() method.
  • It allows you to retrieve the URL fragment using the fragment property.
  • It allows you to set the title of the HTML page using the setTitle() method.
  • It allows you to set a default fragment and title using the init() method.
  • It dispatches events to notify the application when the URL has changed.

Initializing BrowserManager

When working with BrowserManager, you must always initialize the instance by calling the init() method. The init() method requires two parameters: a fragment value and a page title. The application uses the first parameter (the fragment) when the user clicks the Back button to return to a point at which the URL has no fragment. In that sense, the first parameter defines the default fragment value, though it has an effect only when the user is clicking the Back button. The second parameter sets the title of the web page in the browser. In addition, the init() method also sets the property of the application to false, which is necessary for the correct history management and deep linking to work correctly.

It may seem strange that historyManagementEnabled must be set to false for history management to work correctly. That is because is wired to the older HistoryManager, not to . BrowserManager supersedes HistoryManager, and setting to true can interfere with BrowserManager.

The following is an example of how you can use the init() method. In this example, the init() method is being called on creationComplete, which is appropriate because this method must be called before you run any other BrowserManager code.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
creationComplete="creationCompleteHandler();">

    <mx:Script>
        <![CDATA[

            import mx.managers.IBrowserManager;
            import mx.managers.BrowserManager;

            private var _browserManager:IBrowserManager =
BrowserManager.getInstance();

            private function creationCompleteHandler():void {
                // When the user clicks the Back button to the point
                // where there is no fragment, the application will use
                // the default fragment value of example.
                _browserManager.init("example", "Example Page");
            }

        ]]>
    </mx:Script>
</mx:Application>

Setting and retrieving a URL fragment

In BrowserManager lingo, a fragment is the portion of the URL that follows the # sign. For example, in the URL http://www.example.com/#flex/page2, the fragment is . You can set the fragment using the setFragment() method. The following example will set the fragment to exampleTwo as soon as the application starts:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
creationComplete="creationCompleteHandler();" historyManagementEnabled="false">

    <mx:Script>
        <![CDATA[

            import mx.managers.IBrowserManager;
            import mx.managers.BrowserManager;

            private var _browserManager:IBrowserManager =
BrowserManager.getInstance();

            private function creationCompleteHandler():void {
                _browserManager.init("example", "Example Page");
                _browserManager.setFragment("exampleTwo");
            }

        ]]>
    </mx:Script>
</mx:Application>

On the flip side, you often will want to retrieve the current fragment value. The property of BrowserManager returns that value.

Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9

Next Pagearrow