Uso del metadata tag Bindable en getters y setters

Flex nos aporta el data binding, un potentísimo mecanismo para reaccionar a los cambios de ciertos tipos de datos. El data binding es una solución ideal para updatear las GUI según cambios en la capa de modelo de datos. Por esta y otras razones, se considera el data binding una característica muy importante del core de Flex.
En este post vamos a ver el uso de este mecanismo mediante el tag [Bindable] aplicado a los getters de propiedades.

Introducción

Al implementar getters y setters para acceder a una propiedad de un objeto y debemos permitir data binding, hay dos maneras de hacerlo, o lo que es lo mismo, hay gente que lo codifica así:

o gente que lo codifica así:

Un ejemplo de esta última aproximación es el ejemplo que tenemos en las APIs de Flex respecto a la interface IDataRenderer. El ejemplo que nos da la API es el siguiente:

Pero, ¿realmente conocemos la dieferencia entre estas dos formas de implementación? Supongo que muchos sí, pero no está de más que lo expliquemos para los que no.

Explicación

Cuando una propiedad es la fuente de un data binding, Flex copia automáticamente el valor de esta propiedad a la destination asignada cuando esta propiedad fuente cambia. Para avisar a Flex que debe hacer esta copia, todos sabemos que debemos usar el metadata tag [Bindable]. Como hemos dicho, este tag tiene dos sintaxis posibles:

[Bindable]
[Bindable(event="eventname")]

¿Què pasa si omitimos el nombre del evento? pues Flex immediatamente lanza un evento llamado propertyChange y de tipo PropertyChangeEvent.

Hemos hablado de propiedades, pero aplicándolo a getters y setters, si definimos un setter, estamos creando una propiedad de sólo escritura, la cual no se puede usar como fuente de una expresión de data binding. En cambio, al definir el getter, creamos una propiedad de sólo lectura, la cual podemos usar como fuente en una expresión de data binding mediante el tag [Bindable].

Entonces si creamos un getter con el tag [Bindable] sin evento, el compilador de Flex generará un evento llamado propertyChange y de tipo PropertyChangeEvent para esta propiedad. Si el valor de esta propiedad no cambia, Flex no lanza el evento para updatear la propiedad.

Por otra parte si codificamos un getter con evento, por ejemplo [Bindable(event="nameChanged")], nosotros seremos los responsables de lanzar este evento, normalmente en el setter de la propiedad y Flex no mirará si el valor de la propiedad ha cambiado.

Hemos dicho que si no se pone el nombre del evento en el tag Bindable, Flex crea un evento de tipo PropertyChangeEvent, la pregunta es, ¿Por qué este evento y no otro?

Pues la respuesta es porque la clase PropertyChangeEvent representa el cambio en una propiedad de un objeto y proporciona información sobre este cambio. Este evento es usado por las clases de tipo collection y es la única forma de notificar a las colecciones de que los datos que contienen han cambiado.

Si analizamos esto, estamos diciendo que si en un objeto declaramos para una propiedad un getter con un tag Bindable con el nombre de un evento, cuando esta propiedad cambie, Flex no lanzará un PropertyChangeEvent. Si este objeto está contenido en una collection, ésta no se enterará.

A continuación muestro unas imágenes de este proyecto, en el cual podemos experimentar esto que acabamos de explicar. Hay dos objetos diferentes que tienen una propiedad llamada name y a la cual accedemos por getters y setters. En una de estas clases, el getter tiene el tag Bindable y la otra el tag Bindable con el nombre del evento nameChanged. Estos dos objetos están contenidos en un ArrayCollection. La aplicación nos permite cambiar el nombre de cualquiera de estos dos elementos. Como vemos en la imagen que sigue, cuando cambiamos el nombre al elemento que tiene el getter sin ningún evento asociado, el ArrayCollection se da cuenta de que éste ha cambiado:

En cambio, cuando cambiamos el nombre al objeto que tiene el getter con un evento asociado, el ArrayCollection no reconoce cambios:

Conclusión

es importante tener en cuenta estos dos tipos de data bindings que hemos visto en el artículo debido a la repercusión que puede tener en la aplicación. En el caso de que los objetos estén en collecciones: puede ser que tengamos que esperar cambios de los objetos y que la colección no lo notifique. Entonces revisemos como hemos tratado los Bindings.