Fx4 IV: Spark containers

En este nuevo artículo veremos los nuevos containers de Fx4, los spark containers. Aunque Fx4 también proporciona los Halo containers, Adobe recomienda que usemos Spark containers siempre que sea posible, debido a que la arquitectura ha sido mejorada y optimizada. Como ejemplos de esta optimización tenemos que para mejorar el rendimiento de las aplicaciones, algunos Spark containers no permiten skinning y otro ejemplo sería que los Spark containers permiten el intercambio de layouts.

Tipos de Spark containers

Tenemos los siguientes tipos:

• Group and DataGroup
• SkinnableContainer, SkinnableDataContainer, Panel y Application (application no se explicará, ya que no varía mucho de Halo)

Diferencias básicas entre containers

Cada uno de los containers tiene un propósito concreto, a continuación lo comentamos:

En la imagen que sigue podemos ver las características de los diferentes containers:

Veamos dos ejemplos de utilización de spark containers:

En el ejemplo vemos el uso de un SkinnableContainer. El resultado sería el siguiente:

En el siguiente ejemplo se usa SkinnableDataContainer, recordemos que está optimizado para contener, sobre todo, data items:

SkinnableDataContainer y DataGroup necesitan un itemRenderer, si no necesitamos uno en especial, podemos especificar el que se ve en el ejemplo. Si no especificamos itemRenderer, no aparecerá nada en pantalla. El resultado del código anterior es:

Layouts

No profundizaremos en el tema de layouts porque dedicaremos una sección exclusiva para ello; sólo lo veremos muy por encima.
Todos los Spark containers tienen definido un layout por defecto, pero podemos especificar el que queramos. Los diferentes layouts que nos ofrece Fx4 son: BasicLayout (posicionamiento absoluto), HorizontalLayout ( posicionamiento horizontal), VerticalLayout (posicionamiento vertical) y TileLayout (posicionamiento en filas y columnas).

Visión detallada de los spark containers

Group y SkinnableContainer
son containers pensados para albergar componentes que implementen la interface IVisualElement. La diferencia mayor entre estos dos containers es que SkinnableContainer puede ser skineado; Group no, ya que está pensado para una mínima carga de memoria.
El layout básico del container Group es BasicLayout. El layout por defecto de SkinnableContainer es VerticalLayout.

No entraremos en profundidad en el tema de styling y skinning porque tambien se dedicará un artículo, aunque a continuación se adjuntan dos ejemplos para ver un poco de skinning. Los dos ejemplos sirven para obtener el mismo resultado visual. Veamos primero con Group:

Para obtener el mismo resultado usando un SkinnableContainer y una skin, tenemos el siguiente código; la skin:

El container:

Tanto si aplicamos el primer ejemplo, como este último, el resultado es:

Panel
Incluye la barra de título, el título, un border y la content area para albergar a los hijos.Su layout por defecto es BasicLayout.

DataGroup y SkinnableDataContainer
Aunque DataGroup y SkinnableDataContainer pueden contener cualquier componente que implemente la interface IVisualElement y sea subclase de DisplayObject, están pensados para contener data items. Para representar estos data items debemos usar item renderers. Los item renderers convierten los datos a un formato visual. La mayor diferencia entre estos containers es que SkinnableDataContainer puede ser skineado.

No definen por defecto ningún item renderer para renderizar los items, por eso, si no lo especificamos, no se muestra nada. Fx4 proporciona dos item renderers por defecto:

• DefaultItemRenderer, que convierte los datos a un simple String.
• DefaultComplexItemRenderer, que muestra cada uno de los datos en un container de tipo Group. Es adecuado cuando entre los hijos hay algún elemento visual.

A partir de cualquier item renderer podemos acceder al host component mediante la propiedad owner.

Custom item renderers

Para codificar un item renderer, debemos definir un nuevo componente mxml, con ItemRenderer como tag root.

Paso de datos al item renderer
La clase base de todo item renderer es ItemRenderer y define tres propiedades que el owner usa para pasarle la información:

