Arquitectura de Adobe Flex 2 (II)

En la entrada anterior vimos la nueva jerarquía de clases soportada por el Flash Player 9 hasta llegar a la clase UIComponent, una de las piezas claves del framework. En esta entrada veremos en detalle por que es importante conocer esta clase para todo aquel desarrollador Flex interesado en extender el framework.


UIComponent

UIComponent es una de las partes más importantes del core de Flex 2. Esta clase sigue un patrón de tipo Template (o patrón plantilla). El cuál se basa en crear un esqueleto o implementación base sobre la cual poder extender la arquitectura minimizando la cantidad de código a escribir y ofreciendo un algoritmo de inicialización y comportamiento predefinido que asegura el comportamiento por igual de todos los componentes(subclases) que implementemos apartir de esta.

Ciclo de vida de un componente

Es decir la clase aporta una serie de métodos como createChildren, measure o updateDisplayList, que tienen una determinada función y que son llamados por el framework en un determinado momento de su ciclo de vida. Cada método es susceptible de ser sobreescrito en la subclase que implementemos para adaptar el comportamiento del componente a la funcionalidad específica que queremos implementar.

En la siguiente imagen podemos ver cuales son los métodos más básicos de UIComponent que serán llamados por el framework:

Ciclo de Vida de UIComponent

La inicialización del componente conlleva la ejecución del constructor y del método createChildren, el cual es responsable de crear todo los hijos del componente (por ejemplo, otros componentes, botónes, cajas de texto, etc…).

Antes de createChildren se lanza el evento preinitialize y justo después el initialize. Tenemos que tener en cuenta que en este punto todavía no existen todavía ninguno de los posibles hijos que se crearán en el método createChildren. Por último tiene lugar la fase de invalidación y el lanzamiento del evento creationComplete, que indica que el componente está listo para ser usado.

Invalidación y Optimización del Rendimiento

La fase de invalidación es un suceso importante en el ciclo de vida de un componente, ya que es crítico para obtener un rendimiento óptimo.

Básicamente, cada vez que algo cambia en el componente, éste NO actualiza su representación gráfica directamente. Es decir, imaginemos el caso en que en un mismo frame cambiasemos varias propiedades del componente visual. Si siempre llamasemos a los métodos que hacen el trabajo duro de actualizar el componente, el rendimiento se vería afectado seriamente. En la siguiente imagen se detalla lo que pasaría si Flex no implementase el mécanismo de invalidación:

Proceso de Invalidación (i)

Por el contrario el componente es marcado (o invalidado) de forma que se programa una actualización visual que tendrá lugar al comienzo del siguiente frame. Por tanto, la técnica escogida es invalidar cierta parte del componente, lo cual provacará su actualización, junto con el resto de componentes, en la siguiente fase de renderizado. De esta forma la coreografía de los componentes es óptima, al igual que el rendimiento general de la aplicación, ya que todos se actualizan a la vez.

Proceso de Invalidación (ii)

El proceso de invalidación en Flex 2 (al contrario de lo que pasaba en la v2 de Flash MX 2004 donde todo el peso recaía sobre el método invalidate()), se realiza mediante tres métodos: invalidateProperties(), invalidateSize() e invalidateDisplayList(). Estos métodos son los encargados de invalidar un aspecto concreto del componente: las propiedades, el tamaño o la representación gráfica del mismo. En la siguiente imagen podemos ver la relación directa con cada método.

Proceso de Invalidación (iii)

Por tanto, es importante no llamar nunca a los métodos commitProperties(), measure() o updateDisplayList() directamente, ya que esta es tarea del framework. De esta forma aseguramos un funcionamiento suave de nuestros componentes y una integración perfecta con nuestra aplicación.

En el siguiente parte veremos como extender UIComponent y cuales son los pricipales puntos de anclaje en la arquitectura a la hora de crear nuestros propios componentes.

4 Comentarios

  1. Felipe

    Yo tampoco tengo más q decir…salvo gracias por este esclarecedor y estupendo artículo.

    Un saludo, Carlos, y más de lo mismo al resto de colaboradores de mif.

  2. Pingback: MadeInFlex » Blog Archive » Arquitectura de Adobe Flex 2 (III)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase