What does [Bindable] mean in ActionScript?

You can either read my answer here or over on Stack Overflow.

[Bindable] is a one of several meta tags that you can use in flex ActionScript code. It can be applied to properties, or methods that are marked in any scope. It cannot be used with static class members.

The key to useing the [Bindable] meta tag is understanding what is going on under the hood when you use it. Essentially using data binding is a type of short hand for adding event listeners and dispatching events.

There are two basic forms of the [Bindable] tag. The first is just [Bindable] followed by a var/property declaration. The Second is [Bindable(event="eventname")] followed by either a var/property declaration, a function/method declaration or one half of a getter/setter declaration.

I’ll explain the longer notation first since the other builds on the same concept but with even more short hand.

When you use [Bindable(event="eventname")] you are essentially telling the compiler that this var/property/function/method (call this the instance member) is ‘available’ to be used as the source for data binding. You are also telling it that when the value of the instance member has been invalidated/changed and it needs to be re-read that the “eventname” event will be dispatched.
In this longer form this all you are doing. You the developer are responsible for actually dispatching the “eventname” event whenever the value needs to be updated in the binding subscribers.

The real efficiency of using data binding comes on the subscribing side. The typical notation you will see in MXML is value=”{instance.propertyName}” When you use the notation { } you are telling the compiler to do the following:

1. Create an event listener that listens to the event named in the bindable meta tag
2. In that event listener re-read the instance.propertyName and update this value

If you use the shorter form [Bindable], and you add the tag before a property/var, the compiler fills in the blanks and adds some additional functionality to make the property bindable. Essentially you are telling the compiler “add the events and methods you need to make this property bindable”
Now the way to think of what the compiler will do under the hood is this.

1. make a private version of your var
2. create an “event” to trigger the binding
3. create a getter function with scope and name of your original var that returns the private verson of the var when called.
4. create a setter function with scope and name of your original var that sets the private version of the var when called AND dispatches the triggering event.

In essence the compiler will do much of the work for you.

[Bindable]
public var xyz

is equivalent to

private var _xyz:String;

[Bindable(event="updateXYZValue")]
public function get xyz():String{
return _xyz;
}

public function set xyz(newxyz:String):void{
_xyz = newxyz;
dispatchEvent(new Event("updateXYZValue"));
}

The only functional differences in these is that in the first instance;

1. you do not know the name of the event that will be dispatched to trigger the binding
2. there is no way to update the underlying value without triggering the data binding

This second example also demonstrates one special case of the [Bindable] meta tag. This is that when you are applying it to a getter/setter pair defined for the same variable name you need only apply it to one or the other, it will apply to both. Typically you should set it on the getter.

You can use either notation on a function/method however if you do not specify an event the binding will never be triggered so if you are trying to bind to a function you should alway specify an event. It is also possible to specify more than one triggering event by stacking the tag. eg.

[Bindable(event="metaDataChanged")]
[Bindable(event="metaObjectUpdated")]
public function readMyMetaData():MetaDataObject{
var myMetaDataObject:MetaDataObject;
.
.
.

return myMetaDataObject;
}

This would presume that somewhere else you your class you will dispatch this metaDataChanged event or the metaObjectUpdated event when you want trigger the binding.

Also note that with this notation you can tie the binding of any instance member to any event that the instance will dispatch. Even inherited events that you yourself do not generate such as FrameEnter, OnChange, etc…

Data bindings can also be setup and destroyed during runtime. If you are interested in this take a look at the mx.binding.utils classes.

http://stackoverflow.com/questions/3959546/what-does-bindable-mean-in-actionscript/5183839#5183839

Adobe makes available but does not include by default many framework localization resource bundles in the form of collections of property files. These files provide localization settings for the Flex framework components including; number and currency formats, month and day names, internal error messages etc…

To localize the framework components it is necessary to download these property files and recompile the framework resource bundle library (framework_rb.swc) for each locale. (see attachment) These libraries can then be compiled into our localization files.

Setting up basic standard localization for the Flex environment.

This post does not cover how to apply localization to your application when I have a chance I’ll post one on how to do that. Also, this information is made regarding the Flex SDK 3.4 but should apply with minor modifications to most other versions of the SDK. These steps should apply to the command line or any version of Flex/Flash Builder with minor variation.

