sábado, 29 de agosto de 2009

Ocultar pestañas en TabNavigator

Hoy veremos como se pueden ocultar las pestañas en un TabNavigator de Flex 3. Es un problema que parece trivial (en otros entornos realmente lo es), pero en Flex dado el manejo interno que hace Flex del TabNavigator no es tan directo, o por lo menos la forma de añadir pestañas en un mxml puede llevar a un uso incorrecto.

Cuando tenemos un TabNavigator, para añadir una pestaña tan sólo debemos añadir como hijo un contenedor, es decir cualquier clase que herede de la clase mx.Container (Box, Container, viewStack, etc...). Veamos un ejemplo:
Una vez que tenemos el TabNavigator creado, podemos decidir ocultar ciertas pestañas en determinadas circunstancias, o bien usando estados (mx:States) o con código actionScript. Para tratar de ocultar una pestaña la tendencia natural es usar el atributo visible y el includeInLayout (para no dejar huecos entre las pestañas) sobre los hijos que hemos añadido en el TabNavigator, con lo que obtendremos un resultado erróneo, ya que se mostrará el TabNavigator con la pestaña vacía en su interior.

A grosso modo, cuando nosotros añadimos un hijo en el TabNavigator internamente crea una pestaña (tab), en la que incluye el botón con el que se representa la pestaña y añade el contenido que nosotros hemos especificado. Por tanto, si queremos hacer que la pestaña desaparezca completamente debemos acceder al tab y establecer las dos propiedades mencionadas antes: visible e includeInLayout a valor false. Para acceder al tab debemos hacer uso de la función getTabAt del TabNavigator, con la que obtendremos la pestaña (un objeto de tipo mx.Button). Usando el ejemplo anterior, el código para ocultar la "pestaña 2, " resultante sería algo así:

 ...
var pestana:Button =
tabNavigator.getTabAt(1);
pestana.visible = false;
pestana.includeInLayout= false;
...

Cómo vemos de esta forma simple podemos jugar con las pestañas para ocultarlas y visualizarlas, y no sólo eso, sino que podemos acceder a las pestañas (tabs), para cambiar cualquiera de sus propiedades.

lunes, 17 de agosto de 2009

Aplicaciones modulares en Flex

Hola, despues de un pequeño descanso ya hemos vuelto. Hoy quería hablar de un tema que tenía en el tintero desde hace un tiempo. las aplicaciones modulares en Flex.

La primera cuestión que nos viene a la cabeza es ¿Por qué una aplicación modular?, por que hemos de complicar el desarrollo para desarrollar modulos y tener que añadir cierta lógica extra para manejarlos. En efecto, el desarroollo modular supone cierto coste en tiempo de desarrollo y de ejecución de la aplicación, por tanto no todas las aplicaciones son susceptibles de desarrollarse de forma modular. En mi opinión es una cuestión de tamaño y/o complejidad, para desarrollar una pequeña aplicación muy simple quizás no sea recomendable, dado la carga extra que supone. La modularidad empieza a mostrar sus ventajas conforme el proyecto crece y se complica, pudiendo observar grandes beneficios:
  • Reducción del tiempo de compilación --> Dado que trabajamos con módulos, sólo recompilaremos los módulos en los que hay acambios.
  • Reducción del tamaño de los archivos compilados (SWF y SWC).
  • Reutilización --> Podemos reutilizar dicho módulo en otras aplicaciones.
  • Simplifica la adición de nuevas funcionalidades mediante la adición de nuevos módulos.
  • Carga/descarga de módulos dinámicamente--> Liberación de recursos.
  • Desarrollo entre distintos grupos de trabajo.
La realización de programas modulares en Flex podríamos englobarla básicamente en 4 categorías:
  • Uso de Módulos.
  • Uso de Librerías.
  • Uso de RSL (Runtime Shared Libraries).
  • Uso de librerías, RSL y módulos de forma conjunta.
Modulos
Los módulos son archivos SWF que pueden ser cargados dinamicamente y que no pueden ejecutarse independientemente, sino que deben ejecutarse dentro de una o varias aplicaciones. Un módulo puede interactuar con la aplicación padre o con otros módulos.

Podemos definir un módulo usando la clase Module.

Librerías
Como en cualquier otro lenguaje, una librería es un conjunto de funcionalidades y/o recursos que se encapsulan, en este caso se encapsulan en un fichero SWC.

RSL (Resource Shared Library)
Como su nombre indica es la una librería de recursos compartidos. La importancia de este tipo de librerías es que dicha librería se carga una sola vez en el arranque de la aplicación (se puede ver la barra de carga al principio), de forma que desde ese momento podemos utilizar todos los recursos de la librería sin necesidad de cargar la librería. Como es lógico este proceso puede ralentizar el proceso de startup de la aplicación, así hay que decidir con cuidado que librerías se cargarán como RSL (basándonos en la utilización de la librería).
Otro punto importante del uso de RSL, es que usando lo adecuadamente podemos reducir el tamaño de nuestros módulos/aplicaciones, ya que la librería se compilara en un fichero aparte que será reutilizado, y no se incluirá el código especifico que se usa de la librería en cada archivo compilado SWF.

Desde mi experiencia, recomiendo encarecidamente el uso de aplicaciones modulares para aplicaciones de cierta envergadura, ya de esta manera se puede disfrutar de un conjunto de ventajas muy interesantes a un coste relativamente pequeños, ya que sólo requiere el coste inicial de la gestión de módulos y una vez que se tenga implementada dicha gestión se pueden añadir funcionalidades facilmente.