Se ha hecho oficial el anuncio de Player 11, AIR 3, Flex 4.6 y Flash Builder 4.6. Se estima que estarán disponibles a partir de octubre.
Os dejo a continuación dos links para que podáis haceros una idea de lo que esto implicará:
link 1
link 2

Recientemente un viejo conocido de la comunidad Flex hispana (Nahuel Foronda) ha publicado una serie de interesantes posts sobre Optimización de Flex para Móviles que iremos posteando traducidos al español, previa autorización

Si estás comenzando a hacer desarrollo móvil y estás acostumbrado a crear todos los ItemRenderers en MXML, habrás notado que pequeños dispositivos como teléfonos y tabletas no tienen un desempeño tan bueno como en escritorio y necesitarás buscar diferentes maneras de optimizar tu aplicación.

Una de las formas de optimizar tu aplicación móvil es crear tus ItemRenderers con ActionScript. Narciso Jaramillo escribió un buen artículo para Devnet con buenos tips para el desarrollo móvil y uno de los puntos es precisamente eso, mantener tus ItemRenderers en puro ActionScript.

Narciso menciona que el Framework de Flex viene con dos ItemRenderers uno es LabelItemRenderer que extiende a UIComponent y el otro es IconItemRenderer que extiende a LabelItemRenderer. Esas clases son buenas, pero a veces tenemos un diferente caso de uso que necesita una serie diferente de clases. así que en los ejemplos, no utilizaré esos rendereres. En su lugar, extenderemos directamente desde UIComponent o desde SpriteVisualElement para tener inclusive una clase más ligera que UIComponent.

Para el propósito de este tutorial, estoy planeando una serie de entradas explicando las bases y pasar a renderers con mayor dificultad.

Ejemplo Básico

Comencemos con el renderer más simple, un TextField que muestre algún texto. Para hacerlo sencillo, extenderemos desde UIComponent e implementaremos la interfaz IDataRenderer requerida por List.

Pero antes de hablar sobre el renderer, hablemos de otros elementos.

Application

Necesitas crear un proyecto tipo Mobile. En este ejemplo, usaré el más simple de los contenedores raíz, ese es un Application, no las subclases TabbedApplication o ViewBasedApplication. Agregaremos un List que se expanda al 100% como único elemento.

Estilos

Agregué una hoja de estilos externa donde tenemos todos los estilos para el ItemRenderer:

ItemRenderer

Tenemos una clase simple que extiende a UIComponet que nos da algunos métodos útiles y la habilidad de participar en el framework de CSS.

Estos 3 métodos de UIComponent que utilizaremos son los siguientes:

measure donde nosotros leemos el tamaño mínimo del renderer desde la hoja de estilos. Esto se vuelve útil porque dispositivos con diferentes resoluciones dpi necesitan diferentes medidas.

createChildren donde nosotros creamos el TextField, establecemos los estilos y si hay datos disponibles, configuramos el texto en el TextField a ser mostrado.

updateDisplayList donde posicionamos los elementos y dibujamos cada línea separadora para cada ItemRenderer.

Adicionalmente a estos métodos, tenemos la propiedad data, que es la implementación de la iterfaz IDataRenderer. Esa interfaz es el contrato con List y es la forma en la que los datos son empujados hacia el ItemRenderer. Si el TextField existe al momento de configurar los datos, entonces configuramos el texto dentro del TextField, de otra manera, lo guardamos para después.

Como pueden ver escribir un ItemRenderer en ActionScript no es tan difícil como suena.

Estoy planeando mostrar otros ejemplos en el futuro con múltiples elementos, fondos, estados, manipulación de texto, columnas múltiples y más.

El código fuente esta disponible para descargar.

Nota: Este artículo está traducido en MadeInFlex con autorización previa del autor, si quieren consultar la fuente original aquí tienen el enlace.

Tal como habiamos anunciado Farata Systems ha liberado una nueva versión de su herramienta Clear Toolkit, esta vez con soporte para Spring.

Durante la creación del proyecto se puede elegir si se incluye soporte para Spring o no, y en tal caso todas las clases generadas se cargan como beans gestionados por el contenedor y se hacen disponibles a la aplicaciopn flex a traves del paquete de integración de Spring con BlazeDS.

El proyecto sigue hospedado en sourceforge, pero ahora estrena un nuevo sitio con toda la documentación necesaria para comenzar a usar esta herramienta.

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