For reference, I am using Flash Builder 4 installed in the default install directory, with the 3.4.0.9271 SDK loaded as an alternative SDK.
The process to setup basic Flex localization can be broken into the following steps.

1. Create the localization component libraries in the SDK
2. Localize the component librariesfor the SDK
3. Recompile the component libraries for the SDK

Before you can localize you must set up the localization component libraries in the SDK. By default only en_US is installed. To install the others follow the following steps.

1. Create the localization component libraries in the SDK.

To do this you must first copy the en_US stub to your new localization. There are several standard localization names most take the form of two letter language code + underscore + two letter country code. However there is no rule that you must follow this convention. Adobe includes a utility to make a copy of localizations. You must navigate to your SDK bin directory via the command line. Since I am using Flash Builder 4 with the additional SDK loaded in it, that means this directory for me is:

 C:\Program Files\Adobe\Adobe Flash Builder 4\sdks\3.4.0.9271\bin\

You then want to run the program copylocale (if you need to find your bin directory you can do a file search for copylocale.exe)

This is a very simple program it takes two arguments source and destination locales. You don’t worry about directories, it knows where to do it’s business. I will be creating a generic Spanish locale (es) and a Mexico specific locale (es_MX). So I will run the following two commands.

copylocale en_US es
copylocale en_US es_MX

These commands will do a number of things but basically they copy:

 C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\projects\framework\bundles\en_US\

To:

 C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\projects\framework\bundles\es\
 C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\projects\framework\bundles\es_MX\

And at the same time they compile the contents of those directories to several swc files located in:

 C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\locale\es\
 C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\locale\es_MX\

2. Localize the component libraries for the SDK

Now you need to modify the source files located in the first set of directories

 C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\projects\framework\bundles\es\
 C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\projects\framework\bundles\es_MX\

You can modify these by hand if you want to and happen to have the knowledge.  But there is an easier way.

Adobe has made available a set of basic localization files for over a dozen languages online.  (Why they just don’t just include these… I don’t understand) You can download the files at:

http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/framework/bundles/

For my purpose I will get the es_ES directory and copy all of the *.property files to the two directories above. I will make a further change to a few of the files I copy into the es_MX directory, but other than that, that is it.

Note: There is a “docs/” directory in the resource directories on the download site. I don’t think you need it unless you want to localize the context help for your installation of Flex/Flash Builder.

3. Recompile the component libraries for the SDK

You are not quite done yet. If you were to attempt to localize an application at this time you would find that everything is still using en_US.   (‘January’ ‘Monday’,$, etc..)  The reason is that when flex compiles your application,  it uses the SWC files located in these directories:

C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\locale\es\
C:\...\Adobe Flash Builder 4\sdks\3.4.0.9271\frameworks\locale\es_MX\

These were created in step 1, before you downloaded the localized files from Adobe. To recompile these files I use the following command, but first I must change my command console directory to the root of the sdk. In my case that is:

C:\Program Files\Adobe\Adobe Flash Builder 4\sdks\3.4.0.9271

(Note: the next commands are all on one line. I broke it out so you could read it easier.  I also boldfaced the command line options.)

Now I run the following command

bin\compc -locale=es
-source-path+=
frameworks/projects/framework/bundles/es/src/
-include-resource-bundles=
collections,containers,controls,core,effects,formatters,logging,SharedRe
sources,skins,states,styles
-output=frameworks/locale/es/framework_rb.swc


I run it again for Mexico variant


bin\compc -locale=es_MX
-source-path+=
frameworks/projects/framework/bundles/es_MX/src/
-include-resource-bundles=
collections,containers,controls,core,
effects,formatters,logging,SharedResources,skins,states,styles
-output=frameworks/locale/es_MX/framework_rb.swc

These last two commands compile the property files into the framework_rb.swc file.  This library is then in turn used by the compiler when you compile your application or can be dynamically loaded as a localization into your app.

Now you are set to localize your project swf or compile dynamic locale swf files with all of the base flex components being localized.    (‘Enero’ ‘de lunes’, peso, euro etc..)

