Expert Adobe Flex Training

Rob Rusher

Subscribe to Rob Rusher: eMailAlertsEmail Alerts
Get Rob Rusher: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Back and Forth

Custom history management with Flex 2

For over a decade now, we have been trained to use the "back" and "forward" buttons in our Web browser to review or backtrack previously viewed content. We are trained to the point that there are even keyboard shortcuts. Unfortunately, this can be a problem when browsing Flex applications. Being the well-trained users that we are, we often forget that we could cause the Flex application to reload unwittingly.

Fortunately, there is a solution that is built into the Flex SDK and HTML templates that are generated in a Flex Builder project. By default, Flex enables history management for only a couple of navigator containers, without using any additional ActionScript or MXML tags. Although this is a good start, we often need more options to build truly custom applications.

In order to implement your own custom history management, you will need to use the HistoryManager class that is part of the Flex 2 SDK. By implementing the API, you can create custom history management for your custom objects in an application. Note: History management is not supported on Netscape 4.x and Opera 6.0 web browsers.

History Enabled Components
History management is available by default for the Accordion and TabNavigator navigator containers. It is disabled by default for the ViewStack navigator container. When history management is enabled, as the user navigates different navigator containers within an application, each navigation state is saved. Selecting the Web browser's "back" or "forward" browser button displays the previous or next navigation state that was saved. History management keeps track of where you are in an application, but it is not an undo and redo feature that remembers what you have done. Note: When history management is enabled for a particular component, such as a navigator container, only the state of the navigator container is saved. The state of any of the navigator container's child components is not saved unless history management is specifically enabled for that component.

Custom History Management
The mx.managers.HistoryManager package is pretty useful for building generic undo mechanisms. It must be imported before using it. The HistoryManager provides a register () method that allows you to register any object with it, even if it does not have a visual element. To register a component with the HistoryManager class, that component must implement the IHistoryManagerClient interface, and then it must be registered with the HistoryManager class. You will then pass along a reference to a component instance to manage. Each registered component receives a unique state ID based on its full pathname.

In the following example, the Application component (this) is registered with the HistoryManager class when the Application is initialized:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
initialize="mx.managers.HistoryManager.register(this);"
implements="mx.managers.IHistoryManagerClient">

By implementing the IHistoryManagerClient interface, you "agree" to implement the following two methods into your object's code:

  • function saveState() : Object
  • function loadState( state : Object ) : void
The HistoryManager calls the saveState () method on all registered objects every time the state of the application changes. It's up to you to return any object that describes the current state of your object (like a snapshot). If this state is going to be restored, then all registered objects receive their state back via the loadState () method. Again, it's up to you to rebuild the state by investigating the snapshot.

You can also inform the HistoryManager to save the current state of the whole application by calling its static save() method. This has to be done by hand if a performed action has to result in building a "snapshot" of your application. I've illustrated (see Listings 1 and 2) two ways to implement the HistoryManager:

How the HistoryManager Class Saves and Loads State
The history management feature uses the Macromedia Flash navigateToURL() function to load an invisible HTML frame in the current Web browser window. It then encodes a Flex application's navigation states into the invisible frame's URL query parameters (using the standard prop1=value1&prop2=value2 format). A SWF file, called history.swf, in the invisible frame decodes the query parameters and sends the navigation state back to the HistoryManager class. You can investigate this by viewing the HTML source that is generated along with a Flex application.

Conclusion
Once again, the Flex SDK has made it possible for extending components to be history management enabled very easy. By simply implementing an interface and utilizing the HistoryManager class, you are able to quickly avoid many Pavlovian nightmares from the back button. Keep in mind that this feature should be used primarily for managing navigation and not for undo/redo. Although you could accomplish some level of undo/redo if you are creative, there are definitely better ways of doing it, so it's best to stick to navigation with the HistoryManager. I hope you found these examples easy to follow and helpful in your learning process.

More Stories By Rob Rusher

Rob Rusher is an Adobe Certified Expert (ACE), Community Expert, and Certified Instructor (ACI). In his role as Principle Consultant for On3, he leads an Adobe software enablement practice to help his clients build rich Internet applications and to rapidly increase their knowledge and skills to better support their organization's goals. He has taught and mentored the technical teams at Standard and Poor’s, eBay, IBM Global Services, the Social Security Administration, and other Government and Fortune 100 organizations.

Because of his depth of knowledge and long standing relationship with Adobe, Rob was selected to write the Certified AIR training course as well as the ColdFusion and Flex certification exams. Rob has also co-authored four best selling books on building secure, cutting-edge and rapidly developed applications using Adobe AIR, ColdFusion and Flex. He is also very active is organizing and speaking at Adobe conferences and user groups. In addition to growing his software consulting practice, On3, Rob has been building expertise in rich client application development on a wider variety of devices and platforms that extend the applications to change the way we all create and live.

On3 provides consulting, mentoring and training services to help organizations grow their own experts from within. For more information, visit us at www.On3solutions.com. Rob Rusher maintains a weblog devoted to Adobe Flex and other Internet technologies at www.RobRusher.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.