One thing nearly all DI frameworks have in common, is the use of reflection to obtain the extra information needed to inject the objects.
The downside of this approach is that reflection in general (and particularly in Flash) is pretty slow. This will probably not matter much for smaller application, but for large apps you can save several seconds of start-up time if you are not using reflection.

Unfortunately there is no solution out there beside a project from Joa Ebert, who is using a different approach. I wrote about this in another blog entry.

Another solution would be to use code generation.
With code generation you can inspect your code base at compile-time and write the information needed to a class.

I have added such a project to the nucleo library at github.

So how does it look like and how is it used?
Here are a few code snippets from the mojito example at github:

First we need the generated class for the constructor parameter keys. This will be created by an ant task, more about this later.

[code lang="actionscript3"]public class ConstructorParameters extends AConstructorParameters {
protected override function config():void {
constructorParameterKeys[BarProvider] = [IWaitress];
constructorParameterKeys[Bar] = [IWaitress];
constructorParameterKeys[Client] = ["theFewSpanishWords", IBar];
constructorParameterKeys[Waitress] = ["isInTheMood"];
}
}[/code]

You need to create the Config class which contains the mappings of the objects used for injection.
It passes an instance of the ConstructorParameters class to the AConfig super class.

[code lang="actionscript3"]public class MojitoConfig extends AConfig {

public function MojitoConfig() {
super(new ConstructorParameters());
}

override protected function setup():void {
mapInterface(IClient).toClass(Client).asSingleton();
mapParameterName("theFewSpanishWords").toInstance("¡Muchas gracias guapa!");
mapInterface(IBar).toProvider(BarProvider).asSingleton();
mapInterface(IWaitress).toClass(Waitress).asSingleton();
mapParameterName("isInTheMood").toInstance(true);
}
}[/code]

Then the setup can be done. After that you can access some root object and use this.

[code lang="actionscript3"]// first we need our Config. This is the place where our injection
// mappings are defined.
var config:MojitoConfig = new MojitoConfig();

// createInjector is a package level function used for convenience
// to get the injector
injector = createInjector(config);

// we take the root object out of the injector. The other objects will
// be injected just in time when they are needed.
var touristInBarcelona:IClient = injector.getObject(IClient);[/code]

Beside this, there are no traces left from the framework.

The Classes which gets created by the DI container are straight classes with constructor parameters totally unaware of the framework.
They don’t need any “Inject” Metadata tag. They does not know anything from the DI framework and how they get created. This is not their responsibility.

I think this is violated by the use of the Metadata at other DI frameworks. There the class has the information inside itself that a DI container is used for creating an instance of this class. I think this should be only the responsibility of the outer world using this class like a factory or the DI container.

But back to the project.

How does it work internally?

Basically the injection works pretty simple as a chained instantiation of all the dependent objects, starting with the first object requested from the injector:

[code lang="actionscript3"]var touristInBarcelona:IClient = injector.getObject(IClient);[/code]

This will create an instance of the class which is mapped to the key IClient. In our case it is the Client class.

[code lang="actionscript3"]mapInterface(IClient).toClass(Client).asSingleton();[/code]

For creating the Client class it looks up in the ConstructorParameters Class and get the information to create the 2 arguments needed there:
The instance mapped to “theFewSpanishWords” and an object of the class mapped with the key IBar.

[code lang="actionscript3"]constructorParameterKeys[Client] = ["theFewSpanishWords", IBar];[/code]

For creating an object of the Bar class it will need other objects as well, so the chain goes on like this until all objects needed are resolved.

The binding key can be an Instance, a Class or a String (named annotation).

For the named annotation I use a simple convention:
The parameter name must be the same as the annotation name in the Config class, like the “theFewSpanishWords” in the example. I think there is no reason not to use this simple and sensible convention and it makes life much easier and there is no need to add a Metadata for packing in this information.

I only support constructor injection as I prefer this style and it lets the class stay free of any Metadata.
Property or method injection could also be added but then you need to mark them with Metadata. As they would be invoked directly after the class is created i don’t see any reason why not to add these injected data to the constructor.

Now have a look to the code generation:

I used the as3-commons-jasblocks project which is using ANTLR. With this Java project you can read in your sources and it creates an object tree with all the elements of your code (abstract syntax tree). From this you can comfortably grab the constructor parameters and write (again with jasblocks) them into a class file.

I packed this into an ant task, as ant is pretty easy to use, good integrated into the IDEs and well known.
In the ant task you need to setup 2 parameters:

• The source directories (as comma seperated list)
• The target directory for the generated Class.

To automatically trigger the code generation for the ConstructorParameters Class before the compilation, you can use the built-in support for ant tasks of the IDE.

In FlashBuilder and IntelliJ there are easy ways to achieve this. So if the setup guarantees to always run the ant task before the compilation, the ConstructorParameters Class will be always up to date.

Here a quick description how to do this in FlashBuilder:

