Archive for May, 2005

I originally posted my AS1 BrowserHistory class and associated files in 2002 and it was distributed on various sites. In 2005, with my own site, I decided to finally give it a permanent home

What
Normally, pressing a browser’s forward or backward navigation buttons on a Flash page will take you out of the movie. The BrowserHistory class allows developers to create a history list that can trigger actions based on the use of these buttons.

Why
I have noticed a number of solutions out there that attempt to resolve the back button problem, most noteably Robert Penner’s work (www.robertpenner.com) and more recently Mike Chamber’s Pet Store back button. Robert introduced using MX’s LocalConnection object to get around all the browser issues, and I really like the new solutions that implemented this approach, however all of them seem to be missing something. Robert’s required the creation of a new swf and html page for every History object. Mike’s limited you to passing strings through the browser’s url and doing your own data conversions. The javascript approach also didn’t work in the newer Netscape and Mozilla browsers, because appending variables to a url is not treated as a new history object in the browser.

What I really wanted from a History object in Flash was something that:
1) would work on all platforms and browsers with the 6 player
2) would be as simple to use as adding History elements through script and defining a function to handle a history event
3) would only require including extra files and not manipulating them
4) would allow me to work with any predefined datatype

In my attempt, I tried to accomplish these goals by moving the persistant storage of the History elements into a SharedObject instance and using 4 predefined swfs and their accompanying html files (total of 8 files) to create a way of checking status. Since there are only those 8 files used in tracking status, no matter how many history elements you add, a user will only request a total of 8 additional files (this is nice if you think about server loads, the other methods request a file for every history element). Using this method of storage and status does not require the manipulation of extra files, instead all of the work is done “behind the scenes” by the BrowserHistory Class, the only requirements are that you include the proper files and know how to script a BrowserHistory instance.

I hope that this can be of use to someone.
ENJOY
Kenny Bunch