ActionScript 3.0, Adobe Flex

Introducing HydraMVC…

HydraMVC is one of the most recent newcomers to the scene of Application Frameworks and Architecture Blocks for Flex Applications.
Its definitely something I’m going to check out in parallel to my love affair with the Mate Flex Framework.


HydraMVC is the result of a total rewrite of the PureMVC API exclusively for Flex, allowing Flex developers to take advantage of the PureMVC paradigm while leveraging native Flex features.

In addition to using Events vs. an independent Observer pattern, HydraMVC also streamlines implementation, encapsulating much of the initialization code that needed to be written when implementing PureMVC.

HydraMVC was written out of a love / hate relationship with PureMVC; it’s not our intent to say it’s “better” than PureMVC, because the mission of the frameworks are entirely different. PureMVC intends to be language-agnostic, where HydraMVC is a compromise by design.

While HydraMVC is an MVC framework, the demos also imply a strategy for package structure, although the implementation of HydraMVC will work regardless of whatever package structure convention you use. The goal was to create a structure that scales well for large applications, but it also allows you to quickly develop small applications in a proper MVC.

ActionScript 3.0, Adobe Flex, Tools

FC / FB Workflow Optimizer… sources available

I have made the sources available for the Workflow Optimizer… its a crude implementation but it does the job.
It uses Flex, AIR, as3preferenceslib, as3corelib and the Mate Flex Framework.

Don’t hesitate to comment on the ideas or concepts.. but don’t comment the code: it’s not written with any other priority than functionality…

Check it out…

ActionScript 3.0, Adobe Flex

The "initCompleteHandler" function is protected in the FX4 DownloadProgressBar

Great news for all of us implementing Custom Preloaders…

Instead of having a private “initCompleteHandler” function on the DownloadProgressBar, the function is now protected so we can override it in custom implementations. This means that we no longer have to implement the IPreloaderDisplay interface and hack out a lot of the intended functionality in order to have the preloader also handling the load of the application logic so that it does not change to Application View until the Application is considered to actually be ready.

This is great news… making the DownloadProgressBar a lot better… now it all seems like just need some kind of “preventDefault” behavior in order to have total control over the switch from preloader to application without having to bloat the preloader itself…

Currently I am resorting to including either classes such as the PureMVC facade, a Mate eventmap or another kind of EventAggregator into the Preloader SWF in order to be able to hook into it… this is however only possible if you also hack a bit around in order to prevent the default switch from preloader to application.