• Right-click in the project and open the project properties.
• Under Builder add a new Ant Builder before the Flex (compile) builder.
• Under Main point to the build file: eg. ${workspace_loc}/${project_name}/build/build.xml
• Under JRE: select separate JRE

That’s it.

In IntelliJ you need to set an “Execute On” event (“Before Compilation”) to the ant task target. Then it will be executed just before the compilation.

If you don’t like to use the code generation you can also write this class by yourself of course, you just have to maintain it and it violates the DRY principle.

A few words about code generation in general:

For some people code generation has a kind of bad smell and they don’t like to rely on it.

I think it is a very powerful tool to get around the limitations of the language and to outsource boiler plate code.
And if you use Flex you are using it anyway even if you are not aware of it. Flex use a lot of code generation behind the scenes (add the -keep compiler flag to see it) for creating ActionScript code out of MXML, css files, RPC or Data Binding.

I think for the coding experience and productivity it is not only the potential of the language which counts, but also the features of the tools (IDE) you are working with.
What would you (as a developer writing code) benefit much from a type system if you would write your code in a primitive text editor without any code completion or error highlighting (the old Flash IDE was like this, I cannot imagine anymore how to work that way).

With these tools you can get also over the shortcomings of a language.

So I think when you hit the limitations of the language or runtime, it is valid to go in this direction and add features to help you to write clean and fast code.

There are also some limitations and the project is at the moment just a kind of “proof of concept”. It is not bulletproof yet and not tested in a production environment!

So use it at your own risk. I added comments and TODOs in the Java source code about known issues.

One limitation is about external library (swc) files.

With the as3-commons-jasblocks project you can only inspect the code base you have as source code, but not the code compiled into libraries.

There are some solutions (like flagstone) to access this as well, but I have not added this yet.

With the providers (see docs and example code) you always can get around any problems with classes out of your control like 3rd party libraries.

Beside this I think DI should only be used in a limited scope of a project (module).

Basically his API is orientated on Google Guice and does not use reflection, which is great, because reflection is pretty expensive regarding performance.

And Performance matters. We reduced the start-up time of our application from 8 seconds to 3 seconds just by removing Spring Actionscript and using a pure factory-based DI which does not use reflection and has no performance overhead. The code was also better to manage then the XML based solution of Spring Actionscript. Other frameworks which are more in the Guice-style would be nice to use but have the same negative impact on performance, so it was a No-Go for us. The drawback of our factory-based solution compared to Guice-style frameworks was, that it was not so easy and nice to use and more boilerplate code has to be written.

When stumbling over Joa Eberts DI framework I first wanted to use it directly as 3rd party library but I got some problems with the compiled swc. So I started to build my own small DI framework based on previous ideas in this direction and refined with some of his ideas and a similar API style. Unfortunately I cannot share the code but I can give the basic ideas.

So let’s get started:

First you need to setup the Locator. It’s a one-liner and is done like this:

[code lang="actionscript3"]myLocator = Locator.getLocator("myScope", myContext);
[/code]

The explanation for this will follow later.

Further you have a Context Class (the Module in Guice) where you define the bindings of what you want to get injected for a special Interface, Class or named annotation.

Additionally you define if the object should be only created once (asSingleton) or every time newly.

[code lang="actionscript3"]// Interface to Class
bind(ITestInterface).to(TestImpl).asSingleton();
 // String annotation to Class
bind("myList").to(ArrayCollection);
// Interface to instance
bind(IResourceManager).to(resourceManager).asSingleton();
[/code]

To support also some special classes which are outside of your control (3rd party) you can use a Provider to get an instance created in a custom fashion in the Providers getObject() method.

[code lang="actionscript3"]// String annotation to Provider
bind("myServcice").to(RemoteObjectServiceProvider).asSingleton();
[/code]

When you want to inject these objects somewhere in your Classes, just write inject(bindingKey) to obtain the instance defined in the Context.

But when not using reflection we are facing some problems.

Without reflection you don’t have information at run-time about the constructor arguments. This is a problem when creating the classes. One solution to prevent this problem is to use only constructors without arguments.

Instead of the classical way like here:

[code lang="actionscript3"]public function TestClass(testInstance:ITestInterface) {
    this.testInstance = testInstance;
}[/code]

We assign the mandatory members directly in the constructors body with the inject call.

[code lang="actionscript3"]public function TestClass() {
    testInstance = inject(ITestInterface);
} [/code]

Another solution would be to register the Class with it’s parameters annotations explicitly to the framework, so the information what needs to be injected when creating this Class is available.

Something like this (you can use a static function call as it is specific to the class, so it could be located directly above the Constructor):

[code lang="actionscript3"]registerClass(TestClass).withParams([ ITestInterface, "myList" ]);
public function TestClass(testInstance:ITestInterface,
                           myList:ArrayCollection) {
    this.testInstance = testInstance;
    this.myList = myList;
}[/code]

This would have the drawback that you need to maintain changes in the parameters in 2 places, and additional code needs to be written.