El framework Pimento Data Services nos permite realizar el “lazy loading” de una asociación que haya sido configurada como “lazy” en JPA. Para ese tipo de asociación el framework envía al cliente solamente “proxies”, no los datos reales, los datos reales serán cargados en el momento que se invoque el método “initialize” de la clase EntityManager, y no obtendremos una excepción del tipo LazyInitializationException. Veamos cómo funciona a través de un ejemplo.

El ejemplo

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: LazyPimentoServer
• 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 “LazyPimentoServer/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” y “pimento-core”. Necesitamos copiar también el paquete “javassist”, este lo podemos encontrar en la distribución de Spring con dependencias.

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í:

Seguidamente crearemos las entidades asociadas:

Project

Task

Como vemos son dos entidades JPA con anotaciones de Pimento que indican que serán gestionadas por éste. La entidad “Project” tiene una asociación con la entidad “Task” de tipo OneToMany configurada como “lazy”, lo que implica que cuando se cargue una instancia de “Project” no se cargarán en ese instante las instancias de “Task” asociadas con ésta. En este caso el framework enviará al cliente “proxies” que serán utilizados para cargar los datos reales. Veamos cómo funciona esto desde la UI, pero primero cargaremos algunos datos en la base de datos:

Creamos un proyecto Flex con las siguientes características:

• Nombre del proyecto: LazyPimentoClient
• 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 LazyPimentoServer que creamos anteriormente.

Nuestra interface de usuario sería algo como esto:

Inicialmente cargaremos una instancia de Project 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:

Si corremos la aplicación con el “debugger” y nos paramos dentro del método loadResult veremos que el tipo de la propiedad “tasks” de Project no es un “Array” como está definido sino de tipo “ArrayProxy”.

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 método que carga los datos de la asociación es “initialize”, de “EntityManager”, se le pasa como argumento la propiedad “tasks” de la instancia de “Project” previamente cargada.

Una vez más, si corremos la aplicación con el “debugger” y nos paramos dentro del método “initializeResult” veremos que el tipo de la propiedad “tasks” ha cambiado de “ArrayProxy” a “Array”, conteniendo las instancias de “Tasks” asociadas.

El código fuente del la aplicación, cliente y servidor se puede descargar de aquí.

Conclusiones

Hemos visto como Pimento Data Services nos permite hacer “lazy loading” de entidades directamente desde ActionScript de una forma verdaderamente simple. Tan solo debemos poner las anotaciones en la entidad Java y el framework se encarga del resto, es una lástima que Pimento y Cinnamon no soporten ninguna funcionalidad que permita hacer sincronización de datos entre varios clientes. ¿Alguien se anima?

¿Qué es Pimento Data Services y qué funcionalidades ofrece?

Cuando utilizamos JPA e Hibernate para ejecutar operaciones CRUD en nuestra aplicación creamos las entidades con sus correspondientes anotaciones, luego creamos una capa DAO en la cual invocamos las operaciones de persistencia y finalmente una capa de servicios desde la cual invocamos los métodos del DAO y encapsulamos la lógica de negocios. Si ejecutamos todo este código en una aplicación JEE que implemente AMF podremos invocar estos métodos desde Flex utilizando Remote Objects. Pero en caso que decidamos dotar de más inteligencia a la aplicación Flex podemos trasladar la capa de servicios al cliente y en este caso necesitaríamos invocar directamente a la capa DAO o a las operaciones de persistencia.

Pimento Data Services nos permite, desde ActionScript, invocar las operaciones de persistencia definidas por JPA en el servidor, a través de la clase EntityManager, homóloga de la de JPA, pero adaptada a este tipo de cliente. A través de esta clase podemos invocar las operaciones “load”, “persist”, “remove” y “merge”, además de ejecutar consultas utilizando JPAQL y “Named Query”.

El framework almacena en un “cache” en el cliente las entidades cargadas del servidor, asegurando que exista una sola instancia de cada entidad, y este “cache” se utiliza para enviar al servidor solamente las propiedades que cambien cuando se realice una operación “merge” o para restablecer el estado original de la entidad, también ofrece métodos para eliminar objetos del “cache” e inspeccionar si un objeto ya existe en el “cache”.

