Idealism is what precedes experience; cynicism is what follows...

Tuesday, July 08, 2008

Adobe Flex : The Undocumented StaticEventDispatcher

There is an undocumented feature of the Flex Compiler which can come in quite handy.

If you have wanted to listen for changes to static variables, there is an undocumented static variable called "staticEventDispatcher" on classes that have one or more static variables prior to compilation.
The way it works is that as part of compiler pre-processing, the Flex compiler adds a static EventDispatcher object to the class, which eventually can be used to listen for PropertyChangeEvents on the class-reference itself.

If the class does not have a static variable at compiler preprocessing time, the staticEventDispatcher is not added. Despite the i-logic of the fact that a public static property (getter/setter functions) does NOT result in the pre-processor adding the staticEventDispatcher reference it can off course be worked around by adding a variable which references the function in which you have not broken the "contract" of the class, but still have "triggered" the Flex compiler to add your staticEventDispatcher.

The code below is just exploratory-code, and should off course NOT be used anywhere, it just proves the point about the discrepancy about static properties and variables.
public static var getSomethingFunction : Function = something as Function;
public static function get something() : String { return "Hello World"; }

This feature of the Flex compiler is very closely related to an undocumented class in the Flex framework, its the StaticPropertyWatcher which extends its more wellknown cousin, the Watcher class in the same mx.binding.* namespace.
Seeing that the StaticPropertyWatcher actually uses the staticEventDispatcher mechanism of the Flex compiler, and seeing that the ordinary Watcher class uses the StaticPropertyWatcher there is no reason not to use this feature.

However, an important point is that in order to ensure forward-compatibility I recommend that you use the staticEventDispatcher in a more type-strict fashion then the StaticPropertyWatcher implementation.

The following excerpt is taken from the StaticPropertyWatcher, and as you can see - they reference it through the class-index and not directly. By doing this you don't allow the compiler to capture classes attempting to use the static EventDispatcher reference without having a static variable resulting in runtime errors in situations where you don't check for it's existance prior to use.
        parentObj = Class(parent);

if (parentObj["staticEventDispatcher"] != null)
{
for (var eventType:String in events)
{
if (eventType != "__NoChangeEvent__")
{
var eventDispatcher:IEventDispatcher = parentObj["staticEventDispatcher"];

eventDispatcher.addEventListener(eventType, eventHandler, false,
EventPriority.BINDING, true);
}
}
}


In the above case its not possible to do a more type-strict notation seeing that its generic framework code, however in cases where the code is more business-logic-oriented the following notation would make a bit more sense for the compiler
parentObj.staticEventDispatcher.addEventListener( PropertyChangeEvent.PROPERTY_CHANGE, onSomeobjectChange );

This is the preferred way and also a pretty cool way to listen for changes to static variables, despite the fact that its not documented.

No comments:

Blog Archive

My Network