The forums have permanently moved to This forum will be kept around in read-only mode for archival purposes. To learn how to continue using your existing account on the new forums, check out this thread.

Page 2 of 2 FirstFirst 12
Results 16 to 19 of 19

Thread: ApplicationDomain for imported SWF

  1. #16
    ok. We'll do something simple: one parent, two children. Children use the same classes - the shared code. The parent may interact a little with the children, say, to tell them to go to a certain "section" which will be part of their API:
    public interface IChildSWF {
        function goToSection(sectionId:int):void;
    Scenario 1) Shared code. The parent SWF is compiled with the shared code classes and may include the interface type above. If the parent SWF does not use some of the shared code classes, you may need to force them into the compilation by stating them somewhere by name, for example just listing them in the body of the parent SWF document class.

    public class ParentSWF {
    When compiling the child SWFs, they can reference the shared classes as an external library so that they're not compiled within the SWF. You don't have to, but it reduces that redundancy (note that the SWFs will also no work on their own when doing this).

    When the parent SWF loads the child SWFs, it will do so in a child application domain (the default). The child SWFs will inherit the class definitions of the parent SWF and they'll be able to use the shared code accordingly. Everyone is happy.

    When the parent SWF needs to communicate with a child SWF, for example going to a new section, it can use:

    var childA:IChildSWF; // loaded and defined here
    childA.goToSection(1); // uses shared interface, same among all SWFs
    • If shared code, and shared code only changes, you only need to recompile the parent SWF
    • If child SWFs change but in a way that does not affect shared code, you only need to recompile that child SWF
    • If a single child changes, but also affects shared code, that child and the parent must both be recompiled.

    Scenario 2) Self-contained. The parent SWF and the child SWFs are compiled separately and work independently. They may each use the same classes and be compiled from the same classes on disk, but its possible they'll have different versions depending on when those classes are edited and when those SWFs are compiled.

    The child SWFs are loaded by the parent SWF into a new (non-child) application domain.

    Because the classes are not shared at runtime, they'll be different and incompatible. Something like the IChildSWF should not be used since it implies both the parent and the child SWFs would use that class and interact through it. Instead, the references to the child SWFs should use a basic, dynamic reference such as Object.

    var childA:Object; // loaded and defined here
    childA.goToSection(1); // dynamic look up of goToSection; no non-native classes referenced; will only fail if doesn't exist
    Any other interactions would need to be similarly dynamic. If you have complex parameters in method calls, they should be typed as * or Object.

    • When a SWF changes, only it needs to be recompiled, even if it changes code used by other SWFs (even if it breaks the other SWF; that SWF only needs to be recompiled when it changes, and breaking code in the shared codebase can be addressed then)

  2. #17
    Hi Senocular!
    I am back after 11 months, I am sorry, but here at work I can't experiment as much as I would like.
    Maybe I have a small time window to retry implementing this solution: external SWF with shared classes.

    I am creating an SWF containing the shared classes that will be inherited by child SWFs.
    Then you wrote "When compiling the child SWFs, they can reference the shared classes as an external library so that they're not compiled within the SWF. You don't have to, but it reduces that redundancy (note that the SWFs will also no work on their own when doing this).": how do I reference the shared classes as an external library without compiling them within the child SWF?
    Last edited by GiGaGiG; October 29th, 2014 at 12:57 PM.

  3. #18
    You reference them as external libraries. I forget exactly the process, and its different depending on what you're compiling with (builder, or pro). Doing a docs/google search on external libraries should point you in the right direction

  4. #19
    I did it in pro (2014) just to get the process:

    File > ActionScript Settings... > [Tab] Library path

    Add/select the library path with the code you wish to not to be included in the SWF when its compiled

    [Icon] Set linkage options for library (looks like an info "i" icon) > [Dropdown] Link Type: External

Page 2 of 2 FirstFirst 12

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Home About Meet the Moderators Advertise

 Link to Us


Copyright 1999 - 2012