My preferred solution without constructor arguments has the drawback that the mandatory parameters are not visible in the signature of the constructor.
So both has some small penalties, but the good thing is it has zero overhead performance-wise and it is as easy to use like the classic Guice style injection.

Of course you can use the injection in properties or methods as well. But i prefer the constructor injection for all mandatory dependencies, so it’s more clear what a class needs initially.

So how does it work:

Technically it is not real injection but more like the Locator pattern.
You have a Dictionary where you define the mappings of keys (Interface, Class or named annotation as String) to instances, Classes or Providers.

What happened when calling the inject() method inside the Locator?
It looks up for the value stored for the given key.
That can be:

• An instance, so return it.
• A Class, so create an instance of this Class and return it.
• A Provider. Create an instance of the Provider and call the getObject() method to get back an instance which is created in a customized way and return this instance.

The optional asSingleton() call is handling the behavior if the object is cached or not.

So why not use the Locator pattern?

When using the Locator  pattern you need the instance of the Locator. You can pass the Locator in the constructor to not rely on a static dependency inside your class.
That would be fine, but there is a more elegant way.

You can use a package level function (native Flash Functions like getTimer() or trace() are using this technique), so you can call directly the function without reference to the Locator. Inside the function it forwards the call to the package level property which got assigned the reference to the Locator from the setup. The “dependency” is only the package in which these 2 files are defined. If you follow a clear architectural structure this results in the positive side effect, that your Locator is used only in the correct scope and protects from cross-scope misuse.

Note that the file name must be the same like the Function or Property names (inject.as, myInjector.as) and only one Function/Property is allowed.
Here are code examples like these 2 files could look like:

[code lang="actionscript3"]package org.yourDomain.yourProject {
	public function inject(bindingKey:Object):Object {
		return myInjector.inject(bindingKey);
	}
}[/code]

[code lang="actionscript3"]package org.yourDomain.yourProject {
	import org.yourDomain.Injector;
	public var myInjector:Injector;
}[/code]

The myLocator property gets the concrete Locator instance assigned at the setup.

[code lang="actionscript3"]myLocator = Locator.getLocator("myScope", myContext);[/code]

Scopes:

When having a single project you probably don’t need to use different scopes, but this becomes important for larger projects. As different projects are normally using different root packages, the projects root package would be a perfect candidate for the scope key.
When you add the package level property and function file into these packages, you have in every project the access to the right scope of your Locator (need to import them where used).

The Locator implementation is pretty straight forward.

It does the management of the scopes as well as the mapping and handling (creation) of the instances when the inject() is called. I used the fluent interface style but you could implement the Binding also with a plain function and parameters.

Some final discussion:

So you may ask that fetching dependencies is not the same like injecting them, and classes should get the dependencies from outside instead of fetching them from inside.

Yes that is basically true.
But why it is better to get it injected?

Because normally to fetch something you need a reference to the container from where you get it. In classical ServiceLocator patterns it is mostly a Singleton.

[code lang="actionscript3"]ServiceLocator.getInstance().getObject("myObject");[/code]

Better would be to inject the ServiceLocator in the constructor, so the provider of your dependencies is free configurable and you don’t need to change your class if you want to use a different implementation of the provider.

It is not about getting or fetching, it it about to keep the class clean from static dependencies.

With the solution using package level functions it is less code needed to be written and has the benefit to implement a scope mechanism which can serve as protection.

Maybe it depends on the architecture and structure of the project if this approach makes sense. Another solution would be to pass the scope to the Constructor of the Class and lookup for the Locator inside the constructor with the scope key. Or simply pass the already resolved Locator instance typed as Interface to the Constructor.

So using it a bit different, the good old ServiceLocator mimics the fancy Guice-style Dependency Injection without really hurting, but saving a lot of performance.

Unfortunately the Flex 4 components suffer from big performance decrease (163% slower). But just read the article it is very profound discussed there.

I have had recently a look to Unity in search for alternatives to Flash, and was wondering why they are not supporting the Flash Player. They already supports a lot of different platforms, but Flash was missing. I thought the technical limitations and differences would be a too hard barrier.

But now they released the news that they are working on the support for exporting Unity projects to the Flash platform as well as to Android, IPhone (and the rest of the I… derivates), XBox, Mac/PC desktop apps and their Unity Web Player (Linux Player is in development). It is becoming a real tough multi-platform tool! This could have a deep impact, as Unity seems from technological point of view much more advanced then Flash and the main barrier for using it in the web, was the low player penetration of the Unity Web Player. So it was locked to the special cases where the installation of a new plugin is no problem for users, but unfortunately for 90% of the mainstream clients and projects this is a no go. But with this strategy they will get in one move the support of the 99% penetration of the flash player (ok, with the latest player version that is not correct, but people don´t care so much about an update of the Flash Player then about a new installation of an unknown plugin).
And Adobe is getting a real strong competitor, so hopefully they are forced to pay more attention to performance and development environment. The current Flashbuilder is compared to the tools available for Java or .NET not very competitive, to express it friendly. I have not worked with Unity yet, but will use the next opportunity to try it out.

