Fx4 V: Sintaxis de estados

En esta cuarta versión de Flex se han producido cambios considerables en la arquitectura de componentes así como en el lenguaje MXML. Esto se ha hecho para potenciar varios aspectos como son la productividad, facilitar el workflow designer / developer o la integración con herramientas externas.
En esta entrada se verá en profundidad el funcionamiento y nueva sintaxis de los estados ( State ) en Flex 4.


Revisando los estados

Los estados han existido en Flex desde la versión 2. La palabra que define la funcionalidad y de hecho la clase que se ocupa de implementar la misma describe muy bien lo que implica la creación de estados.
Un estado es la declaración de una configuración específica de un conjunto de elementos y/o sus atributos en el marco de un un UIComponent.
A través de los estados podemos modificar el valor de una propiedad o estilo, modificar un event handler o añadir o quitar del display list componentes.
A nivel implementacional los estados se definen como elementos dentro de un Array en la propiedad states y se define el estado en el que estamos en todo momento a través de la propiedad currentState, ambas propiedades pertenecientes a la clase UIComponent.

Fisonomía de un estado en MXML

Como hemos dicho un estado declara la configuración específica de un conjunto de elementos de un UIComponent pero, ¿cómo se declara exactamente? A continuación veremos las diferentes opciones de las que disponemos para declarar los estados. Siempre hablamos de declarar estados en MXML.

Declaración del estado

Lo primero que necesitamos para declarar estados es un contenedor que pueda albergar uno o más de ellos. Este contenedor es la propiedad states.
[mxml]




[/mxml]
Este bloque de código MXML declara dos estados login y registro para que los podamos utilizar en el resto del documento que estamos editando.
Como se puede ver los estados son instancias de la clase mx.states.State igual que en la versión 3 del SDK, esto es debido a que internamente el motor de estados es el mismo (desconozco hasta qué nivel es así internamente pero aparentemente el mecanismo es el mismo exactamente), lo que ha cambiado en realidad es la forma de declararlos en MXML y por lo tanto ha sido un trabajo extenso a nivel de compilador. De hecho si añadimos el flag de compilación -keep-generated-actionscript podremos apreciar que el código generado utiliza las mismas clases para generar los estilos de forma programática mx.states.SetProperty, mx.states.AddItems, etc…. En breve podréis experimentarlo vosotros mismos con el ejemplo al completo.

Asignación de propiedades, estilos y event handlers

Tener los estados declarados es una parte indispensable del proceso, pero el trabajo real para definirlos está en las asignaciones.
Para asignar el valor de una propiedad en el contexto de un estado se utiliza una sintaxis por notación de punto.
Siguiendo con el ejemplo anterior:
[mxml]


[/mxml]
En este bloque de código se puede apreciar el añadido sintáctico con respecto a la versión 3 del SDK. La propiedad title del componente Panel está por duplicado y cada una lleva un sufijo que se corresponde con el nombre del estado en el que esa propiedad debe ser asignada. En definitiva queda como:
<s:Panel propiedad.nombreEstado1='valor1' propiedad.nombreEstado2='valor2'>
Lo cual es mucho más intuitivo y menos verboso que la mecánica de la versión anterior de Flex.
Cabe decir que en el ejemplo anterior se puede obviar una parte del código, que son las referencias al estado base, es decir, al que está el primero en la lista de estados (login en nuestro ejemplo) tal y como se muestra a continuación:
[mxml]


[/mxml]
Lo que acabamos de aprender con las propiedaes es igualmente aplicable para atributos de estilo y event handlers.
Un ejemplo completo donde se ve un ejemplo de cada:
[mxml]


























[/mxml]
En este ejemplo se puede ver como asignamos propiedades, estilos y event handlers en función del estado en el que estamos.

Añadir y quitar componentes

Para añadir o quitar componentes de un estado determinado se utilizan dos propiedades especiales del espacio de nombres fx: includeIn, excludeFrom.
En el ejemplo anterior tenemos un caso de uso para includeIn. Esta propiedad requiere de un nombre o listado de nombres de estado separados por coma que serán en los cuales estará presente el componente en el que se declara la propiedad.
En nuestro código lo utilizamos para decir que queremos que el contenedor en el que está el campo de texto de “repetir contraseña” solo aparezca en el caso de entrar en el estado “registro”.
excludeFrom es lo mismo pero a la inversa, es decir, sirve para decir en qué estados un componente no debe estar presente.
Podríamos declarar el estado en el contenedor de “repetir contraseña” obteniendo el mismo resultado pero utilizando excludeFrom de la siguiente forma:
[mxml]

[/mxml]
Se entiende pues que ambas propiedades son mútuamenet excluyentes.

Reparentado de componentes

