The official Google Code name is unfocus-history-keeper. You can find the latest source in SVN. I will be doing development from trunk for now, until I can get to the tags and branches and whatnot to keep things organized.
For now, here is a snapshot. I’ll call it History Keeper 2.0 Alpha 1 for now. Let’s see where this goes from here.
For the first bug, the last state gets lost in some browsers, if you leave the site and then come back using the back button. I know how to fix it, i just need the time to implement that fix. That is the only known bug, so please feel free to leave a report in the issue tracker at Google Code if you find any more.
Also of note, you will find the source for the Swf Tools in there too (SwfHTML, FlashPlayerInfo, etc.) but if you are using ExternalInterface and SwfObject, you can safely omit those files when using History Keeper. You will not find any Actionscript code in there just yet. I’m still in the process of cleaning that stuff up (which basically means that the Communication stuff is incomplete in this release).
For your convenience, you will find two compressed JavaScript files in the root of the archive, unFocus-History-p.js and unFocus-HistorySwf-p.js.
unFocus-History-p.js contains:
- EventManager.js
- History.js
unFocus-HistorySwf-p.js contains:
- EventManager.js
- History.js
- FlashPlayerInfo.js
- SwfUtilities.js
- SwfHTML.js
These were compressed using Dean Edwards’s Packer (included in above listed order).
There is also a QuickLoader Object in there, that may or may not have a bunch of quirks. Feel free to test it out. It attempts to begin working on the DOM as soon as it’s ready instead of waiting for the body’s onload event to fire.
Enjoy! 🙂 (Download here)
is the communication always going to be using the unFocusHistoryUpdate property in the root of flash ?
if so I can help and easy make a class called HistoryManager which will handle the saving and loading of the states.
So if you have idea if the communication between flash and javascript will be on the way it currently is let me know. I will appreciate it.
Hi AleksLA,
I’m always ready to see some code that might help people out, and this package is missing quite a bit on the application side of things. At this point, the unFocus stuff is a set of tools that others can use to build out their own frameworks. So I’m always happy to see others make frameworks that work with the this stuff (that’s actually why I made it so modular).
Just a note, a big reason for why I have never produced a HistoryManager kind of class, is that I haven’t had the time with all my regular development work (usually on other platforms) to figure out exactly what that kind of class should do. After getting the new adcSTUDIO website up though, I have a pretty good idea, and even the beginnings of a class.
I’d love to see what you have in mind with though. 🙂
BTW, feel free to post to the forum (http://www.unfocus.com/forums/) if that’s more convenient (the server email issues that have been plaguing this site should be over, so it should be possible to register again).
Finally, to answer your actual question, yes, I don’t have plans to change the communication stuff very much, since it doesn’t make much sense to continue it’s development now that ExternalInterface is around and well supported. That said, I’m not going to specifically discontinue it or anything, as I like it better than the other Flash Player 7 and lower solutions (and there seems to be plenty of platforms that only support up to Player 7).
Thanks,
Kevin N.