Los últimos días han sido de especial movimiento en lo que respecta a Adobe por su cambio de dirección con respecto a Flash en los navegadores móviles, los despidos masivos y finalmente el futuro de Flex.

Os dejo una reflexión sobre el análisis de todos los cambios que están ocurriendo.

En Febrero del 2009 Farata Systems anunció en su blog que comenzaba el proceso de liberación bajo licencia de código abierto su producto Clear Toolkit.

En aquel momento estaba en la versión 3.1 y estaba compuesto por:

• Clear Data Builder 3.1: Un plugin de eclipse que permitía la generación de código para hacer operaciones CRUD, tomando como base una sentencia SQL o una clase Java (DTO).
• DTO2Fx: una utilidad que permite la generación de las clases en ActionScript partiendo de una clase correspondiente en Java.
• Log4Fx: Un plugin para Eclipse que automatiza y hace más amigable la generación de trazas en la aplicación.
• Fx2Ant: Una utilidad que genera scripts ant basado en el proyecto Flex
• clear.swc: Una biblioteca de componentes Flex que incluye componentes que hacen facilitan la implementación de las funcionalidades CRUD en los proyectos.

Específicamente sobre la biblioteca clear.swc se han escrito varios artículos explicando su funcionamiento y cómo se usa en los proyectos:

• Introducing Enhanced Flex Components from Clear Toolkit Framework
• Building an Enterprise Framework – Enterprise Development with Flex, Part 1
• Building an Enterprise Framework – Enterprise Development with Flex, Part 2
• Building an Enterprise Framework – Enterprise Development with Flex, Part 3

El producto ha evolucionado, en la actualidad se encuentra en la versión 4.1 y se continúa desarrollando. Esta versión permite la generación del código necesario para realizar las operaciones CRUD, utilizando Hibernate, partiendo de clases Java (DTO) y de interfaces en las cuales se incluyen anotaciones propias del framework, y que al ser compiladas provocan la generación del código. Ofrece también una solución a la sincronización de datos, funcionalidad que no está presente en BlazeDS y sí en LiveCycle Data Services.

Las diferencias entre BlazeDS+Clear Toolkit y LiveCycle Data Services se abordan en el artículo Open source alternatives to LiveCycle Data Servcies.

Otra de las funcionalidades presentes en esta última versión es la posibilidad de hacer “lazy loading” desde flex. Para esto se incluye en la clase Java una anotación que indica la relación (One-to-Many o Many-to-One) y el framework genera todo el código necesario tanto en Java como en ActionScript para esta funcionalidad.

Existen dos screencast que muestran muy claramente cómo se utiliza esta funcionalidad, estos videos se pueden encontrar en:

• http://www.cleartoolkit.com/videos/cdb4.1/Episode1UsingEntities/
• http://www.cleartoolkit.com/videos/cdb4.1/Episode2HierarchicalCollectionsWithEntities/

Los desarrolladores trabajan en la integración con Spring, lo que seguramente estará disponible en versiones futuras.

La documentación de las clases tanto de la biblioteca clear.swc como de java se puede leer en:

• http://help.faratasystems.com/en_US/cleartoolkit/reference/flex/4/
• http://help.faratasystems.com/en_US/cleartoolkit/reference/BlazeDS/4/

El proyecto continúa hospedado en Sourceforge desde donde se puede descargar la última versión del producto así como acceder a la documentación, a los fórums y al código fuente.

Les recomiendo que lo prueben, una vez que se conoce como funciona se ahorra mucho tiempo en la implementación de la funcionalidad CRUD en los proyectos.

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().

Ahora que Cairngorm 3 desde hace un tiempo ya es una realidad, on este artículo queremos mostrar que es, que nos aporta respecto a sus versiones anteriores y daremos un vistazo a su evolución.

Las versiones anteriores de Cairngorm se basaban en una implementación específica del patrón Model-View-Controller, en cambio Cairngorm 3, debido a la experiencia, quiere darnos una serie de guías, buenas prácticas y nos aporta unas librerías y herramientas para ayudarnos en el desarrollo.
Esto implica que el paso de Cairngorm 2 a 3 no sea un simple un cambio de versión si no un cambio de paradigma.

El objetivo de Cairngorm 3 es dar unas bases para conseguir unos desarrollos limpios, consistentes, testeables y fácilmente escalables.

Arquitectura de Cairngorm

Para aproximarnos a un diseño simple y testeable, Cairngorm recomienda una arquitectura concreta para las aplicaciones Flex. Esta arquitectura tiene como objetivo que la estructura de la aplicación se desglose en pequeñas unidades de funcionalidad.

Antes de ver la separación arquitectural, entendamos como concibe Cairngorm una aplicación. Está compuesta de 3 capas de alto nivel:

• Capas de arquitectura: responsables de separar las clases según su responsabilidad
• Áreas funcionales: agrupan clases que atañen el mismo ámbito funcional
• Patrones de diseño: nos permiten coordinar los objetos de manera consistente

Capas de Arquitectura

Las clases con diferentes tipos de responsabilidad en las diferentes capas, pueden cambiarse separadamente por otras. De esta manera, si el diseño visual necesita ser ajustado, la mayoría de los cambios se limitan a clases de la capa de presentación y no a otras partes del código.

Cairngorm recomienda esta separación de capas según la responsabilidad general de cada una de ellas:

• Presentation: se encarga de la apariencia visual y del comportamiento de la presentación. Cairngorm recomienda el uso del patrón de presentación Presentation Model, que se encarga de controlar el estado y comportamiento de la capa de visualización.
• Application: coordina la presentación y la infraestructura de componentes. Coordina los componentes de distintas capas y los enlaza con los Domain Objects mediante el concepto de Controller que ya veremos.
• Domain: se centra en las tareas sobre el modelo de negocio. Representa una abstracción del mundo real mediante un modelo de datos. Sus responsabilidades suelen ser: la validación, cálculos sobre los datos, filtro, ordenación y formateo de datos…
• Infrastructure: coordina los objetos y su integración con otros sistemas, como el servidor y sus servicios remotos.

