Flex ModuleLoader within Module Issue

I ran into a little problem loading Modules and accessing the interface to fire methods within the loaded module. This occurs when I load one module using the ModuleLoader into another Module. I followed the Adobe examples that use the ModuleLoader and cast the event as an Interface to access the methods.  Here is an example of the outlined method from Adobe.  I am loading an external SWF module into the main application and trying to pass a mp3 file to the SWF through the ISoundPlayer interface:

public var _mp3URL:String = "test.mp3";

private function initComponent():void
{
    soundPlayer.url = "SoundPlayer.swf"
    soundPlayer.loadModule();
}

private function applyModuleSettings(event:ModuleEvent):void
{
    var ichild:* = event.target as ISoundPlayer;
    if( ichild != null ) {
        trace("weeee, its ready");
        ichild.selectedMedia = _mp3URL;
    } else {
        trace("sound player not ready");
    }
}

private function progressEventHandler(e:ProgressEvent):void
{
   var num:Number = Math.round((e.bytesLoaded/e.bytesTotal) * 100);
   trace("percent: " + num);
}

The ready event fires the applyModuleSettings handler and cast the target or child of the ModuleLoader as an instance of the ISoundPlayer interface.   However, the test if(ichild != null) is always null.   I could never get it not to be null. At first I thought this was a timing issue and I set a timer event to keep checking back to see if the child was not null, it was still always null.   I finally made what appears to be a work around using the ModuleManager to load the module.

Using ModuleManager to load the modules allows me to access the Interface methods(in this case ‘selectedMedia’). It seems that casting the child within ModuleLoader as an ISoundPlayer interface (in my example) always reports the child as null when loaded. However, casting the loaded module as a DisplayObject gives me access to the methods.

Example:

// ISoundPlayer Interface

package com.custom.interfaces
{
     import flash.events.IEventDispatcher;
     public interface ISoundPlayer extends IEventDispatcher
     {
          function set selectedMedia(mp3URL:String):void;
     }
}

Though I have not tested it, I have a feeling that you would not need an interface to communicate with the loaded module, you could just talk to the public methods directly because it is not a first class citizen within the application.    I would love to know where I might have went wrong with using the ModuleLoader and the ISoundPlayer interface. For now, I just need a quick and dirty method to get it to work. However, the down side is that you no longer have the interface as a contract between the loading application and the module. You don’t get the code hints to display public methods. That means if you change your module method names, you just broke your application.

Update

After some extensive discussion on Flex Coders with Alex Harui, I discovered the issue revolves around a sharing code between modules. Here is a link to the full discussion along with some example files Alex asked me to put together to better understand the issue.

Flex Coders Discussion

Example & Source Code

9 Comments

  1. Great post! I ran into a similar issue and didn’t figure out yet the right solution..

    One question – how do I get the source code for the above?

  2. Hi, i’ve tested the sample code on including a module in another one and found a new problem… perhaps you have an idea?
    If you put a viewStack in moduleOne and a tabNavigator in modulTwo, you have a HistoryManager error! I did try everything possible (for me) like setting historyManagement to false for both component, but nothing seemed to work.

  3. I have not tried having two or more components using the HistoryManger. However, I would put HistoryManager in to the shared code library, load this file into the main application first, then load the other modules. The first module to load the HistoryManager becomes the “owner” and you will get an error from when trying to load any other module using the HistoryManager. Check out this post: tp://blogs.adobe.com/aharui/2007/03/modules.html by Alex Harui, he explains the shared code approach.

  4. En el blog Daniel’s Random Mutterings se explica paso a paso cómo montar un servicio de alojamiento, gestión y reproducción que permita a los usuarios subir y compartir sus vídeos con el resto de internautas. El proceso no es muy complicado a pesar de que no había oído hablar nunca de las herramientas mencionadas en el artículo, como por ejemplo el CMS Django,

Comments are closed.