Assigning to typed variables across SWF boundaries breaks

Question

I'm writing an application that uses extendable UI elements, whose precise implementation is determined at run-time using configuration. So for example, I want to show a list of items, which - depending on the configuration - may be shown as bulleted list, a numbered list, a two column list, etc. The containing application knows nothing about the specific implementation except that it is a type that supports the method call setItems(items:Array):void.

So I have set up a base class, for example:

package my.stuff {
    public class BaseList extends MovieClip {
        protected var m_items:Array;
        public function BaseList() {
            m_items = new Array();
        }
        public function setItems(items:Array):void {
            for (var i:int = 0; i < items.length; i++)
                m_items.push(items[i]);
        }
    }
}

And then I have create a specialized implementation that does, for example, two column list:

package my.stuff {
    public class TwoColumnList extends BaseList {
        protected var m_columns:Array;
        public function TwoColumnList() {
            super();
            m_columns = new Array();
            m_columns.push(new Array());
            m_columns.push(new Array());
        }
        public override function setItems(items:Array):void {
            for (var i:int = 0; i < items.length; i++) {
                m_items.push(items[i]);
                m_columns[i%2].push(items[i]);
            }
        }
    }
}

Now the UI itself is done in Flash Professional as an FLA with class TwoColumnList as the "document class". I compile the FLA ("publish") to the target SWF, then I try to load it into the application. Normally I'd expect this to work like so:

public function startLoading(implURL:String):void) {
    var loader:Loader = new Loader();
    loader.contentLoaderInfo.addEventListener(Event.INIT, doneLoadingImpl);
    loader.load(new URLRequest(implURL));
}

public function doneLoadingImpl(e:Event) {
    var info:LoaderInfo = e.target as LoaderInfo;
    var impl:DisplayObject = info.content;
    m_containerClip.addChild(impl);
    var listImpl:BaseList = impl as BaseList;
    impl.setItems(m_allItems);
}

Except this doesn't work - the addChild() works fine but the cast to BaseList results in null (not an exception - just null). I can cast impl to MovieClip just fine, and I can also cast it directory to TwoColumnList, after which it casts-up nicely to BaseList, like this:

...
var listImpl:BaseList = impl as TwoColumnList;
...

So that works, but it really defeats the purpose of the whole exercise - which is to not know ahead of time the specific UI implementations that may be created in the future.

I read somewhere about doing info.applicationDomain.getDefinition, but I can't say it does any effect whatsoever.

I'm not an ActionScript developer in my day to day job, I've just been called to help out with some project whose main developer is no longer with the company, and I'm stumped - any help will be appreciated.

Answer 1

Your problem is most likely related to the classes loading into different application domains. The type cast returns null, if the object is not a subclass of the class you are casting to - and it seems you have two versions of BaseList "competing" with each other.

If this is the case, you can work around it by explicitly loading the SWF into the same application domain as the main one:

 var ldrContext : LoaderContext = new LoaderContext ( false, ApplicationDomain.currentDomain );
 var loader:Loader = new Loader();
 loader.contentLoaderInfo.addEventListener(Event.INIT, doneLoadingImpl);
 loader.load(new URLRequest(implURL), ldrContext );

However, especially when loading external content, you should really be using interfaces. Keeping the implementations decoupled is exactly what they were invented for. Check out this blog page, it explains why you should use interfaces when loading external files (there also is a link to more fundamental info about interfaces), and incidentally, the author seems to have had a problem similar to yours... ;)