No I am not going to criticize Jobs for these choices. I can see the business logic behind every one of them so that is not fair.  He is after all running a business.    I will however include what I think those reasons are in this little rant (and why they are bogus).  So here goes … the top 3 roadblocks to purchasing an iPad

1. Lack of Flash support:
   It really boggles the mind to think that a device designed specifically to be used as a device to browse online would intentionally leave this out.  For me this is the single biggest problem with the device.  If this were fixed I would probably buy one even with the other issues below.  Now I may be biased as I do Flash/Flex development work however it is not for my own work that I lament, but for the numerous services that would be simply inaccessible with this device.  As with non-inclusion of Flash on the iPhone in the first place this is just a bone-headed move on the part of Apple.  I appreciate that they want to support and encourage HTML5  and I think that is fantastic!    However, it denies the reality-on-the-ground that as of right now and the foreseeable future, Flash is an integral part of the web experience.  (I am NOT saying that is good or bad, just a fact.)  This problem is likely to be the biggest day to day disappointment  for those using the iPad.
   Business Reason: Apple wants to be at war with everyone!  It is no longer enough to take on Microsoft.  Apple wants to rumble with everyone Google, Nintendo, Amazon, Sony and now one of its oldest allies Adobe.  I get it, Steve wants to rule the world.  Closed systems mean you have to buy from Apple.  Closed systems mean developers have to develop versions specifically for Apple products.  If you want to develop for Apple products you have to develop ON Apple products, which means you must BUY the Apple products.  It also means you have less time to develop for other environments and products.  The more exclusive applications available on Apple products the more users will have to buy Apple products to use those applications.  Apple is betting that at some moment a “killer app” will come along that makes owning an iXxx absolutely necessary. Failing that it is betting that ubiquity will be the killer app.

1. Still no Multitasking:
   I understood this on the iPhone, the official justification for a single processor thread was basically ~ensure that the devices primary purpose ( being a phone ) is not compromised by applications that hog cpu usage and memory~ So for the iPhone this strategy made a little sense. However now I don’t see the argument for leaving this out of a device such as the iPad.  There is no phone.  That is not its purpose.   so…..???  What is the problem?
   Business Reason: Cost and speed… get it to market faster and capture market share.  This required less change in the way applications and the OS worked so it *might* (doubtful) be corrected in a future patch or release.
2. Still no camera
   I’ll be honest I really don’t care about this one personally.  However when Nintendo can cram 2 decent cameras into the DSi.  WTF?  How much is a CCD camera to include $1 – $2 ?  Really on a $500 device?   Ok ok, I get that keeping features to a minimum is a design philosophy at Apple but in this day and age when it is difficult to even find a cell phone without a camera it just doesn’t make much sense.  Couple that with the fact that support for a camera is already built into the iPhone OS  again WTF?   So I’ll end on you can add a camera to the little iPod but you can’t put one on the iPod touch or the iPad ??  Wow Apple’s engineers must be really incompetent or unfocused.
   Business Reason: Planned obsolescence, 2nd gen upgrade.   We’ve seen this before from Apple (and other companies)   It is very likely that the camera(s) will be the great addition to a version 2 of the iPad causing legions of those who have perfectly functioning iPads to upgrade to new units even when their old ones are perfectly serviceable.   My prediction is that this upgrade will come to both the iPad and iPod touch at or about the same time, probably next year.

It might not mean a lot to many people but for as long as I can remember I’ve had ideas and inventions floating around in my head. A couple years ago I decided to start patenting my ideas…

This was the first of what I hope will be many more to come. So far I am working on three other patents with over a dozen other ideas just waiting for the time and money to be able to file.

For those that are interested I originally filed this patent application back in mid 2005, It was published one year later. It took almost two full years before it worked its way through the queue to a patent examiner. It was returned to me for some minor corrections late last year and approved early this year. After paying the fee to have it issued about two months ago, it was finnally issued today. The whole process took about 3 1/2 years and cost about $8000.

Here is a pdf of the patent.

http://justinohms.files.wordpress.com/2008/06/uspatent007380665.pdf

The patent is available for license.

For my programming blog: http://blog.flexuous.com/

For my personal blog: http://blog.justinohms.com/

In one of my future posts I plan to include my methodology for moving my blog over including redirects for search engines so that I don’t loose my page rankings and any other links that are out there.