New & Improved Flex/Flash Data Binding

I’m just finishing up the development of another weak-referenced data binding. The implementation I’ll be releasing soon works seamlessly with Flex and Flash projects, ensuring that application bindings don’t cause memory leaks. And it’s smaller and faster than Flex’s built-in BindingUtils

What is Data Binding?

Data binding is something of an advanced programming concept, though once implemented it’s easy to use and receive immediate benefits. Binding is primarily used to connect one or more components to a single data source. As the properties update on the data source, that change is reflected by those components, automatically.

Not only does data binding save you from the manual labor of keeping your data in sync, it lets a data source remain ignorant of these bound components. Just like an EventDispatcher, any number of listening objects can be subscribed to the property changes of the source. In fact, binding uses event dispatching at its core. Because of this decoupled relationship, data binding has become a popular solution for MVC frameworks. In an application framework, the Model holds data central to the application, while many Views watch (are bound to) changes in the Model’s data. When application data changes, Views system-wide update automatically.

Compared with Flex?

Adobe’s Flex framework relies heavily on its built-in data binding. The solution is not only convenient, but it has become central to the Flex development workflow, particularly in MXML with “curly-brace” binding: The downside to Flex-based data binding is when modules and components are removed from display, but remain stuck in memory. For applications that continually create and destroy components this behavior becomes a severe memory leak. When a Flex binding is added it stores a strong reference to both the source and the target of the binding. Unless released manually, this reference will hold both objects in memory, even when every other reference has been removed (read more about Flash’s garbage collection) To learn the details of Flex data binding, watch the recording of Michael Labriola’s 360|Flex presentation.

Unfortunately there is no solution to the memory-leak problem for MXML curly brace bindings. These type of bindings are deeply integrated with the rest of the Flex framework though the compilation process of Flex Builder. It might be interesting to note that components added to the display via MXML tags are held in memory anyway, regardless of binding. So the solutions I’ve developed replace Flex’s ActionScript binding, BindingUtils.

Solution

A while back I developed a wrapper class to Flex’s BindingUtils. This new BindingUtils implemented an almost identical API, but through a proxy and a weak-reference Dictionary each binding target would be able to be removed from memory by Flash’s garbage collection cycle, despite the binding’s references (weak reference, remmber?). This wrapper class finally allowed Flex binding to have the same advantage as the EventDispatcher, which has the optional parameter weakReference:Boolean when adding a listener. The new BindingUtils also has the method releaseBindings(target:Object):void which cleans up all bindings to and from the specified target, regardless of whether they were created with a weak or strong reference. Of course this allows easy clean-up for responsibly minded developers who know when an object is being removed from memory.

In conclusion, I’ve just finished a second binding implementation. The new class Binding doesn’t rely on any Flex code at all, but works perfectly with Flex [Bindable] properties. The class is small, fast and, of course, uses 100% weak-reference’s to keep binding working only as long as you need it too. The implementation can be used in place of the mx.binding.utils.BindingUtils in a Flex project, but will be particularly useful in an AS3 project. Because Flex projects already pull in the Flex binding code, so you might as well use what’s available (through the weak-reference wrapper BindingUtils)

Both binding implementations will be available with the Flight Framework, which will be released at the beginning of the new year (not tomorrow though)

13 Responses to “New & Improved Flex/Flash Data Binding”

1. najier says:

   January 1, 2009 at 8:08 am

   Perfect. Just the solution we have all been waiting for.

   Can u send me an email when u have posted the code. I would like to try this out ASAP.
2. Alan says:

   January 1, 2009 at 8:32 pm

   Why use ‘{}’ binding anyway. I always set dataproviders manually, generally in some kind of ’show’ function, and set the dataprovider to null on any ‘hide’.

   If I am going through the effort to use a proxy databinding class, why not just set data providers to null upon removing them.
3. Jim says:

   January 8, 2009 at 10:54 am

   Tyler,

   I would also like to say that I am quite interested in the code you’ve described here, as it may be relevant to a project I’m working on myself. As such, if it’s not too much trouble, I’d also like to be informed and/or see it in action myself whenever you get the chance to make it available.

   Thanks in advance.
4. Andre says:

   January 12, 2009 at 8:09 am

   Hey,

   cool stuff =) I just ran into a problem with mx:Binding tags in loaded Modules which prevented the Module from beeing garbage collected.
   Your Solution is obvioulsy the most elegant one. Can you send me your code or an swc lib? would be very much appreciated!
5. xtyler says:

   January 12, 2009 at 4:03 pm

   Alan – cleaning up after yourself is by far the best policy. Some systems are large and complex and it can be hard to track the many points of failure, so a better binding solution is convenient and can save time and money.
6. xtyler says:

   January 12, 2009 at 4:04 pm

   Jim and Andre – Both binding solutions will be available with the release of the Flight Framework, an MVC application framework. I’ll be the first to post when that’s available, it’s undergoing final documentation.
7. Michael Hoisie says:

   January 13, 2009 at 4:42 pm

   I’m also looking forward to this code being available My projects generally don’t use the flex framework, so it would be nice to have some data binding mechanism.
8. Jonathan @ JADBOX.COM says:

   January 26, 2009 at 11:02 pm

   Any chance of this utility being released my itself without the framework attached? This would be valuable in even small projects. Email me if you need a beta tester.
9. xtyler says:

   January 27, 2009 at 8:13 am

   Thanks for the input Jonathan! The Flight Framework with which the data binding will be shipped is an open source library. You can include the .swc or classes (in part or in full) in any project and pick and choose what utilities you want to take advantage of. The only requirement under the MIT license is that the license itself, copyright and credits, remain intact within the source code.
10. Greg Baker says:

    February 7, 2009 at 9:43 am

    I too am interested in your solution. This was to be fixed in Gumbo > 4.0.0.4330 … but seams not. I am using the Mate framework and a Presentation design pattern with lots of module loads/unloads. This problem is a big pain. I did not find your previous solution “…a wrapper class to Flex’s BindingUtils.” Anyway, I would be interested in this to try with our modular application(s). — Thank you.
11. xtyler Custom Binding Released! says:

    February 17, 2009 at 3:05 pm

    [...] as promised. It has a smaller memory footprint, a faster clock-speed and, best of all, it’s 100% [...]
12. xtyler says:

    February 17, 2009 at 4:07 pm

    Both data binding solutions have just been released. The first one I built was never publicly available until now – but I highly recommend Flight’s Bind solution over the proxy wrapper around BindingUtils, as it increases memory and slows performance on top of Flex’s already-slow bindings. The new AS3-only solution works seamlessly with Flex and has memory/performance improvements on top of the weak-reference feature.
13. Thoughts On Sproutcore and App Dev In General « lukesh +interactive says:

    January 2, 2010 at 8:35 am

    [...] have the advantage of not being the first in that they can fix all the things that Adobe has done wrong. It all looks really promising except for a few things, which I’ll discuss in a [...]