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.
6 Comments
very good and very nice blog
Simon,
First of all, thanks for making this available to the public. So after reviewing the application, the questions I have with regard to methodology are: 1. All the modules in the pool are loaded at the start of the application, regardless if they are needed or not, and 2. The module pool is static and would require a bit of reworking to be able to dynamically add modules to the pool. It seems to me that one of the primary benefits of using modules is that they can be deployed to the application without the application itself needing to know about them.
I’d be interested in your take on this.
Hey Franics, thanks for the feedback buddy.
Just before I answer you question I want to make it clear to people that this is a simple application to highlight module loading methodology and intended for people starting off in the multicore, module, pipes world. I would hope once people have grasped the basics they can add necessary improvements for deploying a full scale app.
1) Yup, all the pool modules are loaded on app startup. Just to point out here, the modules on load actually do not load any sort of view, the actual UI components are not instantiated until the Shell requests them. So, a basic module skeleton is loaded with pipes connected ready and armed for a pipe message to be sent for it to release its view. Overheads of loading modules in this manner in my tests appear minimal, it also gives further control over view instantiation and a more methodical start up routine. It would be fairly simple to have a start up pool if required to prevent all modules loading initially if this is not to every ones taste. I would be interested to hear opinions in regards to loading of the module skeleton at start up.
2) Yep you right on this point, I wanted to ensure that this demo provided some sort of simplicity in certain areas to ensure clarity with what was being loaded and how to handle modules once loaded. Have you any code to show as an example for dynamically adding modules you would like to share?
Simon,
Yup, I’m probably going to post something soon; I’ve been super busy and I was at 360|Flex in San Jose last week as well. I’ll let you know when I have something ready.
Thanks Francis I look forward to seeing what you’ve got!
Where have have you been adding modules within the framework?
How was San Jose?
Yeah Francis, I too would like to see what you got.
One Trackback
[...] MultiCore app. demo without Flex Modules. [...]