Rat Experiments: Studying the Limitations of Multicore Using Interfaces

[DavidPesta]

It is easier for me to visualize cores when they are completely separate SWF files. The separate SWF approach also makes pieces of the program more modular and allows different development teams to focus on their piece without the clutter of the other pieces.

I have taken Chandima's Move the Cheese (link) example and split it into two separate projects and changed the names of folders to make everything easier to examine.
- A separate project for the rat
- A separate project for the application

I have prepared a zip file for your download (link) of all project files used in the examples below.

Here we have the folder structure and swf locations of the projects where everything is working well:




Limitation #1: Both swf files must reside in the same folder. rat.swf cannot be loaded from a separate domain. If rat.swf is loaded from a separate domain, I get a Type Coercion failure at runtime.

:

TypeError: Error #1034: Type Coercion failed: cannot convert Rat@140a791 to interfaces.IActor.
at view::ApplicationMediator/completeHandler()[C:\...\app_source\src\view\ApplicationMediator.as:91]
Please note: You will find that I added Security.allowDomain("*"); inside of the Rat constructor because I thought that could have been the root of the problem, but the runtime error is the same. Adding a trace inside of the constructor will confirm that it is executed before the type coercion failure happens.


Limitation #2: The interface files must be found in the exact same package structure in both app and rat for it to work. If the package structure for interface files do not match in both projects, Type Coercion failure happens at runtime.

:

TypeError: Error #1034: Type Coercion failed: cannot convert Rat@153eaf1 to interfaces.IActor.
at view::ApplicationMediator/completeHandler()[C:\...\app_source\src\view\ApplicationMediator.as:91]

Limitation #3: While the interface files must be found in the same package structure (#2 above), the StartupCommand.as file cannot. I suspect this is because separate cores share the same filename space or something. If StartupCommand.as exists in analogous packages across the different projects, I get a null object reference error at runtime.

:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
at view::ApplicationMediator/onRegister()[C:\...\app_source\src\view\ApplicationMediator.as:55]
...
at RatFacade/startup()[C:\...\rat_source\src\RatFacade.as:41]
at Rat/init()[C:\...\rat_source\src\Rat.as:40]
at view::ApplicationMediator/completeHandler()[C:\...\app_source\src\view\ApplicationMediator.as:92]

While limitations #2 and #3 are inconvenient, limitation #1 is crippling (for me). Is there a way around any of these?

I genuinely appreciate anyone's help on the matter.

[Tekool]

I see in your app that when you load your SWFs you didn't change the LoaderContext (2nd argument of the Loader.load() method). It will allow you to set SecurityDomain and ApplicationDomain to the same as your shell app. That should help.

http://livedocs.adobe.com/flex/3/langref/flash/display/Loader.html#load()
http://livedocs.adobe.com/flex/3/langref/flash/system/LoaderContext.html#securityDomain

[DavidPesta]

Wow, very very good. Thank you Tek!

I was able to resolve #1 above by replacing the code inside app's ApplicationMediator.as starting at line 65:

:

// load a rat swf
var url:String = "http://localhost.rat.com/rat.swf";
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener( Event.COMPLETE, completeHandler );
loader.contentLoaderInfo.addEventListener( IOErrorEvent.IO_ERROR, ioErrorHandler );
var context : LoaderContext = new LoaderContext(true);
context.securityDomain = SecurityDomain.currentDomain;
context.applicationDomain = ApplicationDomain.currentDomain;
loader.load( new URLRequest(url), context );
It also requires a crossdomain.xml file be placed inside of localhost.rat.com. Also, it won't work unless app.swf is actually being loaded inside of an HTML object tag and served to the browser accessing it via the domain. It will not work inside of a browser loading it locally. (in other words, the browser must point to http://localhost.app.com/app.html and will not work when accessing it from the filesystem file:///C:/.../localhost.app.com/app.html)

I am still investigating solutions to #2 and #3, but it looks like I'm on the right track now and #2 and #3 are merely inconveniences, not show stoppers.

Thanks again!

[Tekool]

Your #2 and #3 points can easily be solved if you use a package per project and a common package for all interfaces, common code, etc...

It must look like :

:

src
    |-- common
        |-- interfaces
            |-- IActor
    |-- app
        |-- model
        |-- view
        |-- controller
    |-- rat
        |-- model
        |-- view
        |-- controller

All my multicore projects look near like this. You can have a look at one Flash multicore project like yours on my blog http://www.tekool.net/blog/2009/08/09/flash-only-modules-with-puremvc-pipes-demo/ 

[puremvc]

Limitation #1: Both swf files must reside in the same folder. rat.swf cannot be loaded from a separate domain. If rat.swf is loaded from a separate domain, I get a Type Coercion failure at runtime.

Limitation #2: The interface files must be found in the exact same package structure in both app and rat for it to work. If the package structure for interface files do not match in both projects, Type Coercion failure happens at runtime.

Yep, what Tek said. You just need to make a library project and put all your common files in it. Then include that library in both your cores.

Limitation #3: While the interface files must be found in the same package structure (#2 above), the StartupCommand.as file cannot. I suspect this is because separate cores share the same filename space or something. If StartupCommand.as exists in analogous packages across the different projects, I get a null object reference error at runtime.

Here your problem is failing to package properly. You are loading everything into the same application domain in the same VM, so yes package name space is shared.

In both of your StartupCommands you have

:

package controller
So you are loading two different classes whose fully-qualified names are controller.StartupCommand.

To differentiate them at runtime, you want to package your classes in some way that ensures they don't collide with each other, even when combined with classes someone else writes.

The most common approach is to start the package hierarchy by reversing the nodes of an internet domain you own, (i.e. com.evilscience). You follow that with the name of the utility or application you're writing (i.e. ratlab). Then you may follow that with the core name (i.e. app or rat). And finally, we have the standard inner core structure (i.e. model, view, controller).

Modifying Tek's structure shown above to account for multiple projects and compatible packaging:

COMMON LIBRARY PROJECT

:

bin
    |-- common.swc    <-- SWC created in this project
src
    |-- com
        |-- evilscience
            |-- ratlab
                |-- common
                    |-- interfaces
                        |-- IActor
                        |-- IApplicationShell

APPLICATION PROJECT

:

libs
    |-- common.swc    <-- SWC used in this project
src
    |-- com
        |-- evilscience
            |-- ratlab
                |-- app
                    |-- model
                    |-- view
                    |-- controller
                        |-- StartupCommand

RAT PROJECT

:

libs
    |-- common.swc    <-- SWC used in this project
src
    |-- com
        |-- evilscience
            |-- ratlab
                |-- rat
                    |-- model
                    |-- view
                    |-- controller
                        |-- StartupCommand

Now your classes in the cores won't conflict with each other when you use the same class names.

:

com.evilscience.ratlab.app.StartupCommand and

:

com.evilscience.ratlab.rat.StartupCommand are unique fully-qualified names.
-=Cliff>

[DavidPesta]

Really very good. It looks like I'll be able to get all of this to work.

Thank you both very much for the time you spent helping me out on these issues.

David