1 person found this helpful
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.
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...