1 Reply Latest reply on Jan 5, 2011 9:23 PM by Flex harUI

    Asking about Modules

    D Baron

      Hi Folks,

       

      I asked a question or two about module-in-a-module loading in combination with interfaces recently and was fortunate to get some great help.  Now I'd like to ask more about modules.  I am new to the Flex universe and am trying to find my ‘sea legs’ so to speak in regards to large, complex application development using Flex and ActionScript.  The products appear to be tremendously powerful and flexible, which is truly inspiring.  Then again… I am currently near the bottom of the learning curve, and thus am looking to those who know to help me figure things out.

       

      To begin with, the “loading” and “displaying” of modules seems to involve several steps (using ModuleManager) and I would just like to know a bit more about the details of the process.  For example, consider the following code (from within an application mxml):

       

      public var _modInfo:IModuleInfo;

       

      private function loadModule_1():void {

          _modInfo = ModuleManager.getModule("Module_1.swf");

          _modInfo.addEventListener(ModuleEvent.READY, ModEventHandler);          

          _modInfo.load(new ApplicationDomain(ApplicationDomain.currentDomain), null, null, moduleFactory);

      }

        

      private function ModEventHandler(e:ModuleEvent):void

      {

          myNavigatorContent.addElement(_modInfo.factory.create() as IVisualElement);

      }

       

      In this example, the public var _modInfo is of type IModuleInfo.   It is scoped to the ‘application’ at this point, i.e., is not a local variable.  Let’s say that Module_1.swf is a 100K module.   After calling the ModuleManager.getModule() method, what exactly is put “into” the _modInfo variable?   Does it, or will it contain 100K of “stuff”?  Or is a pointer to some other memory structure that in turn uses the load() method to tell Flex to ‘download and receive the specified file’?

       

      Then, once the module file has been fully downloaded (and put into some variable?), I get the ‘ready’ event.  The event includes the ModuleEvent arg.  I have seen examples where there is NO explicit, wide-scoped variable such as _modInfo, but instead the ModuleEvent’s .target (or .module?) is used to ‘render’ (?) the finalized module/file into some container.  From your perspective, does it really matter if a ‘wide-scoped’ variable is used to hold the ModuleInfo or not?  Would the main reason be so that it can later be Un-loaded (explicitly)?

       

      That brings me to the next question which is the ‘physical rendering’ of the downloaded module.  Am I correct to ‘assume’ that the ModuleInfo.factory.create() method effectively ‘renders’ the mxml/actionscript into the display container (via the addElement call)?  Could you explain a bit here?   If so, then at that point, assuming I have a wide-scoped variable holding the ModuleInfo, do I essentially have “2 copies” of the 100K module? – one in memory and one ‘one screen’?  Which leads me to this:  Once a module has been ‘visually rendered/added to a display container’, can it be ‘recognized’ again via ActionScript?  In other words, if, as I show above, I ‘addElement’ the module into a Spark NavigatorContent container, can I later re-access that ‘thing’ as a complete ‘module’ and ‘manipulate it’ via its Interface-declared methods and properties, or even Un-load it?   Does this make sense?   Or, is it that once the module as been visually rendered/added into the ‘page’, it ceases to be a ‘complete module’ and instead can only be seen as the individual mxml controls/components that make up the module?

       

      If the latter is the case, then does that imply that in order to ‘re-access and manipulate’ a module, I would in fact *have* to have a wide-scoped variable to hold/persist the ModuleInfo ‘stuff’?  And more to the point, does that variable (which may in fact be cast as my custom Interface) maintain its ‘pointer’ to the ‘visual stuff’ that was ‘added’ to the visual container?  In other words, if, “later on”, I use the wide-scoped variable to call (through my Interface) a custom method in the module, and that method results in a visual change, i.e., a text field being filled in, or an image appearing, would those visual changes be reflected in the earlier added module ‘stuff’ that was rendered into the container?

       

      Thanks in advance,

       

      -David

        • 1. Re: Asking about Modules
          Flex harUI Adobe Employee

          One of the key differences between sub-applications loaded with SWFLoader

          and Modules is that Modules are meant to be factories of instances of the

          module class.  With sub-apps, you typically load the SWF once and use a

          single instance of the sub-app.  Modules are a bit more like COM DLLs.

           

          So, ModuleManager.getModule() returns an IModuleInfo that references a

          structure that represents the module.  A call to load() will load the module

          if it is not already loaded.  If you call getModule() and load() again with

          the same url, the module swf is not loaded again unless it has somehow been

          unloaded.  Calls to getModule() from all over the app return a reference to

          the same module via an IModuleInfo.  The IModuleInfo is small.  All of the

          memory for the module is stored in other memory blocks and referenced.

           

          You must have a strong reference to at least one IModuleInfo until the

          module is READY, otherwise there is a chance that the module will get

          garbage collected.  Once you've created an instance of a class in a module,

          the module will stick around until all instances of classes from the module

          are available for garbage collection, even after unload() gets called.  Note

          that if the module has to be loaded, the READY event can take some time, but

          if it is already loaded, the READY event will happen right away.

           

          In your READY handler, the create() method creates an instance of the main

          class of the module.  You can create additional instances if you want and

          manage them as you would any other class instances.

           

          You added the instance to a parent container who will then size and position

          it just like any other class instance.  You don't have to keep a variable

          referencing the child, you can always find the child via getElementAt() if

          you want.

           

          IOW, if the main class in the module is called Foo, then calling create()

          gives you an instance of Foo just like calling "new Foo()".  All the same

          rules of management of these instances apply.  The only difference is that

          because you do not explicitly use the class Foo in the main app, then Foo

          and all of its dependencies are not linked into the main app which makes it

          smaller, compile faster, load faster and allows for independent development.

          The price you pay is having to deal with the instance in more abstract

          terms, via interfaces.