En la siguiente figura vemos la jerarquía de capas. De arriba hacia abajo, la comunicación entre una capa y su contigua es directa; en dirección contraria, la comunicación se realiza mediante eventos, callback functions u otras soluciones similares.

Áreas funcionales

Las aplicaciones se suelen dividir en diferentes áreas funcionales. La codificación de cada área funcional suele estar agrupada y separada de otras áreas funcionales, para que así sean desarrolladas y probadas de manera independiente. Podemos tener una aplicación de ejemplo que esté compuesta por tres áreas funcionales: contactos, mensajes y gastos. Entonces, cada una de estas áreas es subdividida según las distintas capas de arquitectura, según sea conveniente, como podemos ver en la siguiente imagen:

Cada área funcional suele estar contenida en un package. Ciertas áreas funcionales, según su grado de relación, pueden estar contenidas en un proyecto separado y así extraerse en módulos. El código que suele usarse en diferentes partes de la aplicación, como componentes, suelen ponerse dentro de un proyecto de librería.

Las áreas funcionales suelen tener sus capas de presentación y aplicación. A menudo contienen sus propias capas de dominio, pero otras veces comparten conocimiento del modelo de dominio de otras áreas. En este caso, estos modelos de dominio suelen ser encapsulados en proyectos de librería. Las áreas funcionales pueden interactuar con otras mediante interfaces y eventos AS3.

Capa de presentación

Presentation Model

Una de las cosas que nos recomienda Cairngorm 3 es tender a minimizar el código dentro de los mxml. Si es posible debemos intentar no tener código ni funciones, así las vistas reducen su tamaño y se centran solo en la disposición de sus componentes; haciendo más fácil la lectura.

La manera de hacerlo es extrayendo las variables y funciones que estarían en el Script-block en presentation models.
Cada componente o vista MXML significativa debe tener su propio presentation model. El PM se centra en el estado y comportamiento requeridos para representar los datos en la vista.

Un PM no debe saber nada de otro, ni de la vista relacionada ni de qué sirve a la aplicación. Un PM no debe tener referencia a la vista a la cual sirve, sino que es la vista que observa al PM relacionado. La comunicación entre ambos se realiza mediante Bindings o eventos.

Con esta aproximación minimizamos los errores en la vista y la lógica se localiza en el PM, que es fácilmente testeable.

Coordinación entre PMs

Cairngorm nos muestra dos entidades para coordinar los presentation models con otras entidades: Presenter y Controller. A continuación los vemos con mayor detalle.

Presenters

Su ámbito se centra en la capa de presentación. Se encarga de la coordinación local entre Presentation Models de una misma área funcional o de una región de ésta. Entendemos pues que su rol está por encima de los PMs.

Sus principales objetivos son:

Desacoplar la presentación del Dominio

Coordinación de PMs

Como vemos en la figura anterior, reducen el acoplamiento entre PMs y los domains, escuchando eventos procedentes de los domains y comunicándolos a los PMs.

También son usados para manejar los eventos procedentes de PMs y delegarlos a otros PMs.
Las razones que nos pueden motivar a usar Presenters son:

• Facilitan la lectura y control a alto nivel de la coordinación entre PMs
• Se encargan de asegurar el orden en la gestión de los eventos lanzados por los distintos PMs, ya que los mecanismos de mensajería, normalmente no suelen definir un orden
• Evitan el código de gestión de eventos (event-handling) en cada PM para escuchar a las peticiones de los otros

Controllers

Los Controllers se sitúan en la capa de Application. Tienen la responsabilidad de gestionar la coordinación general de los Presenters, no en un ámbito local, sino más global de un grupo específico de PMs. Se encargan de:

• Traducir los eventos procedentes de un área funcional a eventos de otras áreas funcionales
• Interceptar eventos a nivel de aplicación
• Traducir los eventos de aplicación a llamadas de la API de dominio con la finalidad de mantener los objetos de dominio libres de cualquier conocimiento relacionado con otras capas arquitecturales

En situaciones determinadas, los PMs pueden comunicarse directamente con los objetos de dominio y recibir sus cambios mediante eventos, como podemos ver en la siguiente figura:

Aplicaciones Modulares

La modularidad va más allá de los conceptos de Flex Module y ModuleLoader. Implica la separación de aplicaciones en unidades pequeñas que pueden ser desarrolladas y testeadas independientemente.

Beneficios de la Modularización

• Un modulo puede ser desarrollado, y probado con una relativa independencia
• Los tiempos de compilación se minimizan, ya que los cambios en un módulo no requieren de otros módulos
• Los módulos pueden ser cargados bajo demanda, lo que hace que la carga inicial de la aplicación es mucho menor
• Si un usuario no usa un determinado módulo, no es necesario cargarlo
• Se pueden cargar diferentes módulos para distintos usuarios, según sus privilegios
• Un modulo es más fácil de entender y mantener que una aplicación monolítica, consiguiendo una mejor cohesión funcional
• La interacción entre módulos puede determinarse con APIs, independientemente del crecimiento de la aplicación

Modularización y Cairngorm 3

Como hemos visto, una de las claves de Cairngorm 3 es separa las aplicaciones en diferentes áreas funcionales que pueden ser desarrolladas independientemente; viene a ser una arquitectura modular, donde cada área funcional sería un módulo. Cairngorm recomienda que la comunicación entre las distintas áreas funcionales se haga mediante APIs definidas por interfaces, eventos y DTOs. Así minimizamos las dependencias entre las distintas áreas.

Tendencia hacia el bajo acoplamiento

Cairngorm 3 da mucha importancia a que las capas arquitecturales tengan un mínimo acoplamiento, asumiendo que cada capa cambia por motivos diferentes. Con un bajo acoplamiento en las distintas capas, éstas pueden tolerar mejor el cambio. Por otro lado, el bajo acoplamiento tiene un precio: cuanto menos acoplado esté un objeto a otro, se incrementa la dificultad de lectura.
Hay distintas opciones para conseguir un bajo acoplamiento que los desarrolladores deben tener en cuenta.