• labelText: Cuando los datos recibidos son de tipo String.
• data: Cuando los datos tienen una representación más compleja.
• owner: Es el componente que hospeda el item renderer. El owner de un item renderer debe implementar la interface IItemRendererOwner, que define las siguientes funciones para el item renderer: itemToLabel(), para convertir el data item en una representación en forma de String; y updateRenderer(), que codifica el data item como un String para la propiedad labelText del item renderer; luego actualiza la referencia de la propiedad owner del item renderer.

Debemos tener en cuenta que los item renderers deben definir los siguientes estados:

• normal: cuando no se está interactuando con él.
• hovered: cuando el mouse está encima.
• selected: cuando está seleccionado.

Podemos definir estados adicionales según lo que necesitemos. A continuación se muestra un ejemplo de item renderer:

El item renderer:

El resultado sería algo así:

Igual que en Halo, podemos definir una function como item renderer, mediante la propiedad itemRendererFunction.

También se mantiene la posibilidad de declarar inline item renderers, definiéndolo dentro de fx:Component. La única restricción es que no podemos dejar el tag fx:Component vacío. Cuando trabajamos con fx:Component, podemos acceder al ámbito exterior del item renderer mediante la keyword outerDocument. Los inline item renderers también pueden usarse en cualquier lugar de la aplicación, debemos especificar un id para el tag fx:Component, así podemos hacer referencia a él.

Precedencia de los Spark item renderers

Tanto DataGroup como SkinnableDataContainer siguen reglas para determinar el item renderer que aplicarán:

1. Si la propiedad itemRendererFunction está definida, se usa para obtener el renderer. Si ésta devuelve null, aplica la regla 2
2. Si el itemRenderer está definido, se usa para renderizar los datos
3. Si el item implementa mx.core.IVisualElement y es de tipo flash.display.DisplayObject, se usa directamente
4. Si no se ha encontrado ningún item renderer se lanza un error en tiempo de ejecución

Uso de la virtualization

DataGroup y SkinnableDataContainer pueden representar infinidad de items. Cada item require una instancia de item renderer. Es fácil pensar la degradación de rendimiento que nuestra apliación puede sufrir en función del número de items a representar.

En lugar de crear un item renderer para cada item a representar, podemos decirle al contenedor que tenga un layout virtual: de esta forma el container reusa los item renderers y solo crea los que necesita para la parte visible. Para configurar el container para que use use virtual layout, settearemos la propiedad useVirtualLayout a true. Sólo DataGroup y SkinnableDataContainer con VerticalLayout, HorizontalLayout y TileLayout soportan virtual layout. Con layout virtual se disminuye la carga de memoria y renderizado.

Hay diferencias en el comportamiento de los layouts cuando se activa el virtual layout o no:

• Con virtual layout true no hay soporte para percentHeight = 100% en un VerticalLayout y tampoco para percentWidth = 100% para un HorizontalLayout.
• Un container que use virtual layout y contenga pocos items a representar, cuyas dimensiones varien bastante, puede responder de manera pobre a la interacción del scrolling. Usar virtual layout con pocos elementos es evitable ya que es mayor el cálculo y la creación o measure.

Debido a que con virtual layout un container reusa los item renderers, tenemos que estar seguros que definimos todos sus estados.

Uso del typical item

Cuando usamos virtual layout en un DataGroup o un SkinnableDataContainer, podemos pasar al contendor un data item que define el data item típico. El container usará este data item típico y lo asocia al item renderer para determinar las dimensiones por defecto de los hijos. Esto se hace con la propiedad typicalItem del contenedor, y debemos especificar el data item como en este ejemplo:

En el ejemplo, con la definición de typicalObj representamos la propiedad typicalItem del container. El container usará este data item y asociado con el item renderer, determinará las dimensiones de su children.

Con este artículo hemos dado un repaso a los containers spark, entrando en profundidad en aquellos aspectos que he creido más importantes. Espero que os sea de ayuda para entender más esta nueva arquitectura de los containers.