I am also wondering how much they can cover outside the classical 3D world? Flash has started as a pure animation tool and has become a main player for web application development. I bet the inventors didn´t expect this. So why should not Unity become a tool also for classical applications, 3D comes free if needed, and it seems that 3D will become more and more an intrinsic part of up to date software. 3D-TV sets and Mobiles are currently the hot thing and I think it´s only a question of (hopefully not too much) time, until 3D displays are common also at desktops. 3D content will be the missing link then.

Unity is just ready to take off!

Looking forward also to the new Flash Player (Molehill) which brings GPU-accelerated 3D to the Flash platform.

I discussed this topic already with many developers but nobody could really give me a satisfying answer.
So I spread out my thoughts now to the public in the hope to get some valuable feedback.

Of course I am familiar with the concept of the Flex Life Cycle and the “elastic racetrack” behavior of the Flash Player.

The reason why I am not a friend of this concept is because it introduces an asynchronous code execution where a synchronous code execution would be much easier and faster.

In all my ActionScript based projects it was never necessary to use this pattern and defer code execution to another frame (or Render Event).
At bwin we have built a similar application as the current Flex-based Live Betting application previously in AS2, with a lot of complex components and auto layout containers, without running into any serious problems.
And to be honest the performance of the AS2 project felt somehow the same as the Flex version. But AS3 is about 10 times faster (of course that´s a bit too simple said and we did not measure the difference, but I am not the only one complaining about poor Flex Performance).

So isn´t it valid to question the concepts Flex is based on?

I am sure the architects at Adobe have had good reasons why they decided to introduce this pattern.
In the Docs and Blogosphere one can find several papers about it, but none of these explanations satisfied me, and some are not telling the full truth (that code execution is deferred to another frame).

So I try to discuss some assumptions for possible reasons:

• Avoid Performance bottlenecks
• Keep the Frame-rendering fluidly
• Avoid Performance penalty from unintended repeated method (setter) calls
• Pattern for separating different concerns
• Problems with reading out the measurements of DisplayObjects before they are rendered on screen
• Problems with complex execution flow from auto-layout containers code

So let me add my thought to these points:
Avoid Performance bottlenecks

That was my first assumption when I started with Flex, that this pattern is used to avoid performance bottlenecks. First I thought there is a hidden mechanism for detecting code execution which is running too long and delay this execution to the next frame. After checking out the SDK code I found out that it is simply delaying the 3 phases to 3 “half-frames” (Render Events and Enter Frame Events). So if you have really heavy code your player is still freezing up for a certain time and the Life Cycle does not give you any support for solving this problem.

That leads to the next argument:
Keep the Frame-rendering fluidly

Delaying the render code to the next frame helps the Flash Player running more smoothly and fluidly. That is basically true, but in my opinion 90% of the time the Life Cycle is wasting performance. For me it is a bad trade to get maybe at startup time some more fluidly running pre-loader animation but startup time takes much longer.

Why the Life Cycle is wasting Performance?
Because code which normally would be executed in one frame is now executed over 2 frames (or more).

There is another related issue with performance:
Avoid Performance penalty from unintended repeated method (setter) calls

Assume that in a large project it could be hard to control the execution flow so that it could happen that setting a text or layout property to a component is not only applied once but unintended multiple times.
For this scenario the Life Cycle helps because the call to the setter of the property is relatively cheap, so if the setter is called 10 times instead of once it will not hurt much. Then at commitProperties the property is only applied once to the component.
Again some weird scenarios with multiple invocations of commitProperties will not hurt much because the applying of the property to the component should be protected by a “changed” flag (see best practice with the Flex Life Cycle).
Also if you need for layout code some measurements the pattern helps to avoid unnecessary and repeated code executions.
BUT – is poorly written code really the reason why this pattern was introduced? It is true that it gives you some kind of fault tolerance, performance-wise. I guess this argument should not count in professional software development, and in fact it is dangerous because it could hide some deeper problems. If your setters are called more then once, why not look for the reason and clean it up?
I know in complex situations this could be sometimes hard, and under real life circumstances and time pressure you have to deal with something like this. But it should not count as a criteria for such a basic framework design decision.

I made also some measurements to check out the performance penalties for repeatedly called setters:

With 100 000 iterations applying a changing text to a TextField (in a AS3 project) I got these results:

1. Case:
Setting the text property to a variable in a loop and then applying the already stored text to the TextField again in a loop:

[code lang="actionscript3"]setText(): 119ms
applyStoredText(): 481ms
[/code]

In contrast to applying the property directly to the TextField:

[code lang="actionscript3"]
setAndApplyText(): 2879ms
[/code]

So you can see it is much slower in the 2. Case, so the Life Cycle really helps here, because it only applies the last stored property and not the changing values in between. But again – setting multiple times unnecessary property values is another problem.

The same test with setting the x position does not deliver such a big difference, in fact it is nearly the same time consumed (40+52 vs. 114)

