Building a Plugin Architecture with Adobe AIR

Question

I'm thinking of choosing Adobe AIR as the client-side implementation technology for an upcoming project. (The previous choice was C# and WPF, but I've been really impressed with Flash/Flex/AIR lately.)

But one of the most important features of my product will be its plugin architecture, allowing third party developers to extend the functionality and GUI in interesting ways.

I know how I'd design the architecture in C#: A plug-in loader would enumerate all of the assemblies in the local "app/plugins/" directory. For each assembly, it'd enumerate all of the classes, looking for implementations of the "IPluginFactory" interface. For each plugin created by the factory, I'd ask it for its MVC classes, and snap its GUI elements (menu items, panels, etc) into the appropriate slots in the existing GUI layout.

I'd like to accomplish the same thing within AIR (loading plugins from the local filesystem, not from the web). After reading this article, my understanding is that it's possible, and that the basic architecture (loading SWFs into sandboxed ApplicationDomains, etc) is very similar to the way you'd do it in .NET.

But I'm curious about the gotchas.

If any of you have done any dynamic classloading with the flash player (preferably in mixed flash/flex apps, and ESPECIALLY within the AIR host), I'd love to hear about your experiences building your plugin framework and where you ran into tricky situations with the flash player, and with the flash, flex, and AIR APIs.

For example, if someone asked me this same question, but with the Java platform in mind, I'd definitely mention that the JVM has no notion of "modules" or "assemblies". The highest level of aggregation is the "class", so it can be difficult to create organizational structures within a plugin system for managing large projects. I'd also talk about issues with multiple classloaders and how each maintains its own separate instance of a loaded class (with its own separate static vars).

---

Here are a few specific questions still unanswered for me:

1) The actionscript "Loader" class can load an SWF into an ApplicationDomain. But what exactly does that appdomain contain? Modules? Classes? How are MXML components represented? How do I find all of the classes that implement my plugin interface?

2) If you've loaded a plugin into a separate ApplicationDomain from the main application, is it substantially more complicated to call code from within that other appdomain? Are there any important limitations about the kinds of data that can pass through the inter-appdomain marshalling layer? Is marshalling prohibitively expensive?

3) Ideally, I'd like to develop the majority of my own main code as a plugin (with the main application being little more than a plugin-loading shell) and use the plugin architecture to hoist that functionality into the app. Does that strike fear in your heart?

Answer 1

1. The applicationDomain is more like a namespace, it groups class definitions and put them into a hierarchy: a domain can directly access the symbols in its own domain or in the parent domain, but not in child or sibling domains (or better: it can't do that directly - it must go through the applicationDomain object, asking the definition of a given class); when loading an external swf you can decide where to put the new symbols: a child domain (default), a new domain attached to the system (using null), the current domain, a domain attached somewhere else (explicitly passing the parent of the new domain). Note that new symbols will never overwrite symbols in the current domain, but the same name can exists in multiple domains.
   Unfortunately you cannot enumerate the classes in a given domain (well, at least I don't know any way to do it), but the common solution is to require (as in "The Plugin Interface") the presence of a well-known factory in each swf, which will return either the definition (Class) of the plugin or the plugin itself.
2. You just have go get a reference to the object somehow (the factory), then it's just another object. There's no marshalling: the domain it's just a logical partitionning of the namespace (it's a tree branching of the system domain).
3. No :) But be warned: it may easily turn into a hell for the GC, where unused domains cannot be unloaded due to references spread in other domain. I suggest taking a look at the multi-core PureMVC framework, possibly with pipes for ensuring a strict separation between the plugins.

Btw, Flash Player also a concept of security domain, but I actually never touched it, so I don't known what the possibilities are here.