Opciones para construir, recuperar y aislar objetos

La manera en que creamos, recuperamos o aislamos los objetos en una aplicación Flex, es un aspecto importante.
Por ejemplo, creando un objeto de dominio dentro de un PM, provocamos una dependencia directa. Implica que el objeto queda aislado y si otra parte de la aplicación requiere este objeto, no tendrá acceso directo para consultarlo.

Además con esta dependencia forzada con el objeto de modelo dentro del PM, estamos atando fuertemente la capa de presentación a una implementación concreta del dominio. Con una interface del dominio y usando eventos, podemos bajar el acoplamiento, desacoplando las capas arquitecturales.

La implementación de un objeto de dominio no puede cambiarse sin cambiar la implementación del PM, lo cual puede restringir la flexibilidad de la aplicación.
Los objetos de modelo tienen un significado a más alto nivel que el PM. Cuando el dominio puede abstraerse y controlarse con objetos de más alto nivel, conseguimos una inversión de control, que se opone a la aproximación usual de que objetos de bajo nivel controlan a otros.

Opciones de separación de la construcción y comportamiento de los objetos

Puede ser muy incómodo para el PM substituir el objeto de dominio con una implementación diferente cuando el PM crea al objeto de dominio. Puede también ser muy incómodo el hecho de recuperar una misma instancia del dominio en un determinado lugar de la aplicación. Tenemos diferentes opciones de separar la creación del comportamiento de un objeto para simplificarlo, a continuación mostramos las dos más comunes.

• Aproximación transversal: El modelo de dominio se instancia en el PM o Vista de más alto nivel y se va propagando jerárquicamente a las subvistas o PMs relacionados.
• Aproximación con framework de IoC: Se responsabilizan de la construcción de los objetos. El desarrollador especifica los objetos que se necesitan en el container de IoC.
  Así el framework IoC puede proporcionar estos objetos mediante inyección de dependencias o dependency lookup.

Librerías que nos proporciona Cairngorm

Cairngorm 3 proporciona diferentes librerías, alguna de ellas construidas sobre frameworks existentes como Parsley, Swiz y Spring ActionScript.
Estas librerías son interesantes, tenemos librerías para validación, para la gestión de popups, de navegación, gestión de módulos, etc. Recomiendo que leáis este apartado para que veáis que nos proporciona.

Para entender más como funciona Cairgorm 3 y los distintos conceptos, es necesario mirar y analizar un poco el código de las aplicaciones de ejemplo.

La información de Cairngorm 3 está en este link.

En este último post de la serie Flex Hero Mobile, veremos cuatro elementos importantes y necesarios en las aplicaciones Mobile: List, Scroller, Mobile Splash Screen y Mobile View Menu. Daremos una ojeada a vista de pájaro de estos elementos.

List y Scroller

Los componentes List y Scroller de Flex 4 fueron pensados para usar en pcs. El hecho de usar estos componentes en dispositivos mobile, implica modificarlos para adaptarse al modelo de interacción del usuario y conseguir un mejor rendimiento y suavidad del movimiento. Han habido los siguientes refactorings:

• Modificación del componente Scroller para conseguir nuevas funcionalidades a través de una nueva API.
• Modificación de la list de Spark para un mayor rendimiento en cuanto a scrolling e inicialización, y una mejor utilización de los ítem renderers y el rendimiento que saca de éstos.

Eventos de Mouse vs eventos Touch

Flash Player tiene tres tipos de eventos asociados a las pantallas táctiles: mouse events, touch events y gesture events. Los mouse events sobre todo son mantenidos para no perder retro compatibilidad con las versiones anteriores del framework. Son lanzados con el primer toque sobre la pantalla. Los touch events pueden ser lanzados por muchos toques y son asociados mediante un touch id.

Los gesture events son eventos de nivel superior, como el zoom o la rotación. Son, primeramente, lanzados mediante el sistema operativo y después los relanza Flash. No todos los SO soportan estos eventos.

Dependiendo del input que recibe Flash Player, lanza uno de los eventos descritos.

Item Renderers

El rendimiento siempre debe tenerse en cuenta. No hay nada tan pesado como tratar una lista en un dispositivo mobile y que ésta vaya a trompicones. La mayoría de veces se debe a la mala implementación de los item renderers. Es por eso, que se recomienda crear los item renderers mediante ActionScript. Una de las respuestas al “por qué“, que podemos preguntarnos es que la primitiva de texto más ligera, por ejemplo, está disponible solamente en ActionScript y es mucho más rápida y fácil de renderizar que una Label Spark.

MobileItemRenderer

facilita el trabajo que requiere un item renderer. Es el item renderer aplicado por defecto. Extiende a UIComponent e implementa IItemRenderer. Contiene un componente de texto.

MobileIconItemRenderer

este ítem renderer tiene 4 partes opcionales: un icono a la izquierda, una línea sobre el icono, un texto multilínea al lado del icono y un decorador a la derecha.

Mobile Splash Screen

Proporciona una Splash Screen preloader (pantalla de carga de la aplicación) por defecto para las aplicaciones Flex Mobile. Nos permite especificar un recurso embebido, así como aplicar opciones de redimensionado y aplicarse a pantalla completa, si se desea.

Se ha añadido una nueva clase: spark.preloaders.SplashScreen, que proporciona las siguientes propiedades:

• splashScreenImage: permite poner una imagen como child.
• splashScreenScaleMode: controla el tamaño y posición de la imagen.
• splashScreenMinimumDisplayTime: permite especificar el tiempo mínimo que se tiene que mostrar la splash screen. El valor por defecto es 1000 ms.
• Esta clase está pendiente de los cambios de orientación o redimensión.
• No se necesita hacer trabajo extra para hacer que se comporte a full-screen.