[code lang="actionscript3"]setXPos(): 40ms
applyStoredXPos(): 52ms
setAndApplyXPos(): 114ms
[/code]

Let´s continue with the next point:
Pattern for separating different concerns

To have a kind of pattern which separates different concerns is basically a cool thing. So you have your code block for setting properties, another method where the properties are applied to the component, a method where the measurement is defined and another one for the layout code.

I have no really argument against this pattern, but I don´t know why it is necessary to defer some code of these phases to the next Frame. The execution of the Life Cycle methods could have been triggered also at the Render Event, then there would not have been any delay to another frame, even it still would add this nasty asynchrony.

So this pattern could make development easier but introduce asynchronous behavior where we lived in a beautiful synchronous Flash world before. In my opinion: Not a good trade.

What else?
Problems with reading out the measurements of DisplayObjects before they are rendered on screen

Remembering back to some of my Flash projects I have had sometimes strange problems with TextFields and measurement when setting text and using autosize. But I could not reproduce these problems in a test case anymore. So I am not sure if that was caused by some other stuff or maybe by differences in some older Flash Player versions? But at least in my situations these problems could always be solved without deferring code to another Frame. But at this point I am not sure if there are certain use cases where you cannot read out the size of a DisplayObject (TextField) before it is actually rendered to the screen. If there are such cases this would be a valid argument, but then I am wondering why this could not be solved on the Flash Player level instead of solving this problem at a Framework level.

And my last point:
Problems with complex execution flow from auto-layout containers code

I can imagine that complex situations with nested auto layout containers could be sometimes really tricky to handle. To avoid recursions or unnecessary calls for any possible situation in a generic framework is a tough challenge.

But also in complex situations it is a deterministic behavior, so it should be possible to solve this without the Life Cycle pattern as well. From my experience there was no problems with auto layout containers, but of course in normal project development you have limited use cases and we were not forced to deal with all the possible use cases, like Flex has to do as a generic framework.

So finally I don´t have any idea for the real reason why Adobe has introduced the Life Cycle.
Maybe it seemed that it could help solving a lot of tricky problems (auto layout containers, mixing MXML with AS code,…) and was considered as a good pattern to make development easier. Maybe the fact that Flash has a strong support for Event driven programming and the Flash developers are already used to handle this asynchrony, led to this decision?
Maybe is was a strategic decision to make Flex easier for new developers without Flash background, who were not familiar with the Flash Players frame-based execution model?

I don´t know. I really would appreciate if someone from the Flex Team could illuminate this topic.

I just have made the experience that many things where much more transparent, cleaner and faster in pure ActionScript then in Flex, and i think the Life Cycle is one of the reasons for that.
I really like the API of Flex but I am wondering why Adobe don´t give more attention to performance, specially for large scale applications.

Any comments or insights are highly appreciated!

P.S.: Just found an interesting post related to this. I 100% agree what Paul Taylor says about UIComponent, but that is another story. Ever heard about Reflex? Sounds pretty promising!

Lets assume that we have a css file with type selectors and class selectors, a module based application and some custom components which are designed the way that you can use them out of the box and that they can be individually skinned and styled by other developers reusing them. That´s what custom components are for, right?

So the first question is:
How are the styles compiled into your swf file?
Assume that they are defined in an external css file. You know you can compile css files to swf files and load them at runtime or simply compile them into your application at compile time with a simple assignment like this:

[code lang="actionscript3"]
 
[/code]

Here is the content of our simple css:

[code lang="actionscript3"]
Button
{
	color: #990000;
}
.myCustomStyle1
{
	color: #009900;
}
 /*
     some additional styles here...
     like Button.myCustomStyle2
*/
[/code]

That´s what we will use for our example here.

In this case the MXML compiler creates a bunch of classes and inserts the css definitions right into a method called from the constructor in the generated Applications class.

[code lang="actionscript3"]
public function StyleExample() {
	mx_internal::_StyleExample_StylesInit();
}
mx_internal function _StyleExample_StylesInit():void {
	var style:CSSStyleDeclaration;
	// Button
	style = StyleManager.getStyleDeclaration("Button");
	if (!style) {
		style = new CSSStyleDeclaration();
		StyleManager.setStyleDeclaration("Button", style, false);
	}
	if (style.factory == null) {
		style.factory = function():void {
			this.color = 0x990000;
		};
	}
	// myCustomStyle1
	style = StyleManager.getStyleDeclaration(".myCustomStyle1");
	if (!style)
	{
		style = new CSSStyleDeclaration();
		StyleManager.setStyleDeclaration(".myCustomStyle1",
                                           style, false);
	}
	if (style.factory == null)
	{
		style.factory = function():void
		{
			this.color = 0x009900;
		};
	}
	// similar code follows here....
}
[/code]

I only pasted the relevant code, so this is not complete but should give the basic idea.
So what happens here?

