This content has been marked as final. Show 3 replies
I had to make the same decision. I had memory leak problems with SWFLoader and that influenced my trying Modules instead. Furthermore, you have to use a SystemManager to interact between the shell app and the loaded .swf with SWFLoader. Modules formalize that interaction. There are a few other differences as well which were irrelavent to me so I am skipping them.
But in the end, what basically made me go with Modules was that the documentation for them explicitely states they are intended for splitting huge applications into smaller modular ones. Basically exactly what I was trying to do with SWFLoader on my huge application. Looking ahead to the future, I anticipate that the changes to the Module classes will further facilitate this task while changes to SWFLoader (if any) will not.
Thanks for the insight.
I'm just surprised that no one from Adobe has to time or inclination to answer such questions! It's like if you're using Flex you're own your own. Best of luck! Deffinately not a warm and fuzzy feeling. And deffinately not a feeling to get me to build "large" applications in Flex/Appollo.
Obviously you can use Application SWFs to break a large application into dynamically loaded parts. Modules were created to address the ease-of-use issue. Module SWFs provide an easier mechanism for communication between the Modules and main (shell) application SWF. Modules also give us a way to enhance that mechanism in the future which would be limiting if working solely with Applications.
Further, Modules can be reduced in SWF-size compiling them against the symbols loaded in the shell application. This makes them much smaller and faster to download. That was possible with Application SWFs by using Runtime Shared Libraries. However, using RSLs is tedious compared to using Modules.
I have an example of using Modules on my blog. The example covers the size optimization of Modules as well as communication with Modules.