Mobile View Menu

ViewMenu es un SkinnableContainer con un layout customizado e incluye interacción con el teclado. Este componente aparece cuando el usuario pulsa el botón de menú.

Un ViewMenu expone un conjunto de acciones para interactuar con la vista activa. Cada vista tiene una propiedad llamada ViewMenuItems que nos permite especificar la lista de elementos que mostrará ViewMenu cuando esta vista esté activa.

El flujo de interacción que sigue el ViewMenu es el siguiente: cuando el usuario pulsa el botón de menú, la MobileApplication crea un ViewMenu, lo popula con la vista activa y lo muestra usando PopUpManager. Cuando el usuario selecciona un ítem, este ViewMenuItem lanza un evento de click y la MobileApplication cierra el ViewMenu.

ViewMenuItem

Es una subclase de ButtonBase. Contiene la propiedad label y un icono.

ViewMenuItemSkin

ViewMenuItemSkin extiende ButtonSkin.

ViewMenuLayout

Extiende LayoutBase. En posición vertical permite hasta un máximo de 3 columnas y en horizontal, un máximo de 6. En cada fila pone elementos del mismo tamaño.

Más info en estos enlaces:
List y Scroller
Mobile Splash Screen
ViewMenu

En este post hablaremos de la ActionBar, un componente que ayuda a la navegación de las aplicaciones Mobile hechas con Hero. También trataremos los TextComponents que nos proporciona el framework para tratar elementos de texto.

ActionBar

Descripción detallada

ActionBar es un SkinnableComponent que proporciona navegación, además de permitirmos añadir el título y las acciones relacionadas con el ViewNavigator.

ActionBar tiene las siguientes propiedades:

• ActionBarSkin: la skin po defecto
• Opcional: tenemos como opcional el titleDisplay, para mostrar el título, navigationGroup, titleGroup y actionGroup.

A continuación vemos las distintas partes de la ActionBar:

Title Group

Si el titleContent no es nulo, reemplaza a titleGroup. En caso contrario, ActionBar insertará el titleDisplay, si existe, como titleGroup.

Action Group

El actionContent es un proxy para el contenido del actionGroup. A diferencia de titleGroup, no tiene preferencias para el caso de contenido nulo.

Navigation Group

De la misma manera, navigationContent es un proxy para en contenido de navigationGroup.

Interacción entre la ActionBar, las vistas y el ViewNavigator

Tanto las vistas como el ViewNavigator definen proxies para las 6 propiedades de la ActionBar. Cuando el ViewNavigator añade una nueva vista, comprueba los valores para estas propiedades y da el contenido a la ActionBar. Si la vista activa no define estos valores, ActionBar da sus valores para estas propiedades. De esta manera los developers pueden determinar contenido por defecto en la zona del navigationContent, como puede ser el Home Button.

El ViewNavigator controla el contenido de la ActionBar cada vez que un evento de navegación ocurre. ViewNavigator escucha los cambios de las propiedades cuando una vista es activada, con la finalidad de actualizar la ActionBar. Cuando se desactiva la vista, ViewNavigator quita los listeners de la vista y escucha la nueva vista activa.

Debajo vemos diferentes modalidades de la ActionBar.

Podeis encontrar más información y ejemplos en este link.

Text Components

Descripción detallada

Tienen como objetivos los siguientes:

• Disponer de los componentes de texto típicos como: Label, TextInput y TextArea
• Proporcionar el máximo rendimiento en áreas críticas, como skins o items renderers
• Proporcionar una predicción de texto nativa y de edición

Características

Los componentes de texto para mobile, por motivos de rendimiento, extienden de TextField. Esto hará que la performance sea mejor, aunque si queremos optimizar al máximo en ciertos escenarios, como en la creación de item renderers, podemos mirar la especificación de estos elementos.

Además nos proporcionan:

• Una nueva primitiva llamada StyleableTextField: extiende de TextField y nos da soporte para estilos. También implementa IDisplayText y IEditableText. No implementa IUIComponent o ILayoutElement, por lo que no puede usarse como child de un container. Está pensada para usarse en skins y en item renderers.
• Dos nuevas primitivas, IDisplayText y IEditableText: definen el contrato entre un text display y un editable text. Las skin parts de Texto en los componentes Spark han sido actualizadas para usar estas interfaces en lugar de TextBase y RichEditableText.
• Nuevas skins para los componentes TextInput y TextArea: estos componentes usan la nueva primitiva StyleableTextField.

Teclado y Focus

Los TextInput y las TextArea editables han sido pensadas para que pueda introducirse texto, de manera que no se permite que el teclado se superponga encima de ellos. Cuando uno de estos componentes recibe el foco, el típico rectángulo de color los envuelve.

Mas información aquí.

En el segundo post de Hero en cuanto a Mobile veremos el componente ViewNavigator, que actúa como core del modelo de navegación de las aplicaciones mobile hechas con Hero.

Introducción

El concepto View y view navigator son conceptos del nuevo framework Hero que nos permite crear y navegar dinámicamente por el contenido de la aplicación. ViewNavigator es un componente que trata la creación y presentación de las vistas. ViewNavigator usa una pila de vistas, que hace que solo sea visible la que se situa en el top de la pila. El developer puede usar los métodos como pushView y popView para ir a una vista o retornar a una vista previa.

Objetivos

• Mostrar dinámicamente el contenido de una área específica
• Dar la habilidad para navegar por distintas vistas
• Proporcionar un sistema de datos para dar la información necesaria a una vista cuando se crea
• Soportar diferentes políticas de destrucción
• Proporcionar una Infrastructura para rellenar automáticamente la ActionBar con los datos relacionados con la vista activa

Relación con ViewStack