Otra opción asociada es la de reparentado de componentes según estado. Esta funcionalidad se consigue utilizando un tag especial del espacio de nombres fx:
<fx:Reparent/> target='[id componente a reparentar]' includeIn='[nombre estado en el que el reparentado tendrá efecto]'.
El tag Reparent es un marcador del lugar dónde el componente target deberá ir durante el estado includeIn. Esto en código se traduce así:
[mxml]










[/mxml]
En el ejemplo se puede ver cómo el botón cambia de panel según el estado en el que está. El tag Reparent actúa de marcador para el lugar en el que irá el botón cuando el estado “botonEnPanel2” entre. Notar que se puede utilizar igualmente excludeFrom.

Políticas de creación de estados

Una aplicación Flex puede llegar a ser (y suele ser) realmente grande. Esto implica que si no tratamos con mucho cuidado las políticas de instanciación de vistas, componentes y estados podemos acabar con una aplicación que no responde bien porque consume demasiada memoria y recursos, haciendo que la experiencia de usuario sea negativa.
Uno de los puntos de control de los que disponemos en relación a este aspecto es la propiedad itemCreationPolicy.
La propiedad itemCreationPolicy es una propiedad especial del espacio de nombres fx que permite especificar cuando queremos que un elemento concreto sea instanciado en el marco del manejo de estados. Puede tener uno de estos dos valores:

  • deferred (por defecto)
  • immediate

En el caso de deferred, el valor por defecto, lo que conseguiremos es que un componente declarado en un estado determinado se instancie solo en el momento de entrar en ese estado. Conseguiremos que la aplicación responda mucho más rápido y consuma menos memoria inicialmente pero, dependiendo de lo costoso que sea (a nivel de proceso) crear los estados puede que al entrar en los más complejos se note una penalización en el rendimiento. Aparte de esto las instancias del estado no serán accesibles antes de entrar en el estado por primera vez.

En el caso de immediate lo que conseguimos es que los componentes, aunque no estén en el display list, se instancien al iniciar la aplicación y por lo tanto estén en memoria. Con esto consumiremos más memoria desde el inicio de la aplicación y también se notará una penalización en el rendimiento de la misma durante el periodo de iniciación. Ganaremos en rendimiento al acceder a los estados porque ya estarán creados y podremos acceder a las instancias antes de haber entrado por primera vez a su estado correspondiente.

Como se puede ver hay mucho que decidir y es muy importante tener en cuenta este aspecto en el desarrollo de vistas basadas en estados.
Como norma general se recomienda utilizar immediate solo cuando esté muy justificado, por ejemplo si necesitamos acceder a una instancia antes de crear el estado en el que está.

Políticas de destrucción de estados

Ya que podemos definir la política de creación ¿porque no definir la de destrucción? En Flex 4 podemos mediante la propiedad itemDestructionPolicy, del espacio de nombres fx de de MXML2009.
Esta propiedad nos permite definir si el objeto que se ha creado para un estado determinado sigue existiendo en memoria al salir del estado.
Los valores que puede tomar son:

  • auto (por defecto)
  • never

En el caso de auto, el valor por defecto, estamos diciendo que el componente sea eliminado de memoria al salir del estado.
En el caso de never estaremos diciendo que el componente persista en memoria incluso al salir del estado en el que se ha instanciado.
Al igual que con itemCreationPolicy se debe tener muy en cuenta lo que se decide para que el balance rendimiento / memoria / experiencia de usuario sea equilibrado.

Conclusión

Los estados en Flex 4 son más intuitivos, menos verbosos y además disponemos de más opciones para controlar su ciclo de vida. A todos lo que no han utilizado estados en versiones anteriores por lo tediosos que podían llegar a ser os animo a que le déis una oportunidad en esta versión 4. Seguro que los encontraréis útiles!

6 Comentarios

  1. Carlos Aza

    Hola,

    Tengo una pregunta, igual es algo estúpida: ¿qué diferencia está en separar los componentes visibles mediante estados o mediante ViewStacks? Es posible que haya más cosas detrás que hagan útil usar estados en lugar de ViewStacks, pero no lo acabo de ver.

    Gracias y un saludo,

    Carlos Aza

  2. Joan Garnet

    Aunque de algún modo podrías llegar a hacer lo mismo con ViewStacks que con estados sería matar moscas a cañonazos.
    Se puede pintar la Mona Lisa con tablas HTML (lo he visto) pero es más óptimo y adecuado hacerlo con un lienzo y un pincel 😉
    Solo te puedo decir que si experimentas un poco con los estados lo entenderás.

    Saludos!

  3. Carlos Aza

    Buenas,

    Ok, con vuestras explicaciones y leyendo un poquillo más de la documentación, me empieza a quedar más claro y le veo las posibles utilidades.

    Saludos!

  4. Josue

    disculpas por mi ignorancia y falta de xp en flex, pero, estoy desarrollando un website, y utilizo ViewStack para cada opcion de mi menu principal y States para navegar dentro de cada opción… asi sería mejor? o como puedo organizar mis contenedores?

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