I have been beavering away striving to refine my technique for PureMVC multicore modular applications and finally found a logical path I feel comfortable with. Following a discussion with Cliff my new methods should also solve some potential issues within this app (thanks for the tips mate).

One niggle in my side was that for the application to load the module and events proceed as I would anticipate the facade startup routine in the module had to run on the initialize event. This I resolved by having a creationComplete event listener in the shells application mediator and then proceed to add the module to the framework connecting pipes etc from there. This is all well and good for a simple app but when modules get more complex and we introduce multiple view components can the shell be assured that the module is created and connected. The Flex protocol on creation of a new component could raise problems and within a modular application I do not want issues simply arising from timing.

I have now ventured down a few different paths and have reconstructed the previous Garbage Collection Demo for a V2 available to view here and the source can be viewed here.

I have now opted for module creation using an ActionScript class extending ModuleBase as opposed to mxml Modules. Start up involves creating an array (pool) of modules (string names) and then looping through the array loading each module. Each module is literally an empty shell that instantiates the modules facade and in turn the framework and connection of pipes from shell to module and vice versa. I defer instantiation of the modules view and therefore overcome the potential timing issues for creation of a component which may cause problems when connecting the Pipes etc.

So, to briefly summarise up to this point: Application loads, a pool (ArrayCollection) of module strings are developed, these in turn are loaded using ModuleManager.getModule(), we can then proceed to load the modules View through a chosen method i.e. button click.

To request that the module releases its view a message is sent via a pipe who’s sole purpose is to handle View loading/unloading related notifications. This pipe is named after the specific modules NAME. This technique now offers a much more controlled method of loading a module, its view and further aspects within the framework. It also offers the opportunity to completely remove the module ensuring a garbage collection (well as best possible with Flash Player 9 huh?) or simply removing the View keeping the module instance loaded and prepared for another load View sequence!

If you check the source code I have commented it heavily for clarity sake and hope that this app can help people get to grips further with a MultiCore application.