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 Comments

  1. Posted on January 1, 2009 at 8:08 am by najier

    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. Posted on January 1, 2009 at 8:32 pm by Alan

    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. Posted on January 8, 2009 at 10:54 am by Jim

    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. Posted on January 12, 2009 at 8:09 am by Andre

    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. Posted on January 12, 2009 at 4:03 pm by xtyler

    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. Posted on January 12, 2009 at 4:04 pm by xtyler

    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. Posted on January 13, 2009 at 4:42 pm by Michael Hoisie

    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. Posted on January 26, 2009 at 11:02 pm by Jonathan @ JADBOX.COM

    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. Posted on January 27, 2009 at 8:13 am by xtyler

    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. Posted on February 7, 2009 at 9:43 am by Greg Baker

    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. Posted on February 17, 2009 at 3:05 pm by xtyler Custom Binding Released!

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

  12. Posted on February 17, 2009 at 4:07 pm by xtyler

    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. Posted on January 2, 2010 at 8:35 am by Thoughts On Sproutcore and App Dev In General « lukesh +interactive

    […] 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 […]

The comments are closed.