A CSSStyleDeclaration is created for the given stylename or class if it´s not already existing in the StyleManager (at a modular application some other application could have already created this style). Then the definitions from the css file (here the color property) are added to the factory function.
It is interesting that the class selectors and type selectors are treated the same way regarding storing the style object in the StyleManager. It is simply the selector name which is used as the key in the _selectors Object (hashtable). Only the “.” in the selector name is the visible difference.

[code lang="actionscript3"]
    public function setStyleDeclaration(
                                selector:String,
                                styleDeclaration:CSSStyleDeclaration,
                                update:Boolean):void
    {
        styleDeclaration.selectorRefCount++;

        _selectors[selector] = styleDeclaration;

        // Flush cache and start over.
        typeSelectorCache = {};

        if (update)
            styleDeclarationsChanged();
    }
[/code]

The CSSStyleDeclaration has also a defaultFactory which is used if there is no factory defined (no css file). Additionally there is an overrides Object which is used to store styles set at runtime vial setStyle(), but this will not be further considered yet.
This leads us to the next part:
How should a default style be applied to a custom component?

How Flex is handling this? The MXML compiler generates a bunch of style classes:
For instance a style class for the Button:

[code lang="actionscript3"]
public class _ButtonStyle
{
    public static function init(fbs:IFlexModuleFactory):void
    {
        var style:CSSStyleDeclaration =
                         StyleManager.getStyleDeclaration("Button");
        if (!style)
        {
            style = new CSSStyleDeclaration();
            StyleManager.setStyleDeclaration("Button", style, false);
        }
        if (style.defaultFactory == null)
        {
            style.defaultFactory = function():void
            {
                this.fontWeight = "bold";
                this.paddingTop = 2;
                this.cornerRadius = 4;
                this.textAlign = "center";
                this.verticalGap = 2;
                this.horizontalGap = 2;
                this.skin = mx.skins.halo.ButtonSkin;
                this.paddingLeft = 10;
                this.paddingBottom = 2;
                this.paddingRight = 10;
            };
        }
    }
}
[/code]

This class is added to the mixins array at the generated _StyleExample_mx_managers_SystemManager class.
The mixins are a strategy to get injected some code at application startup before anything else is instantiated. It calls the static init method, so it is executed before the actual classes constructor is called.
A similar strategy with a static initializer is used in some classes in the datavisualisation package to pack some default styles into a component, so that there is no dependency that there are some styles assigned to the component from outside.
That´s seems to be a pretty nice way to setup the default style a component needs. If the user of the component wants to set some different styles, it can be applied easily via css, styles set in mxml or at runtime via setStyle (if possible, this should be done in the preInitialize phase to avoid performance penalties).

One thing which should be considered when using styles (specially in a large application with modules) is the fact that the style declarations are stored with the selector name as key in an Object (hashtable). So if 2 developers are using the same selector name they end up with a conflict that the later instantiated module will use the already created style and not the one which was compiled to the module.
The same applies if you use the same stylename inside one application, the first one used wins.
To get rid of this problem a kind of namespace strategy can be used ([modulename] + “stylename”). Unfortunately the Flex framework does not give any support for this problem.
Tell me if you know a more elegant solution!

LangDetecten>de YahooC

MXML

A great code formatter as Eclipse plugin for Flex Builder: http://code.google.com/p/flexformatter
Download: http://sourceforge.net/projects/flexformatter/

HP has published a security analysis tool for Flash content. It´s also a decompiler to inspect the Actionscript code: SWFScan

Good overview about security issues in Flash:
http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html

A great resource for open source flash/flex tools and projects: http://www.flashchemist.com/104-free-opensource-apis-libraries-and-tools-for-the-flash-platform.html

If you have a dodgy problem that a certain property is not available when it already should be and you ask someone at flexcoders you often get the advice, “try callLater” for a quick work-around. Sometimes this helps, but it leaves a bad smell, because often it´s just hiding some other problems in the code.
So when we worked on a large-scale Flex application we have used it sometimes in the beginning, but after a while we decided to avoid callLater. To find and solve the real problem is simply the better solution – and we never needed it again – there was always another solution to solve a particular problem (maybe we just have had luck).

Unpleasantly we get confronted with the fact that callLater is used inside the Framework at the heart of the layout engine.
We struggled with some strange problems. For instance we got a NullPointer exception in the updateDisplayList method of a custom component, which has already been cleaned up properly and removed from the displayList. It turned out that the layout mechanism delayed with callLater an invocation of updateDisplayList but our stuff there has already been removed and threw an exception.
It was not hard to fix, but it demonstrated us that some asynchronous stuff was going on behind the scenes which was out of our direct control.

So for me callLater leaves always a certain bad smell.

Unfortunately I never found time to really investigate how it´s implemented and what are the concepts behind it.
So it was time to catch up with this issue:
CallLater is basically a method in UIComponent which delays a passed function to the next EnterFrame OR Render event.
Often in den docs it´s just described that it will delay to the next frame, which is not correct because it could be that your function is executed already at the Render Event, which happens in the same frame and is the last opportunity where User code can be executed before the screen is rendered.

