Skinning detallado con Flex 4

Uno de los ámbitos fuertes de Spark es el mecanismo de skinning de componentes. Nos ofrece un control total sobre el look and feel de nuestras aplicaciones. En este artículo veremos en profundidad como funciona este aspecto tan importante de Flex 4, acompañado de un proyecto de ejemplo.

Introducción

La nueva arquitectura de skinning que nos ha aportado Flex 4, proporciona una separación clara y precisa entre la lógica y los elementos visuales de un componente. De esta manera se consigue que los componentes en Flex 4 no contengan ninguna información sobre su representación gráfica. Esta información es contenida en el fichero que compone la skin. Mediante FXG y estados, podemos crear skins con mxml únicamente.
Uno de los conceptos más importantes son las skin parts, que nos describen todas las partes de un componente y definen el contrato que el componente establece con la skin. Las skin parts pueden ser dinámicas o estáticas. El tipo de skin part nos determina el tipo de instanciación que tendrá. Además, las skin parts pueden ser requeridas o no.

El proyecto de ejemplo

Es un componente que nos permite seleccionar el sexo y rango de edad de una persona:

Descarga

static y dynamic skin parts

Al crear un componente custom, lo primero que debemos hacer es mirar que partes lo constituirán. En este momento decidimos que partes serán opcionales, cuantas instancias tendremos de cada una de ellas y si se crearán en el inicio de la skin o durante el ciclo de vida de ésta.
Las partes estáticas se crean con la skin y son siempre accesibles. Sólo tendremos una instancia de cada una de estas partes.
Las partes dinámicas se instancian cuando se necesitan.

En el componente definimos las partes que lo comprenden, la lógica específica de la vista y listeners de eventos a los que responde, a parte del control del estado de esta vista y de sus elementos.
En cambio, en la skin determinamos de distribución del layout y los elementos gráficos que la compondrán.

Esta tabla resume las diferencias entre las static y dynamic skin parts (click para maximizar):

Un ejemplo es el siguiente, VSlider, tiene thumb y track como skin parts estáticas debido a que sólo tendremos una instancia y dataTip que es dinámica debido a que su creación será deferida.

Como se resume en la tabla, es adecuado usar una dynamic skin part cuando habrá múltiples instancias de ésta o cuando será instanciada a posteriori y no en el momento de creación de la skin. Son muy útiles cuando en tiempo de compilación no sabemos cuántas instancias vamos a necesitar: por ejemplo, puede ser que tengamos que ir modificando el número de instancias según el valor de una propiedad que modifica el usuario o cuando tenemos que mostrar resultados de una query a la base de datos y no sabemos cuántos resultados nos devolverá.

Trabajar con dynamic skin parts es distinto a hacerlo con static parts, debido sobre todo a que seremos nosotros los encargados de instanciarlas y no el framework.

Declaración de las skin parts en el componente

En nuestro componente de selección de sexo y edad, tenemos los botones de selección de tangos de edad que serán dinámicos. Con el metadata tag [SkinPart] definimos una skin part, tanto dinámica como estática. En el caso de las dinámicas, la variable, en lugar de ser fuertemente tipada, se declara de tipo IFactory, aunque en el parámetro type del tag definimos con el tipo que será instanciada:

Tenemos el parámetro required para especificar si esta skin part es requerida o no, en la mayoría de skin parts dinámicas, required tendrá como valor true.

Definición de las skin parts en la skin

El siguiente paso es la definición de las partes dentro de la skin. Para las static skin parts, directamente ponemos elementos gráficos y otros controles en la skin. Las dynamic skin parts se declaran dentro del tag de Declarations de la skin, debido a que no sabemos cuántas instancias necesitaremos:

Al definir una dynamic skin part debemos declarar el componente dentro del tag Component y este Component debe tener como id el mismo valor que le hemos dado a la skin part dentro de la Clase del componente.

Creación de una instancia de una dynamic skin part

Las dynamic skin parts son declaradas como IFactory. Es por eso que debemos usar el método createDynamicPartInstance() de la clase SkinnableComponent. Este método usa un mecanismo de caching. Aquí vemos un ejemplo de creación:

Vemos que una vez instanciada, la variable tiene que ser casteada para poder ser usada. Además debemos añadirla a la parte del layout que le corresponda, en este caso en el container dropDown.

Control sobre las parts

Tanto para las static como para las dynamic parts, Flex invoca automáticamente el método partAdded(), cada vez que se crea una parte. Es sobrescribiendo este método cuando añadiremos comportamiento específico a cada una de las partes, si es necesario:

Cuando una part se elimina, automáticamente se llama el método partRemoved(). En él deberemos quitar el comportamiento que le habíamos asignado, si es necesario, como, por ejemplo, eliminar event listeners:

Podemos eliminar intencionadamente una parte usando el método removeDynamicPartInstance() .
Para acceder a una dynamic part que hemos creado, tenemos dos maneras:

• Mediante createDynamicPartInstance(skinPart:String)
• Mediante getDynamicPartAt(partName:String, index:int)

Cambio de skin en tiempo de ejecución

Puede interesarnos cambiar la skin de un componente en runtime. Esto implica que debemos guardar el estado de las dynamic parts dentro del código, ya que Flex no se encarga de hacerlo. Es recomendable hacer esto que hemos comentado dentro de los métodos attachSkin() y detachSkin(), ya que estos métodos se llaman cuando la skin se carga y se descarga respectivamente.

¿Código en la skin o en el componente?

En general, la lógica que atañe a la vista, debería estar en la declaración de ésta, es decir, en el componente, pero esta regla no siempre es la más adecuada, depende de los escenarios:

• Si un código de un componente debe ser el mismo independientemente de la skin que se le aplique, vemos claramente que debe estar en el componente.
• Si un código atañe a una determinada representación, este debe estar en la skin.

Sobrescritura de métodos de SkinnableComponent

Todos los componentes visuales de la arquitectura extienden la clase SkinnableComponent. Por lo tanto, heredan sus métodos, propiedades, eventos y demás atributos de esta clase.
Puede ser que para crear una determinado componente custom, debamos sobrescribir métodos como commitProperties(), createChildren(), measure(), updateDisplayList(), attachSkin(), detachSkin(), partAdded(), partRemoved() o getCurrentSkinState().