So i have a situation where i want to pass a object of a class say 'MyBigAwesomeClass' from a child to a parent. I import the class definition into both the parent and child.
Now, if i load the child swf from a location that is relative to the location of the parent , all is fine, however the moment i load it using a full absolute path, it treats the definitions for 'BigAwesomeClass' in parent and in child as different and does not allow an object of the type 'BigAwesomeClass' to be assigned to an object of the same in the parent class.
I am totally stumped, and have banged my head over ApplicationDomains, including using this code
loader.contentLoaderInfo.addEventListener(Event.COMPLETE,swfLoaded);
var context:LoaderContext = new LoaderContext(false, ApplicationDomain.currentDomain);
loader.load(new URLRequest(_file.url),context);
To absolutely no avail. Any ideas as to what can i do it fix this ?
Thanks in advance
I would agree with you that the problem probably has to do with the parent & child's Application Domain, but in order to answer more accurately , it 'd be good to have some example use of the class you would like to share between the parent and the child.
In theory it seems the problem could be avoided if a class was defined for the child as well... Here's a very basic example that in my opinion should work wherever you load the child from.
One option is to use implement a method in the child class to return an instance of the class using it's own applicationDomain, eg:
The
IMyBigAwesomeClassLoader
would look like this:The parent clip would then use this to get the instance from the child when it's loaded:
The reason to use interfaces here is to decouple the class definition from its implementation. Even though the class in the parent and child SWFs have the same name, Flash treats them as different classes. The interface tells Flash that they can be used in the same way even though they are different.
Flash uses static typing, which means that once a class is defined it will never change, which means it will never over-write one class definition with another. So if there are two classes with the same name, it is necessary to use
getDefinition
to resolve the conflicting names. If you want to avoid this added complexity, you can use different names or name-spaces for the class in the parent and child SWFs.According to Adobe's documentation (Loader#securityDomain):
The trick is telling Loader to check the crossdomain file when loading the swf, by passing
true
as the first parameter when creating theLoaderContext
, eg:The accompanying cross-domain.xml should be located in the same location as the child SWF, or in one of its parent folders. Here's a non-restrictive cross-domain file according to documentation from Adobe:
One other thing that might make this easier for you, is to pass the interface instead of the class, which would effectively bypass conflicting code. This will work because the child inherits the interface from the parent class by default at runtime (see Loader#applicationDomain point #1). The child class can then safely instance it's own version of each object as long as that object adheres to the interface. For example:
The definition for MyBigAwesomeClass would then look something like this:
Well it turns out its a Sandbox Issue. Files that are not part of the installer are placed in a different Security Sandbox, and since they reside in different sandboxes, the child when imported into the parent does not inherit the definitions of its Parent in the
ApplicationDomain
and two separate definitions exist which are incompatible. Sadly, there seems to be no direct way of resolving this. Adobe does allow communication between sandboxes via the SandBoxBridge, but that forces you to use Object type, which kind of defeats the purpose of the whole thing. As far as i can tell there is no way for classes in two different sandboxes to be compatible even though they are exactly the same. I guess its back the painfull world of no strict typing with Objects.