Pimento ofrece también funcionalidades que permiten realizar “lazy loading” de entidades. Para todas las asociaciones y colecciones marcadas como “lazy” que no han sido inicializadas en el momento de la carga, el servidor envía solamente “proxies” al cliente, y en el momento necesario, utilizando el método “initialize” de la clase EntityManager se cargarán el resto de los datos.

Ante una operación “merge” de una entidad se compara el estado de la misma con la que se encuentra en el “cache” y se envía al servidor solamente aquellas propiedades que hayan cambiado, este proceso ocurre recursivamente cuando las propiedades son colecciones.

El framework también se ocupa de gestionar las llaves primarias de las entidades, al hacer persistente una nueva entidad se devuelve la misma entidad con el valor correspondiente de su llave primaria inyectada.

Si tenemos propiedades en nuestra entidad en el servidor que no deseamos que lleguen al cliente o que no sean modificadas en éste, anotamos las mismas usando anotaciones propias del framework.
En el servidor podemos interceptar todas las operaciones iniciadas en el cliente y controlar el valor de las propiedades de las entidades involucradas en las operaciones.

Pimento Data Services se compone de dos partes, una se incluye en el cliente y otra en el servidor. La parte que se incluye en el servidor utiliza Spring para inyectar dependencias en todas las clases que reciben las entidades enviadas por el cliente. La parte correspondiente en el cliente incluye librerías que se añaden al proyecto.

El framework ofrece dos modelos de programación para trabajar con entidades persistentes: uno utilizando la clase EntityManager de AS3 y otro utilizando servicios personalizados, cada uno tiene sus ventajas y desventajas. El modelo más simple es el que utiliza el EntityManager de AS3, con este modelo creamos las entidades y le incluimos las anotaciones propias de JPA, luego añadimos la anotación “@Managed” a aquellas entidades que queremos que sean gestionadas por Pimento, se crean las clases AS3 equivalentes a las entidades gestionadas, se inicializa el cliente y se invocan las operaciones CRUD, opcionalmente se pueden crear interceptores.

Los servicios personalizados por su parte son equivalente a las capa de servicios que mencionábamos anteriormente, son clases Java gestionadas por Spring y que se exponen al cliente para que sean invocadas remotamente. El framework incluye tareas ant para generar los “proxies” de esas clases en el cliente.

Desde el punto de vista de flexibilidad los servicios personalizados son más convenientes si planeamos que nuestra aplicación tenga múltiples clientes (Web, de escritorio, Web Service, etc.), pero si el único cliente es Flex entonces la solución más simple es usar el EntityManager de AS3, en este caso solamente tenemos que crear en el servidor las entidades con sus anotaciones correspondientes.
El framework se soporta sobre Cinnamon Remoting, una aplicación JEE que implementa el protocolo AMF3, como BlazeDS, pero a diferencia de éste no soporta mensajería, por lo que se hace un poco complejo implementar la sincronización de datos.

En este artículo veremos a través de un ejemplo como ejecutar operaciones CRUD desde Flex con Pimento Data Services utiizando el EntityManager de AS3. En artículos futuros veremos la funcionalidad de “lazy loading” y los servicios personalizados.

El ejemplo

En el ejemplo que desarrollaremos partimos del hecho que queremos gestionar una entidad denominada User y contamos con un servidor de bases de datos MySQL.

Luego de descargar el framework desde aquí lo primero que haremos será crear la aplicación JEE que utilice Cinnamon y donde crearemos las entidades. Para esto creamos un proyecto de tipo “Dynamic Web Project” con las siguientes características:

• Nombre del proyecto: PimentoServer
• 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 “PimentoServer/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” y “pimento-core”. Necesitamos copiar también el paquete “javassist”, este lo podemos encontrar en la distribución de Spring con dependencias.

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í:

A continuación crearemos la entidad que vamos a gestionar desde el cliente:

Aquí la única anotación propia de Pimento es “@Managed”, que indica que la entidad será gestionada por el framework, o sea, será incluida en el “cache” del cliente cuando sea cargada, su llave primaria será inyectada al hacer persistente una instancia de la clase, se enviarán solamente las propiedades que cambien al realizar una operación “merge” y su estado podrá ser gestionado a través del EntityManager.

Desplegamos la aplicación en Tomcat y arrancamos el servicio, pero antes creamos la base de datos según quedó configurada en el archivo “db.properties”. Al iniciar la aplicación se creará la tabla que representa la entidad en la base de datos. Llenamos esta tabla con información inicial para poder efectuar la autenticación en la UI.

