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.