The company I work for, Tom Snyder Productions, has just released the latest version in our FASTT Math line of products, "FASTT Math 2.0 Enterprise Edition". (Don't blame me, I didn't pick the name) The architecture for this product is a little odd. Schools buy a FM (FASTT Math) server and install it locally on their network. On the server is a Flash based application (plus a whole lot of other stuff) to run the product. On each client computer is a thin loader application that downloads the application and displays it to the student.
When starting off development it was assumed the loader would be a simple Flash projector since several other similar products had been successfully deployed in that manner. But as we developed the application we really started to see the shortcomings of that approach and begin looking for alternatives. In the end we chose a Screenweaver HX based solution for our loader. It provided us with all the base functionality we expected, but also allowed us to implement a few features that would have been impossible otherwise.
1) The loader is capable of both reading and writing to a local configuration file. While the file writing didn't end up making it into the released product, we did implement it and everything worked as expected. (A separate config utility is shipped to match other products in the line)
2) We were able to have a splash screen while loading. This might seem like such a minor thing, but having a nice FM logo appear in a separate window instead of a "loading" message really made the product feel more polished.
3) If enabled in the config file, all trace() statements get written out to disk in a log file. This lets us diagnose problems in the field far more easily.
4) We have error handling code to gracefully fail if the initial swf couldn't be loaded for any reason.
5) Full screen support with keyboard access, and pushing escape doesn't pop you out of it.
I won't bore you with the details of how every feature was implemented, but I will comment on #2 and #3 since they are just a little interesting.
To implement the splash screen we distribute a local swf that contains only that information. It gets installed locally next to the loader application. On startup of the loader some haXe code runs that loads that swf and displays it in a window. The haXe code also creates a second window and begins the load of the main application files. It doesn't display this window at first so you only see the splash screen. The main application loads, and then that app loads several more files it needs. When the main app is complete it makes a call to the haXe backend that tells it to hide the splash screen and display the main application window in full screen mode. In this way the student goes from splash screen to an application that is ready for user interaction.
Logging was a simple feature to implement since we used the MTASC compiler to build the main application. Using MTASC's -trace option we were able to specify a custom trace function that would report back to the haXe backend on any call to trace() in the Actionscript code. The haXe backend would then make a decision to write it to disk or not depending on a configuration option. During development we required a more robust logging solution, so when not in "release mode" our build scripts are set up to redirect trace output to the XRay debugger. Using this method there were no Actionscript code changes necessary to switch from a debug to a release build.
One of the biggest advantage to using Screenweaver HX over the course of development was the user community. Several times we ran into roadblocks that were quickly resolved with a question to the haXe mailing list. Having the source code for the underlying infrastructure also allowed us to trace some bugs back to their source more easily.
Screenweaver HX rocks.
Thank you Nicolas, Edwin and everyone else who's contributed to a great project,