Esto es todo lo que haremos en el servidor, a continuación crearemos la UI.

Creamos un proyecto Flex con las siguientes características:

• Nombre del proyecto: PimentoClient
• 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 PimentoServer que creamos anteriormente.

La interface de usuario contiene un ViewStack con dos elementos, en uno pondremos un panel de autenticación:

Al introducir un nombre de usuario y contraseña válidos pasaremos al segundo elemento del View Stack, en el cual se realizará la gestión de la entidad:

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.

Luego procedemos a crear el equivalente AS3 de la entidad creada en java:

Como podemos ver, no se incluye el metadata “RemoteClass”, que normalmente utilizamos para indicar la clase equivalente a ésta en el servidor, Pimento y Cinnamon se encargan de registrar la clase y realizar todo el proceso de serialización/deserialización entre AS3 y Java de las instancias cuando viajan de cliente a servidor y viceversa.

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 queda así:

El contenido del archivo “config.xml” que se encuentra en la carpeta “src/config” del proyecto Flex es el siguiente:

Cuando el usuario introduzca un nombre de usuario y contraseña válidos se ejecutará el comando que realiza la autenticación, que es éste:

Como vemos en el método “execute”, el modo de uso de la clase EntityManager de Pimento es muy similar a su homóloga de JPA, pero con la característica distintiva que las operaciones de persistencia son asincrónicas, de ahí que debamos registrar manejadores para obtener los resultados y los posibles errores.

De forma similar el código para realizar las operaciones CRUD queda así:

Adicionar

Modificar

Eliminar

Listar

El código fuente de los proyectos del servidor y el cliente se puede descargar de aquí.

Conclusiones

Hemos visto el modelo de programación más simple de Pimento Data Services, este modelo nos permite trasladar al cliente la lógica de la capa de servicios e invocar directamente desde éste las operaciones de persistencia de JPA en el servidor. Hemos dejado fuera las funcionalidades del “lazy loading” y los servicios personalizados, que serán tratados en artículos futuros.

En este post veremos dos de los nuevos componentes que nos trae esta release de Hero, Spark Form y Spark Formatters.

El Spark Form

Mantiene la funcionalidad del MX Form y añade mejoras para adaptarse a diseños más modernos, debido a que es totalmente customizable por ser un SkinnableContainer con estados visuals asociados. Su costumización se hace en la skin del componente.

La mejora más importante de este componente respecto a su predecesor es la madurez de su layout. El Spark Form usa restricciones basadas en un grid para posicionar cada FormItem. Además, el layout nos permite tratar las filas y columnas de forma más dinámica: las columnas y filas pueden incrementar o decrementar su amaño en tiempo de ejecución para adaptarse al contenido de la información y los errores de texto de ayuda o de validación, se pueden mostrar bajo demanda. Spark Form viene con dos layouts: por defecto el horizontal y también el llamado stacked, que distribuye los elementos verticalmente. En las imágenes vemos estos dos tipos de layout:

Clases relacionadas con el componente
Tenemos unas clases que se relacionan con el Spark Form y debemos tener en cuenta:

• Form – el componente SkinnableContainer que define el Form propiamente dicho
• FormItem – SkinnableContainer que define cada uno de los form items del form
• FormHeading – Sección de texto que nos denota el inicio de una sección en el formulario
• FormLayout – layout asociado al Form
• FormItemLayout – restricción basada en distribución tabular para posicionar cada FormItem
• FormSkin – la skin por defecto del Form
• FormItemSkin – la skin por defecto del FormItem con layout horizontal
• StackedFormItemSkin – la skin por defecto del FormItem con layout vertical
• FormHeadingSkin – la skin del FormHeading

Aspectos importantes de la clase FormItemLayout
FormItemLayout extiende a ConstraintLayout, una clase equivalente a las restricciones del mx Canvas. FormItemLayout usa los métodos internos getMeasuredColumnWidths y setLayoutColumnWidths para alinear las columnas de los FormItem. En este momento ConstraintLayout soporta las siguientes restricciones: left, right, top, bottom y baseline.

El comportamiento general de ConstraintLayout es el de un grid para definir el layout en regiones. Los elementos que constituyen el Layout se pueden alinear con las filas y columnas usando restricciones. También es possible hacer que los elementos del Layout se expandan a través de multiples filas y columnas para dar un major comportamiento y flexibilidad del posicionamiento.