For more details about the internal concept of a frame in Flash and the relevant events see the great article by Sean Christmann:

Here is a good illustration from his article about the anatomy of a frame in Flash:

All functions passed to callLater are queued up in an array and are executed at the EnterFrame event or Render event. It is possible that the executed function has some other callLater invocations again, so the final execution sequence could be delayed over several frames.

CallLater is used inside the Flex Framework in several classes. The main use case is probably inside the LayoutManager.
There is a concept called phased instantiation which means basically that at application start-up the 3 phases in the UIComponents life-cycle (validate properties, validate size and validate displayList) are not executed in one pass, but are delayed with callLater to 3 half-frames. Half-frame because the Render event happens in the same frame as the EnterFrame event.
This should reduce performance peaks at application-startup and should increase the UIs responsiveness.
You can also use it later on in your application if you have to render heavy stuff, to balance the load across frames.

So far so good. But…
First let me emphasis that I am sure that the SDK architects has had some good reasons for implementing callLater, but it introduces an asynchronism which could be hard to control. Normally with async stuff you have an event driven approach, so you get informed when the async task is done.
With callLater it´s not so clear when the last callLater is really finished. There is an UpdateComplete event in UIComponent and LayoutManager which helps to get informed when the last callLater is executed, but in-between, you don´t have control about the distinct moments of your function calls.

Another issue is that you cannot control if your heavy load is really spread over 2 frames. It could be that it is just executed inside one frame at the EnterFrame event and at the Render event, so it could be that you don´t win anything from the load-balancing perspective.

Performance-wise there could also be perceptible delays caused by repeatedly callLater executions.

I guess there are many special situations in the framework code (probably mostly measurement stuff) which are difficult to handle, but i guess it should be possible (maybe I am too optimistic?).

There seems to be a problem to get the correct measurement when you set a new text in a TextField before the frame is actually rendered (see this post at flexcoders), but if this is an unsolvable problem then it should be urgently fixed in the Flash Player.

References@livedocs:
callLater()
usePhasedInstantiation

If you feel this would be a nice feature, vote for it on the Adobe Bugbase.

You probably have seen already the Flex Style Explorer. It gives a good overview of the different styles of the standard Flex components.

BTW: Did you know that parts of Flex Builder are open source (the derived stuff from Eclipse)? You can download it at Adobe.

When you compile a Flex application the compiler runs the compilation in 2 steps:

• The mxmlc compiler generates a lot of Actionscript classes
• The compc compiler compiles from the generated classes plus your custom classes the swf file

These 2 steps are normally not visible, because the generated code is not stored in your project. If you add the compiler argument -keep (or -keep-generated-actionscript=true) in your compiler settings in Flex Builder, you will see a generated folder inside the src folder containing a lot of Actionscript files.

There are different kinds of files generated:

• Classes defining the default style for Flex components
• Classes holding the Resourcebundle properties
• Classes for embedded skins
• Classes for Flex Application setup
• Classes for Flex DataBinding

The style, skin and property files are out of our scope here and has no direct relation to this topic.
The classes which are used for setting up a Flex Application are our entry point, but will not be discussed in detail (even it would be very interesting to have a closer look to Mixins, [Frame] metadata tags and all these exotic stuff…).

So lets look at our relevant classes for DataBinding (all others has been removed):

The entry-point of our Flex application is _DBGC_mx_managers_SystemManager.
This class extends SystemManager. The SystemManager is the main class and the first DisplayObject added to the stage. It does a lot of setup stuff.
At the first frame in our MovieClip the preloading is handled. At the second frame the Application (DBGC) is instantiated. In the static info() method the mixins classes are defined. At frame 2 the mixin classes are inited via the static method call init().

The DBCG class (file: DBCG-generated.as) is our Application class.
Here the MXML components are converted to UIComponentDescriptors which handles the instantiation of these Components.
At initialize() an array of Binding objects are created.
The Binding class use anonymous functions for resolving the source and destination properties.

[code lang="actionscript3"]
var binding:Binding = new mx.binding.Binding(this,
    function():String
    {
        var result:* = (bindableVO.myBindableProp);
        var stringResult:String = (result == undefined ? null : String(result));
        return stringResult;
    },
    function(_sourceFunctionReturnValue:String):void
    {

        myLabel.text = _sourceFunctionReturnValue;
    },
    "myLabel.text");
[/code]

The _DBGCWatcherSetupUtil creates an array of PropertyWatcher objects, setup the relationship for chains and pass the Binding object to the PropertyWatcher.

[code lang="actionscript3"]
watchers[0] = new mx.binding.PropertyWatcher("bindableVO",
    { propertyChange: true },[ bindings[0] ], propertyGetter);
watchers[1] = new mx.binding.PropertyWatcher("myBindableProp",
    { propertyChange: true },[ bindings[0] ], null);
watchers[0].updateParent(target);
watchers[0].addChild(watchers[1]);
[/code]

After the basic setup execute() is called on every Binding object.
Here is the complete code:

