I think we may have our wires crossed in terms of what we are trying to
achieve here.

The Air App is simply a surrogate browser, simply a means to load our
existing application SWF. There doesn't need to be any communication between
Air App and SWF other than it has a place to host/show it. So having it in
it's own Application Domain is perfect for what we need.

Alex Harui-2 wrote
> It is all about the ApplicationDomain topology.  By loading the sub
> application's SWF into its own ApplicationDomain, the  subApplication has
> its own definition of SystemManager which is not the same definition as
> the main Application's SystemManager.  You can almost think of an
> ApplicationDomain as a decorator on the runtime's class identifier (the
> qualified name may be mx.managers.SystemManager for both), but the runtime
> has effectively stored them as mx.managers.SystemManager@MainSWF and
> mx.managers.SystemManager@SubSWF.  And thus, the cast will fail.
> I'm pretty sure the reason the styles were having a problem is also due to
> some expectations about ApplicationDomain topology.  By default, SWFLoader
> in the browser sets up a topology you have not mentioned, which is a
> "child ApplicationDomain" topology.  So far it sounds like you tried
> loading into the main ApplicationDomain and having a separate
> ApplicationDomain, but your browser app was loading into a child
> ApplicationDomain so that classes that both SWFs had would use the main
> app's definition and classes unique to the subSWF would be in their own
> AppDomain.  The style code might have expectations about that.  That's why
> having a simple test case would be useful.  It would hopefully let us
> write a blog post that says "if you are converting SWFLoader from Browser
> to AIR, here is what you need to change".
> In your current separate AppDomain topology, you may find more issues
> passing data types between the SWFs.
> HTH,
> -Alex

Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Reply via email to