Flex gives us 4 different techniques to use DataBinding:

• Curly Brackets in MXML
• Binding tag
• BindingUtils
• ChangeWatcher

Lets have an overview of the possibilities of each technique:

Curly Brackets in MXML

The most obvious one: Binding a source value to a destination value:

This works also for readOnly properties and static constants. You can omit the Bindable metadata tag because the Binding is only triggered at application startup. Static variables are not supported (the Adobe docs are not correct at this). Also Binding to style properties are not supported.

To add 2 way Binding simply use the curly brackets syntax in both objects crosswise:

[code lang="actionscript3"]


[/code]

Here some code examples for Actionscript and E4X expressions:

[code lang="actionscript3"]
// Method calls and calculations


// Perform string concatenation


// Perform a conditional operation using a ternary operator


// E4X expressions

[/code]

A nice feature which is probably not typically used in your daily work, is the possibility to bind to functions. You can use a function as source for your Binding:
To make this work you have to mark the function with the Bindable metadata tag and define your custom event name. When you dispatch an Event with your selected event name the Binding is triggered and the destination gets the return value of your function.

[code lang="actionscript3"]

       


[/code]

As we have seen in the previous post Binding in MXML is not the fastest solution.
Your better choice for writing high performacne applications is BindingUtils:
You have 2 static methods: BindingUtils.bindProperty and BindingUtils.bindSetter

[code lang="actionscript3"]

    




[/code]

The name of the arguments in the API are a little bit confusing (at least for me).

[code lang="actionscript3"]
public static function bindProperty(site:Object, prop:String,
            host:Object, chain:Object,
            commitOnly:Boolean = false):ChangeWatcher
[/code]

The first 2 parameters are the destination object and property name, and the last 2 the source object and property name.

• site:Object -> destination object
• prop:String -> destination property name
• host:Object -> source object
• chain:Object -> source property name(s)

Binding supports changes on every bindable element in the source chain. If one element is changing the Binding is triggered.
You can specify the chain as a single String for the name of your property (if there is only one chain element) or as Array of property name Strings for each bindable chain element.

[code lang="actionscript3"]
// bind to object: user.setting.volume
BindingUtils.bindProperty(myText0, "text", user, ["setting", "volume"]);
[/code]

But there is another possibility to set the chain argument:
You can pass an Object in the form:

[code lang="actionscript3"]
{ name: propertyName,
  getter: function(host) { return host[propertyName] }
}
[/code]

This Object must contain the name of the property and a function returning a value, which is normally a getter function for a public bindable property of the source object.
This feature opens interesting possibilities.
The function is basically a wrapper which returns the value of the source. I am not sure at the moment where to use this, but it´s good to know that there is an open door…

When using chains with BindingUtils you can choose if the chain elements in-between are bindable.
If an element in-between is not bindable, no Binding is triggered if this element changes.
This is not the case when you use the chains in MXML. You got a compiler warning and a runtime exception if one of the in-between elements are not marked as bindable.

Here is a code example for using chains:

[code lang="actionscript3"]



public class User
{
    [Bindable]
    public var setting:Setting;
    public function User(setting:Setting)
    {
        this.setting = setting;
    }
}

public class Setting
{
    [Bindable]
    public var title:String = "blabla";
    public function Setting()
    {
        setInterval(function():void {
                     title = int(Math.random()*10000).toString()
                     }, 100);
    }
}
[/code]

The ChangeWatcher is the class used inside of BindingUtils. ChangeWatcher implements the event handling and the handling for the chains. BindingUtils are just a more convenience way and adds nearly no overhead compared to use ChangeWatcher directly.

Here are some additional snippets about DataBinding:
You can use multiple [Bindable] tags. Doing this lets you trigger Binding from different events.

When you use Binding in MXML the addEventListener method uses a weak reference.
This is important due the fact that you cannot unbind with the curly brackets syntax. Without weak reference Binding in MXML would be a potential memory leak.

When using BindingUtils you are responsible for calling the unwatch() method on your ChangeWatcher object (a ChangeWatcher object is the return value of BindingUtils.bindProperty). The addEventListener method in the ChangeWatcher is not using weak references, so if you don´t do your housekeeping carefully, this could lead to a memory leak.