[code lang="actionscript3"]
override public function initialize():void
{
 	mx_internal::setDocumentDescriptor(_documentDescriptor_);

	var bindings:Array = _DBGC_bindingsSetup();
	var watchers:Array = [];

	var target:DBGC = this;

	if (_watcherSetupUtil == null)
	{
		var watcherSetupUtilClass:Object = getDefinitionByName("_DBGCWatcherSetupUtil");
		watcherSetupUtilClass["init"](null);
	}

	_watcherSetupUtil.setup(this,
				function(propertyName:String):* {
                                     return target[propertyName];
                                },
				bindings,
				watchers);

	for (var i:uint = 0; i < bindings.length; i++)
	{
		Binding(bindings[i]).execute();
	}

	mx_internal::_bindings = mx_internal::_bindings.concat(bindings);
	mx_internal::_watchers = mx_internal::_watchers.concat(watchers);

	super.initialize();
}

private function _DBGC_bindingsSetup():Array
{
    var result:Array = [];
    var binding:Binding;

    binding = new mx.binding.Binding(this,
        function():String
        {
            var result:* = (bindableVO.myBindableProp);
            var stringResult:String = (result == undefined ? null : String(result));
            return stringResult;
        },
        function(_sourceFunctionReturnValue:String):void
        {

            myLabel.text = _sourceFunctionReturnValue;
        },
        "myLabel.text");
    result[0] = binding;

    return result;
}
[/code]

So lets jump into the Binding Class. This is a regular Framework class.
The execute() method is basically applying the source value to the destination. In-between there is a lot of error handling going on, but basically it´s nothing else as reading out a value and setting it to the destination. No event dispatching is included until now.

The setting of the value happens on start-up. If the bindable property changes later, event dispatching comes in.
This happens in the PropertyWatcher class:
An event handler is added at the source object and the PropertyWatcher is listening for the defined event type. It is invoked with weak reference, so the fact that MXML Bindings cannot be removed will not lead to memory leaks.
The event handler checks if the dispatched PropertyChangeEvent contains the same property name as our PropertyWatcher represents and calls notifyListeners() if the property name matches.
On every Binding object which is registered as listener watcherFired() is called.
And here again the execute() method is responsible for passing the value from the source over to the destination.

The last missing link is the class which dispatch the PropertyChangeEvent.
The BindableProperty (file: _BindablePropertyVO-binding-generated.as) is the place where this happens.

[code lang="actionscript3"]
[Bindable(event="propertyChange")]
public function get myBindableProp():String
{
    return this._834029286myBindableProp;
}

public function set myBindableProp(value:String):void
{
    var oldValue:Object = this._834029286myBindableProp;
    if (oldValue !== value)
    {
        this._834029286myBindableProp = value;
        this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this,
                                  "myBindableProp", oldValue, value));
    }
}
[/code]

Here the gettter/setters are created for our [Bindable] property. The compiler defines “propertyChange” as event type – [Bindable(event=”propertyChange”)] and dispatches a PropertyChangeEvent if the value has changed.
If the class containing the bindable property is not a subclass of EventDispatcher the compiler set the classes interface of BindableProperty to IEventDispatcher, adds the methods of IEventDispatcher and uses an instance of EventDispatcher via composition.

Note that this code is only generated when you don´t use custom events in the [Bindable] metadata tag ([Bindable(event=”myCustonEvent”)]).

I don´t know how this class is linked into the Application, it has no reference anywhere. I guess the compiler do this job behind the scenes, as well as with the interface classes and some other stuff.

Lets have a look to the moments when DataBinding is executed:

At Application start-up the Binding is executed for the first time.
Here is the call stack (Breakpoint at Binding.execute():

Due the fact that the component is not created yet, the Binding fails in a catch Block at wrapFunctionCall() in the Binding class. The catch block is pretty slow, i am wondering why this initial execute() is not prevented? At least the try/catch could be replaced with a check against null which is much faster then falling into the catch block. I guess in large applications this could noticeable slow down start-up time.

At the time the component is added to the Application executeBinding() is called and triggers the second execute().

At this point the component is valid but there is only the value passed which is defined in the property declaration. This value is often not set at this momens so it is null.

If you setup your initial value at the initialize event a third run will be triggered:

You can prevent this if you set the value right at the variable declaration (if possible) and so prevent to trigger DataBindings third round.

Conclusion
Finally we are through the basic parts how DataBinding is working behind the scenes. To go further it´s best to step through the generated code and try out different scenarios.
We only have had a look into Binding in MXML. If you use BindingUtils just the code for event dispatching from the [Bindable] metadata tag is created.

The generated code for DataBinding with MXML do a lot of error handling. it´s clear that it has some performance drawbacks but gives the benefit that it is very fault-tolerant. You also should consider that there are a lot of different features and use cases for Binding (functions, expressions, 2-way Bindings,…) which has to be handled.

For large applications BindingUtils are the better choice and prevents several performance drawbacks, specially at start-up time.