Data binding is essentially tha synchonization of values, typically between the model and the views (read more here. For Flex applications data binding is typically accomplished with the [Bindable] compiler meta tag. For pure AS3 applications it’s been a roll-your-own world and some even use [Bindable] here as well. This is just wrong.

These are the reasons why BindMax is better than [Bindable]:

• Mobile loving
  Building mobile apps with AIR? Then you know it’s all about squeezing file size out and performace in. BindMax is an implementation of the observer pattern, which is a much simpler structure than the Flash Event bus. In fact it’s beautiful minimalism compared the Events. Smaller file size, better performance.
• Speed!
  For primitive data types BindMax is generally 3x faster than [Bindable]. Performance with complex data types obviously depends on how fast your compare functions are, if you have any. Without them, complex data types propagate just as fast as the primitve ones. The speed tests are included with the source so check for yourself!
• Early type checking
  A data binding is usually defined early in the application run cycle. When that happens, BindMax will evaluate each attempt to bind a property or setter against the data type of the binding and throw an error if the data types don’t match. With [Bindable], you get no errors until the target property/setter for that binding is used. For a property that is used only rarely, you may never even see that error until the client/user stumbles over that rare use case and tells you.
• Boot time property/getter/setter name validation on both sides of data binding
  Just as with type checking, BindMax validates that that the names match between the property or setter you bind a property or getter to.
• Easy custom compare functions for complex and custom data types
  Primitive data type values like numbers and strings are easy to compare. Complex data types like arrays, dictionaries and custom objects require special handling. For this scenario, BindMax provides setCompareFunction which lets you pass it a function reference to a custom function that takes two instances of the same class and returns true if they are equal.
• Optional automatic binding disposal
  To play nice with the garbage collector, BindMax lets you turn on automatic disposal of bindings which are no longer in use. When the last target for a binding is removed, BindMax will dispose of it.
• Previous value retrieval
  BindMax stores the last value of each binding so you can retrieve it with retrieveLast if for comparison with the new value. The typical use case for this functionality is an animated image gallery where animation direction is determined based on image index vs previous image index. I’m sure you can think of several others.
• Powerful reset function
  With the reset function, you can reset any or all of the bound properties to their default values (value of the property when the binding was defined). A quick call to reset followed by propagateAll will effectively reset you application.
• Propagation forcing
  There are times when checking if a value is in fact changed simply doesn’t make sense. Then you wanna be sure that a value spreads to you application each time it is set, even if hasn’t changed. BindMax lets you override change detection on a per-update or per-property basis.

So go get it! At Google Code

NOTE: From now on I will be talking mostly about BindMax instead of it’s little brother BindLite. I’m leaving BindLite in the source in case someone finds it useful, but BindMax is much more verastile by not being an all static access class.

I’ve also updated the BindMax tutorial

The updates I made were the following:

• Added reset all functionality when calling reset without arguments
• Added setForcedPropagation function
• Added propagateAll function
• Removed outdated example project

I needed to draw a dashed line in AS3. I thought it would be easy, but I thought “hey, that one’s already been covered”, expecting that if I could find some ready-made class or lib that would do the job, I might even get some extra benefits. I went on this great interweb page called Google and I searched for “Dashed Line AS3″.

I was disappointed at all the feeble attempts at doing something so simple, so after a couple of attempts i did it myself. I even threw in the added benefit of making it able to draw itself between two points you supply it. I was expecting something extra so I imagine you did too.

Here ya’ go:

DashedLine.as

PS: Damn, that drop shadow Mac OS X includes in window screenshots is really something.

That’s actually a good question. But it seems there’s no way to force a property to be passed by reference in AS3. The behaviour of most properties are to be passed by value, which means that if you write this:

var myValue:String = _myObject.value;

Then the value of _myObject.value is copied into the value of myValue and not further connection between the two is maintained. There are exceptions to this rule, Arrays being one of them. But in general this is how it works.

But sometimes you want myValue to continuously reflect the value of _myObject.value. Or maybe if you wanted another object to have access to the original object’s value, you would have to pass boh a reference to the object and the property name as a string. You would have to get a little dirty and use the AS3 equivalent of the old eval() function in AS2. In AS3, we do this with a string representation of the property name enclosed in square brackets, like so:

var myValue:String = _myObject["value"];

As we know, eval is evil because it’s slower and more error prone than accessing the property directly. Hence we need an elegant workaround that at the very least looks like we’ve made an attempt to formalize the situation. So I created a small example class.

package
{
	public class PropertyReference
	{
		private var _object:Object;
		private var _property:String;

		public function PropertyReference(object:Object, property:String):void
		{
			_object = object;
			_property = property;
		}

		public function get value():*
		{
			return _object[_property];
		}

		public function set value(val:*):void
		{
			_object[_property] = val;
		}
	}
}

As you see, all it does is store a reference to the object instance containing the property and the name of the property. It also contains getters and setters for hiding the grunt work of accessing and motifying the property. It does not help the speed issue, but it makes it less error prone. You would instantiate it like this:

var propertyRef:PropertyReference = new PropertyReference(_myObject, "value");

That means you only specify the string equivalent of the property name once, which makes it less error prone.

New in version 1.2.2

If you didn’t catch the 1.2 update, you will not have discovered the new shorthand function which makes logging/tracing even simpler. Instead of trace, write otrace (works with the same arguments as the Olog.trace() method). Also check out the original blog post about version 1.2 for more about this goodie release.

Olog.traceDisplayList()

Version 1.2.2 introduces a safe and fast display list crawler, accessed via the function Olog.traceDisplayList(root, maxDepth, property). This is extremely handy if you need to debug UI issues. It will present a tree representation of the display list from the specified root object. Like so:

You can simply call it without arguments. In which case it will use Olog’s own stage as the root object and a maximum traverse depth of 10 levels down. Supply the root argument with another DisplayObjectContainer, to start from there instead. Altering the maxDepth argument lets you control the tradeoff between level of instrospection and speed. Of course, on a huge display list, a maxDepth of 200 might result in a script timeout/crash, but I trust you to decide what’s safe.

In addition, you can specify the string name of a property to include for each child. If the child has this property, it will be appended with its value after the class name in the resulting tree. For instance, specify “alpha” and you will see the value of the alpha property on all children like so: MyView.alpha = 1.

Automatic handling of uncaught exeptions

Flash player 10.1 (SDK 4.1) introduced a way to handle uncaught exeptions globally in a movie. Olog compiles safely with SDK 3.5 (the SWC is compiled with 3.5), but takes advantage of this feature if it is accessible.

Olog.addKeyBinding()

This neat little trick lets you bind a sequence of characters to the call of a function. Watch:

Olog.addKeyBinding( "list" , _traceDisplayList );
private function _traceDisplayList ():void
{
	Olog.traceDisplayList( this );
}

If you then, while the movie is running type the word “list”, Olog will call the function _traceDisplayList.

These two additions I’ve wanted to add for a long time and I finally got around to it. Having these tools at my disposal has made many a debug session considerably shorter.

Enjoy!

As some of you might know, I’m in layoff from my job as a flash developer at Allegro Interaktiv. I’ve been thinking hard and well about what I want to spend this period of four months doing. I will be freelancing a little if I can (in agreement with my employer of course), spend time with my family, and also catch up on a few forsaken hobbies.

But this sudden abundance of free time obviously creates a pefect climate for getting up to speed on new Flash libraries and dig deeper into the ones I already know. Like the AS3 core classes. That’s why I’ve given my self a perhaps rediculous challenge; to read the complete ActionScript Language Reference back to back over the next four months. This is clearly perversely nerd-like and all that, but here’s why.

The case for reading it all

Actually I’ve been thinking about it for a few years. You see every time I look up a class or a method in the dictionary, I usually read one or two paragraphs more than I need. Often I learn something new that’s been sitting just below the surface of what I already know. At times the AS3 language reference is not even that badly written and the examples are usually useful. So instead of googling for tutorials about particle engines, Papervision and what not, I decided that before trying to gain something completely new I’d be better off getting to know the old annoying aunt intimately. Well not in that sense… sorry, you know what I mean.

You should too!

I’m not saying you really should join me in this preposterous endeavour, but I am serious in that many tend to overlook what a great resource the AS3 Language Reference really is. So the essence is really that you can learn a lot from what you already have at a single keyboard command (shift-F1 in Flash that is). Look up some random class name that you’ve never used an find out what it’s for. You might be glad you did.

In the mean time, you can follow my progress here at the blog, and if you follow me on Twitter.

Although a bit late for this season, I thought I’d share a small christmasy ActionScript nugget with you. This stuff was developed some time ago, so it’ll happily compile to Flash Player 6 if needs be. The script simply replicates a small, white particle that resembles a snow flake and animates it so that it falls from the sky. It also imitates 3D by altering the size and speed of the flakes and you can put any graphic you want inside the snowFlake movie clip to make it behave like a particle of snow.

I’ve actually had much use for it for various clients and projects. Go ahead and download it here:

Snow Flake FLA

Merry Christmas!