ViewNavigator es similar al componente mx:ViewStack: pueden cambiar rápidamente el contenido visual. La mayor diferencia entre ellos es el sistema de navegación: ViewStack solo puede cambiar entre estados predefinidos, mientras que ViewNavigator permite al developer activar dinámicamente un número de vistas y saltar rápidamente entre ellas, según el flujo que defina el usuario. Esto significa que ViewNavigator crea y mantiene un historial de navegación y representa mejor el modelo de navegación. Además ViewNavigator contiene un modelo de datos con la habilidad de persistir los datos y estados entre diferentes sesiones de la aplicación.

Relación con los States

ViewNavigator no se puede considerar un reemplazo de los States de Flex. Aún y así, las vistas y los states son similares en tanto que permiten al developer cambiar el contenido bajo demanda, pero hay diferencias: los states son un subsistema que se concentra en el cambio de subpartes de componentes y propiedades en el mismo instante de tiempo, controlados por un solo thread; mientras que las vistas centralizan toda la lógica y el contenido relacionado en un único componente, el cual es reemplazado totalmente al navegar a otra vista.

Descripción detallada

Estructura del componente

A continuación vemos este componente:

La content area es el contenendor principal de la vista actual. Cuando se crea una vista, automáticamente es añadida a este contenedor. La ActionBar nos permite mostrar la información contextual a la vista actual.

Control de las vistas

Como hemos dicho, ViewNavigator usa una pila para controlar las vistas, concretamente tiene un vector de objetos llamado navigation stack, donde el primer elemento es el que estará activo y visible. ViewNavigator nos proporciona un sistema de push y pop de vistas. Es importante destacar que no proporciona ningún mecanismo para poder mostrar una vista específica de la navigation stack.

En la imagen anterior vemos como al seleccionar un elemento de la vista de búsqueda, accedemos a la vista de detalle. Esto provoca la destrucción de la vista de búsqueda y la vista de detalle pasa a ser la activa y visible.

Vistas

Una vista (View) es la clase base de todas las vistas de la aplicación y es una subclase de Group. Una vista tiene una propiedad data que será usada para representar su contenido y estado. Este objeto es automáticamente serializado, persistido y restaurado por el view navigator cuando una vista se activa o desactiva.

Políticas de destrucción

La implementación incial de ViewNavigator solo permite una vista visible. Cuando una vista pasa a ser activa, los componentes de la anterior se destruyen. De esta manera tenemos una mejor gestión de memoria.
También es cierto que en determinados escenarios es más costoso destruir una vista y volverla a crear cuando sea necesario. Para tratar esto, las vistas tienen una propiedad llamada destructionPolicy que determina que debe pasar cuando la vista es reemplazada en la pila. Por defecto se destruyen, pero podemos determinar que se mantengan en memoria.

Modelo de datos de la vista

Las vistas también tiene soporte para la persistencia de datos. Estos datos se guardan en un objeto y se settean a la propiedad data de la vista cuando se hace la llamada de pushView(). Des esta manera se asegura que la vista contenga los datos que necesita. Cuando una nueva vista se pone como activa, los datos de la anterior son guardados.

Ciclo de vida de una vista

ViewNavigator sigue el flujo típico de invalidación de las aplicaciones Flex para hacer la transición entre vistas. Así un developer puede ejecutar operaciones de navegación en un solo frame. Todas las operaciones de navegación pueden ser canceladas.

A continuación el diagrama de acciones y eventos que suceden cuando se solicita una nueva vista:

Visibilidad de la ActionBar

Disponemos de dos layouts para la action bar dentro del navegador. El developer puede cambiar entre ellos usando la propiedad overlayControls de la vista y del ViewNavigator. Con overlayControls a false, la ActionBar usa como layout vertical. SI tiene valor true, el área de vista se expande al width y height del navegador. La ActionBar se pone encima aplicando un alpha determinado.

Orientación

ViewNavigator soporta las orientaciones de portrait y landscape. Debemos usar los siguientes skin states del ViewNavigator:

• portrait: Las vistas se muestran en layout portrait y con la ActionBar con el layout por defecto
• landscape: Las vistas se muestran en layout landscape y con la ActionBar con el layout por defecto
• portraitAndOverlay: Las vistas se muestran en layout portrait y con la ActionBar se superpone a la content area
• landscapeAndOverlay: Las vistas se muestran en layout landscape y con la ActionBar se superpone a la content area

Transiciones

Podemos definir transiciones para pasar de una vista a la siguiente. Podemos pasar un objeto de tipo ViewTransition para determinar que transición queremos aplicar.
ViewNavigator tiene dos skin parts opcionales: defaultPushTransition y defaultPopTransition.

Más información y ejempos aquí.

Igual que hicimos comentando las novedades de Hero para desktop, vamos a postear una serie para explicar, a grosso modo, lo que nos ofrecerá Hero para Mobile. En este primer post veremos una visión global centrada en la clase MobileApplication.

MobileApplication

Esta clase permite crear aplicaciones enfocadas a dispositivos móviles. Una aplicación mobile típica se divide en diferentes vistas que se van mostrando u ocultando según el flujo de la aplicación. Este modelo de aplicación se conoce como view-based. Una aplicación mobile saca partido del componente ViewNavigator, que ya veremos, para gestionar estas vistas.

Por otro lado, una aplicación mobile debe estar integrada con los eventos que nos puede lanzar el dispositivo, como la gestión de teclado o el control de la orientación.

A continuación vemos el típico flujo de una aplicación mobile (click para ampliar):

La metodología usada para desarrollar aplicaciones mobile es diferente a la que usamos para aplicaciones desktop. Una aplicación mobile se suele usar durante poco tiempo y a menudo interrumpida por otras acciones: mensajes, llamadas u otras aplicaciones. Se espera que al abrir una aplicación mobile, se hayan guardado los datos y estado anteriores, lo que implica que debemos persistirlos cada vez que la usamos.

Para poder conseguir este objetivo, Flex Hero nos proporciona apis de persistencia de datos para guardar los datos de las vistas. Esto permite a los developers guardar de forma rápida y sencilla los diferentes datos y estados entre sesiones.

