shared class between two different swfs

[milkmit]

I have a wrapper swf which loads a main content child swf. Both swfs compiled with the same custom event class, which I use to communicate from the child to the parent wrapper.

I've noticed, quite often, that if I make changes to the child swf, export, upload & test within the wrapper again, it sometimes behaves a little unpredictable. But once I export the wrapper swf again, upload, and test once more, it works.

There's *nothing* changing within the custom event class, nor anything else that would directly effect the wrapper/child relationship. It seems that almost any changes I need to make to the child that require a recompile to see *also* require me to recompile the wrapper. Why is this happening?

(Specifically, the wrapper loads the main content swf, and then once it is loaded & initialized, it fires an event to the wrapper to let it know it's ready (incase it needs to overwrite any settings). Only then does the wrapper tell the child to begin doing its thing. That is the extent of the relationship between the two.)

[senocular]

Any definitions within the wrapper SWF will be shared by (overriding) definitions in the content SWF. This includes any referenced definitions as well. So while you know the Event class is shared, there may be other classes that are also shared by references. For example does that Event class have any variables of the type of other custom classes? If so, they will be compiled with the wrapper SWF as well and override any differences within the content SWF.

There are some tools out there that can inspect what classes are in your SWFs, including decompilers or other AS classes. If you happen to use FlashDevelop, it provides a drop-down for SWFs in your projects panel listing out the classes your SWFs have (which is helpful for this sort of thing).

Alternatively, you could also load the content SWF into a completely new and separate Application Domain using the Loader class. This will separate your definitions and prevent the wrapper's from interfering with the content's.

[milkmit]

Hmmm, interesting.

Assuming the only references between the parent wrapper swf and the child content swf are:

-custom events (being dispatched from the child, and being listened to from within the wrapper) with no variables of the type of other classes -- meaning both swfs have the same custom event class included
-a simple reference in the wrapper swf to call public functions in the child swf after the child is loaded

...should I be concerned about a coupling issue like the one I mentioned in the original post? To be clear, I'm *not* talking about changes to the custom event class that both share; just other changes solely within each swf.

Unfortunately, I don't use FlashDevelop (I'm on a Mac, though I know there's porting tools I can use to run it), though I wish the Flash IDE had something like that.

Thanks. This is a difficult situation for me to understand, as it seems hit or miss for me when I'm testing, and I can't see exactly where the problem lies.

[senocular]

The concern is that classes in both SWFs use the versions of those classes defined by the loader SWF. How that affects you depends on how you use those classes and when/if they change

[milkmit]

I see. That's right, you said that the loader swf (the child) overrides the definition of the parent.

So assuming nothing ever changes with the custom event class that both swfs share (nor the content swf's public API, which may include a way to pass an XML object from the wrapper to the child), should I be free to make whatever changes I want within the child content swf OR the parent wrapper swf, assuming (again), that the changes doesn't effect the custom event and API?

[senocular]

note that by loader I meant the parent SWF - the SWF that loads the child. Its definitions have precedence.

Any changes in either SWF in classes not shared should not cause a problem.

[milkmit]

note that by loader I meant the parent SWF - the SWF that loads the child. Its definitions have precedence.

Any changes in either SWF in classes not shared should not cause a problem.

Ah, ok, great. Thanks for the clarification.

This should work out fine, then, I believe. It's a pretty crazy architecture I'm working with, but seems necessary as the child content in this case is a video player that will be under continuous development, and I'd hate to have to re-export the wrappers with each player change (there will be multiple versions for different layouts/usages) each time as well.

Thanks again!