Why does adding Bindable to a Getter and Setter Method cause a compiler warning?
I've exchanged a few emails with Louise. He saw my 360Flex video on creating Flex Components and had a few questions about how things work. He was creating a component with a selectedValue property. He asked me this:
Why is [Bindable] only needed one time? If I add it before the set function, I get a warning that this is a duplicate. Is it because both functions reference the same property?
Louise answered his own question correctly. The combination of get and set methods create a property on the component. And that property only needs to be declared as Bindable once.
To demonstrate the error, here is a simple code block to cause the warning:
[Bindable]
public function get selectedValue():String{
return _selectedValue;
}
[Bindable]
public function set selectedValue(newValue:String):void{
this._selectedValue = newValue;
}
Just removing the second Bindable will clear that warning right up:
[Bindable]
public function get selectedValue():String{
return _selectedValue;
}
public function set selectedValue(newValue:String):void{
this._selectedValue = newValue;
}
The Bindable Meatadata only needs to be specified once. It is worth noting that you can also specify Bindable on the class; instead of individual properties. If you do that, every "Bindable" in the class definition will generate similar warnings.
I understand that Binding can be a process intensive operation. Does anyone know how making variables Bindable affects performance? I would expect that the performance issues only come into play when the binding actions take place; not by setting variables to binding. But, is that assumption wrong?
As always, I love answering questions; so ask away.
From a performance point of view this would be more efficient too:
public function get selectedValue():String{
return _selectedValue;
}
[Bindable(event="selectedValueChanged")]
public function set selectedValue(newValue:String):void{
if (newValue != this._selectedValue)
{
this._selectedValue = newValue;
dispatchEvent(new Event("selectedValueChanged"));
}
}
From a technical stand point I don't think it matters. I find it hard to believe that metadata placement would cause any performance differences. If there was a performance case, I'm sure the Flex Framework code would implement it in the way you suggest.
From an "easy to read code" point of view; the metadata is easiest put before the get/set methods. The get / set methods are just two pieces of code to a "chunk" that make a single property
I agree with you, and I wasn't implying that the placement of the metadata would have any affect on performance. I thought from a logical point of view that the metadata ought to be placed above the setter. But your point about the readability is a good one, so it's a matter of taste I guess.
Performance wise it does matter whether you use a generic [Bindable] or a specific [Bindable(event="specificPropertyNameChanged")] though, because it enables bound objects to listen to that specific event instead of the generic propertyChanged event.
cheers,
Roland
I didn't think there was a generic propertyChanged event.
If you want a quick intro into the binding internals then I suggest you watch this little presentation by Michael Labriola:
http://www.slideshare.net/michael.labriola/diving-...
Cheers,
Roland
http://link.brightcove.com/services/player/bcpid17...
if you have an hour to spare, its well worth your time I believe.
Roland
http://livedocs.adobe.com/flex/3/html/metadata_3.h...
"If you omit the event name, Flex automatically creates an event named propertyChange."
I always took this to mean it creates an event named [nameoftheproperty]Change . Although I can see why that interpretation would be incorrect.
Michael's preso [and many others from 360Flex] have been on my list of things to watch. Someday I'll get to them.
Now, you should use [Bindable(name="someEvent")] above your getter to control when to dispatch a binding update. For instance, you might have some complex value that consists of concatenated string. Any time one of the strings changes you want everything bound to your single var to update.
[Bindable(name="myEvent")]
public function get myValue():String{ return field1.text + field2.text + field3.text;}
So, somewhere in a change function or whatever you could merely dispatchEvent(new Event("myEvent")); and it will update everything listening.
As noted above, binding is expensive so don't put it on the class unless you truly want every property to be bindable.
Hope that helps.
Do you know if Bindable variables cause performance issues; or just the act of binding? I would expect a variable that has the bindable metatag, but is never bound, will not cause any performance issues.
Be especially careful with adding [Bindable] to value objects that can have to be created potentially hundreds or thousands of times. If you don't really need them to be directly bindable than omit the [Bindable] tag.
cheers,
Roland