Flex Chronicles #24: ApplicationControlBar, ApplicationDomain, & Event Metadata

Layout with ApplicationControlBar

ApplicationControlBar has some weird borders that can make it screw up your layouts. Meaning, if you have a Canvas with 100% width and height, and have theApplicationControl bar in it, your Canvas will get scrollbars . Easiest way to fix is to (like a lot of things) wrap it in a Canvas with width and height of a 100%, as well as your vertical andhorizontalScrollPolicies set to “off”. That’ll make it flush and not cause scrollbars. This works for other components as well that give you layout grief.

ApplicationDomain

I used ApplicationDomain successfully for the first time this week. Short version is that you can now, as of Flash Player 9, control how your classes are used by loadedSWF’s. In Flash Player 8 and below, if you loaded a SWF , and each had the same class, they’d both use the parent (defined on _global). This was done for a few reasons, the 2 main ones being that most people don’t want childSWF’s overwriting classes in the “shell SWFs” and secondly for security reasons. Flash MX 2004 (maybe MX had it, can’t remember) introduced the exclude.xml file which allows you to name the file the same as the FLA, place it in the same directory, and list out all the classes you DIDN’T want Flash to compile into theSWF. For large Flash websites / applications, this was great because you could share classes in the main swf with multiple other ones, thus saving a few kilobytes (23k on one project I was on with 30 SWF’s using classes from that pile). On larger sites with booku amounts of traffic, this is a big deal.

Using ApplicationDomain (don’t worry about security for right now), you basically have 3 choices how you want to handle classes in the Flash Player, specifically forrun-time loaded SWF’s.

  1. Partition the SWF into it’s own black box; it uses the classes it was compiled with, and doesn’t touch the parent SWF’s classes that loaded it.
  2. Adding the classes to the parent SWF; this is how Remote Shared Libraries work (think loaded run-time DLL’s… I think)
  3. Sharing, meaning the child SWF can utilize the parent’s classes. This is the default behaviour, and is in part what the Module’s concept is built upon.

I used #1 this week, and it worked great. Mike Britton is creating a dashboard charting application, and has his own code base. I’m loading his dashboard into an application I’m working on that is an entirely new code base with a different version of Cairngorm as well as my personal modifications. Loading his SWF via the standard SWFLoader doesn’t work at all since his SWF see’s my classes (like ModelLocator), and fails to attempt to use them since they have different data then they were compiled with. Merely specifying a unique ApplicationDomain for his classes to live in makes it work great.

var appDom:ApplicationDomain = new ApplicationDomain();
loadedSWF.loaderContext = new LoaderContext(false, appDom);

Furthermore, I can even pass it needed data via calling a function he has exposed for me on his Application.mxml file. Current problem is it’s not strongly typed, but we’ll probably use an interface later:

public function onComplete():void
{
var obj = loadedSWF.content; // of type SystemManager, but in different namespace I think
        var o = obj.application; // of type Appilcation in specific namespace
        var r:Boolean = o.someMethod(Model.getInstance().someData);
DebugWindow.debug("r: " + r); // prints out true
}

I got Modules working the reverse way, but… I’ve found Modules are no different than premature optimization; they are a pain in the ass to work with so best left till later in my opinion… depends on your deadline and team workflow obviously.

Event Metadata Reboot

Finally, Library Projects. I’m using them for Cairngorm 2.1 (just in case I have to modify ServiceLocator again…), my Cairngorm mods, and a front end API to our back-end services that multiple applications / vendors will eventually use. Every time I save a file in any of those projects, it’ll re-compile an SWC file. I’ll then run an Ant build.xml file in my main project that copies the updated SWC’s, if any, to my Flex Project’s lib directory. The downside to this is my code-clicking (when you hold Command / Control, your code turns into hyperlinks) doesn’t work because it looks inside of the protected SWC’s instead of my Library Project directory. The upside, however, is my code base is purely for the project only so is… somewhat more navigate-able . It’s also easier to work in those code bases by just closing all projects and leaving just the 1 Library Project open; easier to focus.

The main problem, though, is code hinting for addEventListener. You get those when you use the [Event] metadata tag. While I can do a project refresh after I’ve copied the SWC into my project to get updated code hints, the addEventListener ones don’t work. I have to reboot FlexBuilder to get those to show up. If you don’t know what I mean, they look like this:

When you choose one and hit enter, it’ll type the event name and type for you. If you use the [Event] metadata tag, you can make these for your classes as well. That way, when I distribute the SWC, it comes with helpful code hints. Rebooting the IDE to get these is kind of lame, though. Refresh and Clean don’t work.

One Reply to “Flex Chronicles #24: ApplicationControlBar, ApplicationDomain, & Event Metadata”

Comments are closed.