In UIComponent there is the method executeBindings() which force a trigger to all Bindings on this component. This could help sometimes when a Binding is not firing by it´self correctly, but of course should be taken carefully because it´s probably just healing a symptom not the underlying problem.

When you use the [Bindable] metadata tag before a class definition, it only applies to public properties; it does not apply to private or protected properties, or to properties defined in any other namespace. You must insert the [Bindable] metadata tag before a nonpublic property to make it usable as the source for a data binding expression.

The DataBinding reference can be found at Adobe LiveDocs.

• Performance
• Features (beyond the obvious ones)
• Generated Code under the hood

So lets start first with a closer look at Performance:
It is clear that such a nice feature has it´s overhead.
For small and medium applications this probably will not be even noticeable. The benefit´s for rapid development will knock out the performance considerations. But when you work on larger applications you may come to a point where you have to take care of every possible bottleneck. And the sum of a lot of small improvements will give you a considerable performance boost at the end.

Lets have a look to different approaches to set a value from a source to a destination object:

• Binding in MXML with the curly brackets (or the Bindable tag)
• Using BindingUtils (or ChangeWatcher) in Actionscript
• Custom Event dispatching
• Setting the property directly

I created some tests passing a random value from a source to a destination with 10 000 iterations and repeated this tests 10 times to get a good average value.
Here are the results:

• Binding in MXML: 412 ms
• BindingUtils: 188 ms
• Event dispatching: 146 ms
• Write property directly: 81 ms

So there is a considerable performance penalty when using Binding in MXML. For small projects this probably will not be a problem, in large applications where a lot of Bindings are triggered, this could be a noticeable drawback. It could slow down the application startup, when all Bindings are initiated.
A good thing on MXML Binding is that it gives you the highest level of pre defined errorhandling. Because most of the generated code can be checked at compile time, it gives you warnings if you going to mess up something. With BindingUtils the possibility of runtime errors is already higher.
Another plus for MXML is that some features are only supported with MXML Bindings (Actionscript expressions, E4X Expressions,…).

The difference between BindingUtils and EventDispatching is not so huge, but in some cases you can gain a bit if you handle it by your own event dispatching.

The fastest way of course is setting a property directly and could be your good friend in really performance critical areas. But the support for a loosely coupled architecture is not as good as with the other solutions.

There are some further fine-grained improvements possible when using your own event name instead of the default “propertyChange” event. In the Bindable metadata tag you can specify a custom event name.

[code lang=”actionscript”][Bindable (event=”myCustomEventName”)][/code]

Doing this, the Flex Compiler will not auto-generate code for you, like it is the case when you use [Bindable] without setting an event name. So you have to write a bit more code and dispatch an Event with the given event name. But doing this you can gain some performance improvements.

Here are the test results:

• BindingUtils with custom event names ([Bindable (event=”myCustomEvent”)]): 150 ms
• BindingUtils with the default (“propertyChange”) event name ([Bindable]): 188 ms

Doesn´t sounds too exciting, but that´s not all:
When you have a large class with a lot of bindable properties the performance gain will grow with the number of properties, because all Binding objects have to be checked if one property in this class will change.

Separating properties with custom event names, will speed up performance again.

The test scenario:
Change 10 different properties in one class with 10 custom events versus changing 10 properties in a class with the default event name (do 10 000 iterations).

Here are the test results:

• Test Binding with different Event names: 1511 ms
• Test Binding with the default “propertyChange” event name: 2657 ms

So now the difference is quite huge.
Of course to have too much properties in one class is often a result of bad design and should not be the typical use case. But it´s good to know where to tweak if performance issues arise.

Here is the code you have to write by yourself if you use custom events.
It is basically the same the compiler auto-generates for you when you use [Bindable] without a custom event name.

[code lang="actionscript3"]
private var _myLabelText:String;
[Bindable(event="myLabelTextChanged")]
public function get myLabelText():String
{
    return _myLabelText;
}
public function set myLabelText(value:String):void
{
    if (_myLabelText !== value)
    {
        _myLabelText = value;
        dispatchEvent(new Event("myLabelTextChanged "));
    }
}
[/code]

References:
Watch out the great presentation about DataBinding by Michael Labriola: Diving in the Data Binding Waters
Links: Slides

It´s also worth to have a closer look to the DataBinding reference at Adobe LiveDocs.

The test project is linked here, in the View Source context menu the sources are attached.