MobileApplication no está pensada para ser usada para aplicaciones desktop o web, requiere AIR 2.5 SDK y swcs exclusivos de Flex Mobile (mobileComponents y mobileTheme).

Objetivos de MobileApplication

• Crear una aplicación mobile con una plantilla simple, que exponga los diferentes aspectos de UI comunes en las applicaciones mobile
• Automatizar el control de los eventos de orientación que se lanzan en runtime
• Automatizar el manejo de eventos de hardware, menu y búsqueda que se pueden dar en runtime
• La creación de un manager simple de persistencia que permita guardar los datos y recuperarlos bajo demanda
• La implementación de una skin básica para la aplicación

Descripción

Creación de Interficíe de Usuario

La clase MobileApplication provee una manera fácil y rápida de crear UI para móviles. Este componente extiende a SkinnableContainer y contiene una estructura muy específica definida con skin parts opcionales. Los componentes estándar de la UI son:

• ViewNavigator: usado par tratar la navegación a través de las vistas dentro de la aplicación. Se expande por todo el área libre de la pantalla del dispositivo. Nos proporciona acceso a una ActionBar, responsable de mostrar el título y los componentes contextuales de la vista actual.
• Menú de la aplicación: Se muestra en respuesta a un click a una acción sobre el menu del dispositivo.

Debido a que MobileApplication usa ViewNavigator para navegar a través de sus vistas, no podemos añadir directamente hijos al componente MobileApplication. El developer necesitará usar la propiedad firstView o invocar manualmente la llamada pushView() del navigator para definir que objeto visual se instancia al inicializar la aplicación.

Menú de aplicación

Muchos dispositivos móviles usan un menu de aplicación. Con este menu se muestran las acciones globales o contextuales relacionadas con cada estado de la aplicación.

Atajos de teclado

Se suelen usar en muchos dispositivos y también se ha aplicado a dispositivos que soportan Flex Mobile. La clase MobileApplication proporciona automáticamente un botón de retorno (back button) para gestionar la navegación principal de la aplicación. Cuando la tecla de retorno se pulsa, la clase MobileApplication comprueba cuantas vistas están en la pila. En el caso de que se esté gestionando más de una vista, mobile application llama el método popView() sobre el navigator para que muestre la vista anterior. Si no hay ninguna vista empilada o sólo se está gestionando la actual, al pulsar back retornamos a la vista principal de la aplicación.
La clase MobileApplication nos expone apis sencillas para que los developers puedan sobreescribir está funcionalidad si nos interesa otro comportamiento.

Soporte para la orientación

Las clases MobileApplication y ViewNavigator tienen comunicación estrecha para controlar la orientación del dispositivo. El developer puede usar la propiedad de la clase MobileApplication llamada landscapeOrientation, que es solo de lectura, y permite determinar la orientación del dispositivo. Cuando cambia la orientación del dispositivo, la clase MobileApplication capturará la orientación del stage y automáticamente actualize esta propiedad. Para cambiar la orientación física del dispositivo debemos usar las apis de la clase Stage.
La clase ViewNavigator soporta los estados de landscape y portrait.

Propiedades de vista a nivel de aplicación

A continuación mostramos propiedades interesantes de la clase MobileApplication. Estas propiedades se usan como proxy para usarlas sobre la clase ViewNavigator que contiene los mismos valores y definirlos si no han sido setteados en la vista actual.

• firstView: define la primera vista cuando no se ha definido ninguna sección
• firstViewData: el objeto de datos que se debe settear a la primera vista de la aplicación

Propiedades de la ActionBar

• title: el título usado en la action bar
• titleContent: los UIComponents que deberían ser visualizados en la ActionBar
• titleLayout: el layout por defecto de la zona de titleContent
• navigationContent: los UIComponents que se deben mostrar en la zona de navegación de la ActionBar
• navigationLayout: el layout de la zona de navegación de la ActionBar
• actionContent: los UIComponents a mostrar dentro de la zona de acción de la ActionBar
• actionLayout: el layout que se aplica dentro de la zona de acción de la ActionBar

Persistencia de datos entre las sesiones de la aplicación

Flex Mobile framework introduce un nuevo manager que nos permite guarda datos mediante una API muy sencilla. Este manager se llama PersistenceManager e implementa la interface IPersistenceManager. Nos da una lista de apis para que el developer pueda usar para guardar y tratar los datos de la aplicación.

Persistencia automática del estado de la aplicación

Usando PersistenceManager, la clase MobileApplication automáticamente guarda y restaura la información del estado de la aplicación para que dispongamos de ella cuando la aplicación se suspende y se relanza. MobileApplication tiene la propiedad sessionCachingEnabled que una vez habilitada hace que la aplicación guarde automáticamente su estado. Usa los siguientes parámetros para hacer este guardado:
versión de la aplicación, un timestamp para saber el momento es que se ha guardado y el estado de la navegación. Todo esto se guarda en la pila del navegador principal.

Debemos tener en cuenta que el objeto compartido que PersistenceManager usa para guardar los datos no está ni encriptado ni protegido. Se guarda con un formato fácilmente legible. Esto implica tener cuidado con lo datos que el developer guarda. El developer siempre tiene la posibilidad de implementar su propio manager de persistencia para crear una mejor manera de guardar los datos, si lo cree necesario.

Aquí encontrareis más información y ejemplos.

En los artículos anteriores dedicados a Pimento Data Service exploramos el uso de la clase EntityManager para invocar operaciones CRUD y la funcionalidad de “lazy loading”. Esta vez vamos a tratar el uso de los servicios personalizados y lo haremos como siempre a través de un ejemplo.

Habiamos mencionado en el primer artículo que Pimento Data Services ofrece dos modelos de programación, uno basado en la clase EntityManager y el otro basado en los servicios personalizados. Con este último se crean clases de Java que asemejan a la capa de servicios de una arquitectura multicapa, y se exponen como servicios remotos de Cinnamon, el framework que implementa AMF y que soporta tareas “ant” que facilitan la creación de “proxies” en ActionScript de estas clases Java.