ConstraintColumns y ConstraintRows

Las regiones dentro de un ConstraintLayout se definen con instancias de ConstraintColumn y ConstraintRow definidas dentro de dos propiedades de tipo vector, llamdas constraintColumns y constraintRows respectivamente. Cada ConstraintColumn y ConstraintRow puede tener o no un tamaño definido a nivel de píxel. Una columna de tamaño fijo no cambiará de tamaño aunque su contenido lo haga. Si un componente se expande a través de diferentes columnas, el espacio se distribuirá a través de las columnas. Se prevé que ConstraintColumn y ConstraintRow permitan determinar el tamaño porcentualmente en futuras releases.

Restricciones
Ya hemos comentado las restricciones que se pueden determinar. Cada elemento puede especificar restricciones respecto al contenedor principal, por ejemplo (left=”5″) , o respecto a una columna o fila, por ejemplo (left=”col1:5″).
Las restricciones left, right, top, and bottom, definen las fronteras del elemento respecto a la región o container. La restricción de baseline define el desplazamiento entre la línea de base definida por la fila que establece la restricción y la posición del elemento.

Estados del elemento FormItem
Los estados que nos define el elemento FormItem son: normal, disabled, required, requiredAndDisabled y requiredAndError.
El estado de error se da cuando el contenido del FormItem tiene valor INVALID (fallo de la validación). El estado required ocurre cuando el FormItem se especifica como requerido.

Error Handling en la validación
Un FormItem está pendiente de los eventos FlexEvent.VALID y FlexEvent.INVALID de los elementos que contiene. La propiedad elementErrorStrings contiene un Vector de errorStrings sobre los elementos del FormItem.

Para ver más:
Especificación
Video

Spark Formatters

Flash Player 10.1 lleva implícito un Nuevo conjunto de APIs para tratar la globalización de los datos, como el formateo de fechas, horas, números o monedas. Hero, usando estas APIs ha desarrollado los nuevos Spark Formatters. Estos formatean los datos basados en la configuración regional definida por el sistema operativo.
Esta versión de Hero nos proporciona 3 formatters para tartar la información correctamente: CurrencyFormatter, NumberFormatter y DateTimeFormatter:

Otro aspecto importante son las nuevas clases de Sort y SortField añadidas para tratar el comportamiento específico para ordenar los datos según la configuración regional. La nueva clase de Sort aprovecha el tratamiento de la configuración regional específica que trae Flash Player 10.1 para comparar strings, parsear números y monedas para ordenar debidamante.

Conceptos importantes

Para entender bien los nuevos formatters debemos tener en cuenta estos conceptos:

• flash.globalization: es el nuevo package añadido a Flash player 10 para acceder a las configuraciones locales que proporciona el SO en el que se está ejecutando el Flash player. Proporciona la siguiente funcionalidad:
  - Formateo de fechas, horas, numeros y monedas según la configuración regional.
  - Parseo de numeros y monedas según la configuración regional.
  - Comparación de strings según la configuración regional.
  - Conversion de strings a mayúsculas o minúsculas según la configuración regional.
  - Proceso y parseo del Locale ID.
• Locale data: los datos necesarios par poder tratar cada tipo de datos según las convenciones culturales de la región.
• Locale: se refiere al lenguaje, la escritura, y la región para los cuales el SO tiene un conjunto de reglas para tratar correctamente los datos.
• Locale ID: nos permite identificar el locale. Por ejemplo en_US o es_ES.
• Collation Order: Los datos se suelen ordenar alfabéticamente. Para ello ActionScript usa una comparación de los códigos Unicode. Otros idiomas utilizan otras maneras de ordenación. De aquí que se necesita otra forma de ordenacion.

Comparación entre MX formatters y Spark formatters
Una diferencia importante es el uso que hacen los Spark formatters del package flash.globalization para mejorar su funcionalidad. Los MX formatters usan el ResourceManager de Flex para acceder a la configuración regional y usar los datos adecuados.
Como consecuencia, los Spark formatters proporcionan un comportamiento adecuado al sistema operativo y tienen acceso a todas la localizaciones que este soporta, aunque este comportamiento puede variar según la plataforma en que se use. Por otro lado, los MX formatters tienen el mismo comportamiento en relación a los SO, pero limitados a los “locales” proporcionados por el developer.
Más información en:

Especificación
Video