Fx4 IX. Ciclo de vida de un componente spark

Al desarrollar aplicaciones, y en nuestro caso, con tecnología Flex/AS3, debemos conocer el ciclo de vida de los componentes del framework para así entender la interacción y como sacarles el máximo provecho. Conocer bien el ciclo de vida de los componentes nos servirá para evitar errores al trabajar con ellos.

En este artículo veremos como funciona el ciclo de vida en los spark components. Estos componentes siguen un ciclo de vida parecido a los Halo components, pero con algunas diferencias. Antes de ver estas diferencias, creo necesario hacer un repaso al ciclo de vida de los Halo components.

¿Porqué necesitamos que los componentes tengan un ciclo de vida?

El Flash player funciona con una secuencia de frames. Cada frame tiene la siguiente forma:

En nuestra aplicación hay mucho código que no necesita renderización, como cálculos, iteraciones por colecciones, etc.
En cambio hay código que requiere la actualización del componente, pongamos un ejemplo:
Si cambiamos el width de un container, queremos que este se actualize y de paso que actualize el tamaño de sus hijos. El ciclo de vida hará que estos cambios se apliquen, debido al flujo de etapas que él mismo define.

El ciclo de vida de los Halo components

Los Halo components tienen un ciclo de vida compuesto de tres etapas:

Etapa de creación

Consta de cuatro fases que se ejecutan en el orden en que se explican a continuación:

• Fase de construcción: Fase en la que creamos el objeto llamando a su constructor.
• Fase de configuración: Durante esta etapa, los valores asignados a las propiedades del componente, se guardan internamente para referenciarlos posteriormente.
• Fase de inclusión (attachment): Se activa cuando el componente es añadido a la display list mediante addChild() o addChildAt() o mxml. Define el componente padre, ya que estamos añadiendo un componente a la display list.
• Fase de inialización:Lanza preinitialize event. Luego ejecuta createChildren() para crear sus hijos y finalmente lanza initialize event.

Etapa de la vida del componente

A partir de los cambios que recibe el componente, éste pasa por diferentes fases:

Proceso de invalidación

Los cambios hechos en las propiedades, estilos y subcomponentes son marcados para que sean actualizados.
Hay tres métodos para la invalidación:

• invalidatePorperties(): marca las propiedades del componente que han cambiado.
• invalidatesSize(): marca los componentes que necesitan ser redimensionados de acuerdo con un valor cambiado.
• invalidateDisplayList(): marca el componente cuando éste recibe algún cambio visual.

Proceso de validación

Es la respuesta al proceso de invalidation. Renderiza los cambios marcados en la etapa de invalidation.

Métodos para la validación:

• commitProperties(): para actualizar los cambios en las propiedades. Es la respuesta al método invalidateProperties(). La primera instrucción debe ser super.commitProperties().
• measure(): para actualizar las dimensiones del componente. La primera instrucción debe ser super.measure().
• updateDisplayList(): es el punto final en el proceso de validación. Se ejecuta como resultado a la petición de invalidateDisplayList(). Hace el layout del contenido del componente y realiza cualquier actualización en la renderización.

La validación ejecutará la etapa de actualización del componente de manera que los cambios que se han producido, sean renderizados.

La relación entre los métodos de cada una de las etapas es la siguiente:

Etapa de destrucción del componente

Ocurre cuando el componente se elimina de la displaylist. Luego se llama al garbage collector para eliminar los elementos no referenciados.

¿Qué ha cambiado en Flex 4?

La verdad es que, en cuanto a ciclo de vida, no ha cambiado mucho. Spark se ha construido encima de Halo.

La mayor diferencia es que Spark separa la skin del propio componente, pero existe un contrato entre ambos, un contrato que obliga al componente a definir los datos, partes y estados que tendrá su skin. como muestra tenemos a SkinnableComponent, que extiende de UIComponent, por lo tanto tiene el mismo ciclo de vida, pero tiene una skin que sigue su propio ciclo de vida.

Ciclo de vida de la skin

Una skin puede tener partes estáticas y partes dinámicas. Cuando se ejecuta el createChildren() de un SkinnableComponent, este invoca a validateSkinState(), que a la vez invoca a attachSkin(). La función attachSkin() crea la skin con las partes declaradas y la añade como un hijo del componente.

Cuando muere el componente, se van quitando las partes de la skin y finalmente se destruye la skin. Así se da fin al ciclo de vida de la skin.

Conclusión

Se ha dado un paso a vista de pájaro de lo que es el ciclo de vida en los spark components. Respecto al ciclo de vida de un SkinnableComponent, para entenderlo con claridad es mejor ver y codificar ejemplos. A continuación os dejo unos links que espero que os sirvan.

http://www.developmentarc.com/site/wp-content/uploads/pdfs/understanding_the_flex_3_lifecycle_v1.0.pdf
http://www.flex888.com/1219/flex-4-components-life-cycle.html
http://www.artima.com/articles/flex_spark.html
http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Skinning
http://www.adobe.com/devnet/flex/articles/flex4_skinning.html
http://miti.pricope.com/2009/08/16/skinning-a-list-in-flex-4-magnifier-effect/