El uso de este modelo de programación permite también aprovechar las facilidades de Pimento en cuanto a que entidades que hayan sido cargadas por un servicio personalizado pueden ser gestionadas por el framework, o sea, se cargarán en el “cache” del cliente, se gestionará su llave primaria cuando se haga persistente una nueva instancia, etc. Esto quiere decir que los dos modelos se pueden complementar entre sí para adaptarse a los requerimientos.

El ejemplo

El ejemplo que desarrollaremos será el mismo que en el artículo dedicado al “lazy loading”, pero en este caso, en vez de hacer la carga inicial de la entidad “Project” utilizando la clase EntityManager lo haremos utilizando un servicio personalizado, la asociación “One To Many” la cargaremos a través del método “initialize”, de EntityManager, lo que probará la integración de ambos modelos de programación.

Lo primero será descargar el framework de aquí. Luego creamos un proyecto de tipo “Dynamic Web Project” con las siguientes características:

• Nombre del proyecto: CustomPimentoServer
• Target Runtime: En nuestro caso usaremos Apache Tomcat 6, pero puede utilizarse cualquier otro que se haya configurado.
• Versión del módulo Web Dinámico: 2.5
• Configuración: Configuración por defecto para Apache Tomcat 6.0
• Cambiamos la carpeta donde se compilarán las clases a “CustomPimentoServer/WebContent/WEB-INF/classes”.

Una vez creado el proyecto copiamos el contenido de la carpeta “server/web/WEB-INF/lib” de la distribución del framework en “WebContent/WEB-INF/lib” de nuestro proyecto. Sustituimos el archivo de HSQLDB por el controlador JDBC de MySQL, y copiamos de la carpeta “server/release” los archivos “cinnamon-core”, “cinnamon-reflect”, “pimento-core” y ”pimento-generator”. Necesitamos copiar también “freemarker” y “paranamer” de la carpeta “server/lib” y el paquete “javassist”, este lo podemos encontrar en la distribución de Spring con dependencias. La carpeta “generatorTemplate” la copiamos en la raíz del proyecto.

Creamos una carpeta denominada “config” dentro de “WebContent/WEB-INF” de nuestro proyecto y copiamos los archivos “jpa-spring.xml” y “pimento-spring.xml” en “server/web/WEB-INF/config” en la distribución del framework; también copiamos el archivo “dp.properties.template.mysql” de “server/web/WEB-INF/config/db-templates” como “db.properties” en “WebContent/WEB-INF/config” de nuestro proyecto y ajustamos los valores de la conexión a la base de datos. Como estamos en fase de desarrollo ponemos “hibernate.hbm2ddl.auto=update”.

Finalmente el archivo “web.xml” de nuestro proyecto queda así:

En este caso el servicio personalizado se define en el archive service-spring.xml, cuyo contenido es el siguiente:

Las entidades con que trabajaremos son:

Project:

Task

Estas son entidades de JPA con anotaciones del framework que indica que serán gestionadas por éste.

El servicio personalizado se concibe como una clase que implementa una interface donde se definen todas las operaciones. El código es el siguiente:

ProjectService

Nótese aquí la anotación “@CinnamonService” que indica un servicio a ser invocado remotamente.

ProjectServiceImpl

Esta es una clase que utiliza JPA del modo tradicional donde de realiza la carga de la entidad Project. Para poder utilizar esta clase desde Flex a través de Pimento debemos generar el “proxy” para ActionScript, lo cual haremos mediante las tareas “ant” suministradas por el framework para esto:

Antes de proseguir con el cliente cargaremos algunos datos iniciales en la base de datos:

Creamos un proyecto Flex con las siguientes características:

• Nombre del proyecto: CustomPimentoClient
• Tipo de aplicación: Web
• Seleccionamos el SDK por defecto
• Como tecnología del servidor no seleccionamos ninguna
• Como carpeta de salida seleccionamos la carpeta WebContent del proyecto CustomPimentoServer que creamos anteriormente.

Nuestra interface de usuario será la misma que en el artículo anterior:

Inicialmente cargaremos una instancia de Project, pero esta vez utilizando el servicio personalizado, e inspeccionaremos el contenido de su propiedad “tasks”, luego cargaremos las instancias de “Task” asociadas mediante el método “initialize” de la clase EntityManager, las cuales mostraremos en el “DataGrid”.

Para estructurar mejor el proyecto nos auxiliaremos del framework Robotlegs. Lo primero que haremos será incluir en el proyecto las librerías del framework Pimento y Cinnamon. Copiamos en la carpeta “libs” del proyecto los archivos “cinnamon-1.1.0.swc” y “pimento-1.1.0.swc” que se encuentran en la carpeta “client\release” de la distribución, incluimos también “spicelib-core-2.0.1.swc” y “spicelib-reflect-2.0.1.swc” de la carpeta “client\lib” y la librería del framework Robotlegs.

Creamos luego las clases en ActionScript que representan las entidades:

Project

Task

La configuración del framework en el cliente comienza con la creación de una instancia de la clase “PimentoConfig”, a través de la cual podemos obtener el “EntityManager” que usaremos para invocar las operaciones de persistencia. La clase PimentoConfig necesita conocer el URL de la aplicación JEE que a través de Cinnamon recibirá las solicitudes del cliente para invocar las operaciones de persistencia, específicamente el URL al servlet “service”. En nuestro caso cargaremos esta información de un archivo xml externo. El comando que hace todo esto y además carga la instancia de “Project” que insertamos en la base de datos es el siguiente:

Para configurar el servicio personalizado creamos una instancia de ProjectServiceImp y lo registramos en el framework a través del método “addService”. Al final cargamos la entidad basado en su Id.

Una vez cargada la instancia de Project, ante el evento “Click” del botón se ejecuta el comando que carga los datos de la asociación:

El código fuente del proyecto se puede descargar desde aquí.

Conclusiones

