You shouldn't have to make any special facility for getting the Facade to a Command because it happens to be in a library. It should extend SimpleCommand and so, when instantiated by the controller in your app, the Facade it will have access to is the one that's already been instantiated inside your app.
You may create a Facade in your library, but just use it to define constants. It should not have any methods, or ever need to be instantiated.
Your ApplicationFacade will register Commands against notifications names defined on the Facade in the library.
Generally, Commands in the library should handle the creation and registration of Proxies and Mediators in that library, reducing the burdon on the developer using the library.
Shortly there will be several really good examples of utilities available. In preparation for releasing 2.0 of the framework, I'm migrating all the demos. As I go, I'm extracting utilities.
For instance the CodePeek AIR Demo will yield 2 utilities;
- XMLDatabase for persisiting and working with XML databases,
- WindowMetrics for allowing all AIR apps to be good desktop citizens by remembering their desktop and monitor position as well as maximized state, and restoring it on startup.
And, because WindowMetrics makes use of XMLDatabase for persistence of info, we'll see examples of inter-utility dependence.
Also Phil Sexton and others here have really iterated the resource loading mechanism that's at the heart of Jens Krause's Application Skeleton demo, and so we'll have a StartupManager
utility with corresponding demo that shows how the resources to be loaded can be dependent on each other's completion.
Certainly return to this thread with any further questions you may have about creating utilities using the framework.
Oh, one last thing, definitely DON'T include the framework classes in your utility. Let the implementing app do that. And make sure you note which version of the framework your utility is compatible with.