2 Replies Latest reply on Jun 1, 2010 2:04 PM by Harbs.

    Extension life-cycles

    Harbs. Level 6

      I'm trying to weigh my options with an extension which has a number of windows which can be loaded in more than one way.



      1. There's a significant amount of processing which must be done when the extension is loaded (or at least for some of the windows). I'd rather only have to process that data once per session to avoid delays while the windows are loaded.

      2. A lot of the data structure should be shared between different windows.

      3. I'd like to be able to invoke the windows by script or another extension.


      Options as I understand them:

      1. I can create a bundle with separate extensions for each window.

      3. I can create one extension with multiple windows (as in the CSXSWindows sample).


      Are there more options which I'm not aware of?


      Problems with #1:

         a) Each extension is a separate swf which makes the memory footprint much higher.


         b) I can't think of a good way of sharing a data model between the different swfs. Is there one that I can't think of?


         c) When each window is closed, as far as I can tell, the lifecycle of the extension is over and all the data must be re-loaded next time the window is open.


      Problems with #2:

         d) I'm not sure how to load a window of an extension from a script.


         e) I'm pretty sure that even if I figure out how to load the window from a script (or other extension), the main extension (say the panel) must be open. It's got to be a big pain to work around this issue.


         f) Windows are a real pain to work with in the design mode of Eclipse/Flash Builder. (At least on my system) you can not see the whole area of the window. The only way I got it to work was changing it to "Application" while I work, and then change it back to Window before compiling the swf.


      Problems with both:

         g) When the main window of the extension is closed, the life-cycle of the extension is over, so all the data of the panel needs to be loaded each time the panel is opened.





        • 1. Re: Extension life-cycles
          irpaterson Adobe Employee

          Hello Harbs,


          When you speak about the memory footprint increasing when you factor a bundle into multiple SWF-based extensions, do you have benchmark figures you are able to share? I am very interested in understanding more about how to design and implement non-trivial extensions like the ones you are building, and you already have a lot of experience I am hoping you can share around this.


          I hope that I am not going over what is old ground for you but here are some observations.


          Re #2. When you write about loading a window from a script, do you mean from ExtendScript? Does that mean you would have to call some kind of "load extension" from the ExtendScript context and then dispatch an event the extension could act upon to open its window?


          Re #1. The problem of sharing a model across different SWFs that have been Marshall Plan loaded (as CS5 extensions) you describe in #1 is an interesting one. This is my basic understanding and here's how I would go about building something like this myself, also to let my extensions restore their state gracefully after being unintentionally (or intentionally) closed by the end-users:

          • The Marshall Plan loading of the different SWFs (in CS5 extensions) means they're insulated from one another- they can't straightforwardly share code and data, so this is what you're noting already, but they can communicate via events.
          • CSXS events can be dispatched from one extension with application scope and be listened for in another extension, and you can send an XML payload that reflect the model changes (for instance) as a very basic mechanism to communicate change across your extension models
          • The example CSXSPrefsBase shows an interesting design, where persistent data is stored to a CSXS preference object by serializing the binary form of an ActionScript object to a Base64 encoded string. This is a very-very lightweight database, where you can imagine that you read and write the state of a shared model object from extensions, using perhaps CSXS custom events to communicate that the model has been updated and perform a read. Alternatively you could imagine serializing all your objects you want to restore state from on your extension starting back up from this kind of basic store.
          • I really like the idea of using SQLite from CS5 extensions, since they can use the AIR APIs like and there's a nice post on just using it from AIR on http://www.adobe.com/devnet/air/flex/articles/sqlite_db_api_in_air.html and I could imagine treating the database as the model accessed from multiple extensions- again, I would fasten on using CSXS events to dispatch a model-changed event to my extensions to get them to sync against the DB and maybe look at some object-relational mapping layer to help me write code more quickly if the model got more complicated.




          Best wishes


          1 person found this helpful
          • 2. Re: Extension life-cycles
            Harbs. Level 6

            Hi Ian,


            Thanks for the suggestions. I'll definitely take a look at those options!


            Events will probably get cumbersome, and will only help if the different parts are open. I had thought of using the Preference Object, but I have yet to examine that angle. I'll defintely take a look at that SQL example too!


            I have not done any profiling, but I think  it's a pretty safe assumption that the memory footprint will be greater when there's multiple swfs being loaded.


            As far as loading from scripts; yes, I mean ExtendScript. I imagine I might have the need to load from a different swf as well.


            Loading swfs are easy, but Windows seem to me impossible.


            What I'm thinking of doing is creating two swfs: One for the panel. (Each Panel much be a separate swf. Correct?) The second one will be an off-screen dummy window which will just act as a proxy to load the other ones. I wish there was a more elegant way to handle this though...