Hemos visto el modelo de programación de Pimento que permite utilizar servicios personalizados, que no son más que clases de Java expuestas como destinos remotos que toman entidades como parámetros o devuelven entidades como retorno. Estas entidades pueden ser gestionadas por Pimento lo que permite que este modelo coexista con el otro que se basa en la clase EntityManager, dando gran flexibilidad a la aplicación.

Acabaremos esta serie de Hero para desktop con este post, hablando de estos tres aspectos importantes: Size Report, Open Source Media Framework (OSMF) y mejoras en cuanto a las Run Shared Libraries (RSL).

Hero Size Report

El tamaño final de las aplicaciones siempre es un aspecto determinante para cualquier proyecto. En este apartado veremos las mejoras que ha realizado Hero en este ámbito.

El compilador de Flex 3.x y 4.0 nos proporciona la opción -link-report , que genera un report XML, detallando el tamaño aproximado en bytes todas las clases ActionScript incluidas en el SWF final. Nos puede ayudar a ver durante el desarrollo, las areas que contribuyen, en mayor mesura, a tener una película demasiado pesada.

También disponemos de la utilidad swfdump utility, que proporciona un report de alto nivel, pero no lo suficientemente adecuado para ver las áreas problemáticas relacionadas con el tamaño de la película.
Flex 4.5 mejora la opción -size-report para tener un total del peso de cada tipo dentro del SWF (script, media, fonts, etc).

Uso

Cuando usamos mxmlc o compc -size-report , se obtiene un reprot XML como podría ser el siguiente:

El tag principal report, contiene un subtag llamado swf que nos da el tamaño en bytes del SWF, tanto comprimido como no comprimido.

Otra información

Este report también nos da información importante como puede ser:

• Sumario por frame:Nos proporciona un sumario de todos los scripts y tags a nivel de frame.
• Actionscript: Datos ActionScript asociados con el SWF.
• Frame data: Datos adicionales a las definiciones de los frames relacionados al SWF.
• Bitmap data: Los bitmap data embebidos en la aplicación.
• Fonts: Todas las Fuentes embebidas.
• Sprite: Datos a nivel de Sprite.
• Datos de los Shapes
• Datos binarios: Datos binarios relacionados con el SWF, como pueden ser shaders, Pixel Bender u otros tipos de datos embebidos.
• Datos de sonido
• Datos de video

Más información sobre esta característica aquí.

Integración de OSMF 1.0

Flex Hero actualiza la version de OSMF a 1.0. Con esta actualización se añado soporte para HTTP Streaming. Podemos usar esta funcionalidad para proporcionar recursos bajo demanda, como streamming dinámico mediante el componente Spark VideoPlayer.

Dos enlaces para más información:
HTTP Streaming
Información

Mejoras de Hero en cuanto a RSLs

Se ha hecho un esfuerzo para poder usar las RSLs de manera mucho más fácil y más efectiva.
El uso de las RSLs en la caché de Flash Player se introdujo en Flex 3. Flex 3 solo tenía 3 RSLs y solo se cargaba por defecto la RSL del framework. La opción RSL linkage estaba desactivada por defecto.
En Flex 4 se hizo el cambio para que se cargaran todas las RSLs y para permitir que pudieran ser debuggadas, aunque no se cambió la manera de cómo se configuraban y cargaban. Se cargaban 6 RSLs para cada aplicación.
Las RSLs se definieron de manera muy simple: especificando el SWC que se quiere como librería externa y luego cargando la RSL desde la URL que contiene todas las clases necesarias para que la aplicación funcione.

Historial de las RSLs

1. El número de RSLs aumentó en el paso de Flex 3 a Flex 4. La carga de todas las RSLs retarda el inicio de la aplicación, ya que las RSLs deben cargarse aunque no se usen en la aplicación.

2. En Flex 4 se espera que las sub-aplicaciones y modules usen las RSLs cargadas por la aplicación primcipal. Pero hay módulos que necesitan custom RSLs. Podemos pensar que la aplicación principal cargará estas custom RSLs, pero no es así.

3. Podemos crear RSLs para sobreescribir clases de las RSLs del SDK, pero el proceso es complicado.

4. Se está creando un set de componentes Spark como análogos de los componentes mx. En muchos casos no hace falta usar componentes mx. Si incluimos la RSL del framework, se cargan todos los components mx y provoca más consumo de memoria.

En relación a todo esto, Hero aplica las siguientes soluciones:

1. El compilador elimina las RSLs que no son usadas por la aplicación, usando una nueva opción de compilación: “remove-unused-rsls”.

2. Si una sub-aplicación o módulo intenta cargar una RSL que ya ha sido cargada, la ignora.

3. Para poder sobreescribir RSLs, podemos incluir una opción de compilador para que incluya sólo la herencia de dependencias en un SWC que serán usadas por la RSL sobreescrita.

4. Se han movido los componentes mx a una RSL separada para poder descartarla si no la usamos.

Rendimiento

El rendimiento usando RSLs ha mejorado en Flex 4.5 comparado con Flex 4.0. Las mejoras se deben a no cargar las RSLs que no se necesitan y la reducción de tamaño de la RSL del framework.
Se han hecho tests con una aplicación simple, la típica “Hello World” para demostrar las mejoras de rendimiento.
La aplicación ha sido complada en 4.0 y en 4.5 con la opción de compilador “remove-unused-rsls”. El resultado es que se han quitado RSL que no se usan, como osmf o rpc y se ha conseguido reducir el tamaño de la RSL del framework de 608 KB a 310 KB.
Con una velocidad de bajada de 1500 kbps, se optienen estos resultados:
para la versión de SDK 4.5 el tiempo de inicialización es de 9 segundos y la memoria de sistema necesaria es de 14 MB, mientras que para el SDK 4.0 se precisan 15 segundos de inicialización y 17.4 MB de memoria.
Así observamos que hay una reducción considerable en cuanto a tiempo y a memoria.

Más info en estos dos links:
RSL enhancements
Linking RSLs