Un año después de que Flash Builder 4 y el SDK Flex 4 fueron liberados, las nuevas versiones Flash Builder 4.5 y el SDK Flex  4.5 ya están disponibles. El enfoque principal de ambos es la posibilidad de construir aplicaciones móviles enfocadas hacia los sistemas operativos Google Android, Blackberry Tablet OS, y iOS de Apple. Además, el SDK Flex 4.5 introduce nuevos componentes Spark y mejoras para el desarrollo de aplicaciones a gran escala mientras que Flash Builder 4.5 introduce docenas de características productivas para la codificación y un desarrollo más rápido con ActionScript y MXML.

AIR para móviles

Para aprender más acerca de las mejoras en el SDK Flex 4.5, recomendamos el artículo de Deepa Subramaniam. Y para aprender más acerca de lo nuevo en Flash Builder 4.5, incluyendo las nuevas características orientadas al desarrollador así como a los nuevos flujos de trabajo con Flash Catalyst CS5.5, revisa el artículo de Andrew Shorten. Si quieres aprendes específicamente acerca de las nuevas capacidades móviles en ambos Flex 4.5 y Flash Builder 4.5, lee el artículo de Narciso Jaramillo.

Este artículo trata acerca de cómo construir aplicaciones orientadas al desarrollo web y móvil. Habla acerca de tres aplicaciones de referencia desarrolladas con el SDK Flex 4.5 y Flash Builder 4.5 donde cada aplicación corre en el explorador como una aplicación web tradicional así como también en los dispositivos móviles. Estas tres aplicaciones son Shopping Cart, Expense Tracker y Sales Dashboard. El artículo cubrirá las consideraciones específicas en la construcción de una aplicación Flex para web y dispositivos móviles. Además, muestra la arquitectura de las aplicaciones  para compartir código entre los proyectos web y móvil. Y finalmente, hablaremos acerca de las consideraciones de rendimiento sobre las cuales hay que pensar cuando se construyen aplicaciones para todos los factores de forma (dispositivos, sistemas operativos y resoluciones).

Creando un Nuevo Proyecto Flex Móvil

Todos los tipos de proyectos que están disponibles en Flash Builder 4 son soportados, Flash Builder 4.5 introduce tipos de proyectos Flex adicionales incluyendo los proyectos  Flex móvil y ActionScript móvil. Estos proyectos móviles están en sintonía con el desarrollo de aplicaciones móviles. Los proyectos móviles Flex entienden el “seguro” Flex móvil que se puede usar en dispositivos móviles. Ademas, Flash Builder 4.5 te ayuda cuando creas un nuevo proyecto móvil, sin considerar si este es un proyecto Flex o ActionScript.

Para crear un nuevo proyecto Flex móvil ve a File > New > Flex Mobile Project. Veras que Flash Builder te ayuda paso a paso cuando creas y configuras un nuevo proyecto móvil, incluyendo su nombre y el tipo de aplicación móvil que quieres construir. Las aplicaciones móviles Shopping Cart, Expense Tracker y Sales Dashboard usan el tipo de aplicación basado en vistas. Esto significa que cada vista de la aplicación está gobernada por su propia clase vista y todas las vistas están controladas por un ViewNavigatorApplication.

Flash Builder 4.5 te ayudara a crear sub vistas para tus aplicaciones basadas en vistas. Puedes entonces agregarlas en vistas subsecuentes de tu aplicación. Cada sub vista deriva de la clase spark.components.View. Las vistas comprenden como visualizar los datos e inyectar información dentro de la Action Bar. Una Action Bar es la UI de navegación colocada hasta arriba de cada aplicación. Esto permite información contextual acerca de la vista actual, incluyendo el titulo de la vista actual y los botones de acción que puede navegar el usuario hacia lugares particulares dentro de la aplicación.

El proyecto móvil Shopping Cart organiza todos los hijos de estas vistas en el paquete  com.adobe.mobileshoppingcart.view.Ahi puedes ver las clases MXML que crean la UI para cada vista subsecuente en la aplicación móvil Shopping Cart. Por ejemplo, CartView.mxml es la vista que muestra los elementos que el usuario ha escogido para su compra o itemDetailsView es la vista de detalle individual para cada elemento.

Arquitectura para maximizar la reutilización de código a través de múltiples pantallas

Flash Builder 4.5 te da todos los flujos de trabajo que necesitas al desarrollar aplicaciones para una gran variedad de objetivos, incluyendo web para él  su implementación con Adobe Flash Player, o de escritorio o para dispositivos móviles para su implementación con Adobe AIR. Para nuestro equipo, hemos decidido usar una arquitectura de aplicación en la construcción de las versiones web y móvil de las aplicaciones Shopping Cart, Expense Tracker y Sales Dashboard. Esta arquitectura de aplicación trabaja muy bien con expresiones para organizar el código a través del equipo de desarrollo así como mantener el código de la UI separado de la capa del código de servicio. Además, esta arquitectura permite compartir código entre nuestros proyectos web y móvil. (Nota: no es necesario usar una estructura de aplicación para compartir código entre proyectos web y móviles, pero en nuestro caso con un equipo de desarrollo distribuido, una arquitectura de aplicación resulto beneficiosa).

La arquitectura que escogimos esta ligeramente basada en la arquitectura clásica Modelo Vista Presentador (MVP). MVP usa vistas pasivas y toma ventaja de un controlador formal para pasar estados e información UI a través de vistas. Pero mantiene todo el código lógico fuera de los archivos de las vistas, fuimos capaces de reusar el código del núcleo de la aplicación en múltiples proyectos.

FXP’s contra FXPL’s

El código del núcleo de la aplicación que será compartido entre múltiples proyectos, en nuestro caso entre el proyecto web y el proyecto móvil, está contenido en un proyecto de librería de Flex (Flex Library Project, FXPL). Por ejemplo, MobileShoppingCart.fxp y ShoppingCartWeb.fxp se enlazan con ShoppingCartLib.fxpl. ShoppingCartLib.fxpl contiene todo este código relevante compartido entre las versiones web y móvil, incluyendo la capa de servicio y las clases de utilidad. Similarmente, DashboardMobile.fxp y DashboardWeb.fxp están enlazados a DashboardLib.fxpl y a DashboardChartLib.fxpl. Estos FXPL’s contienen el código compartido para la manipulación de los componentes de graficas y la administración de datos en las aplicaciones Sales Dashboard web y móvil. Y finalmente, CRUDMobile.fxp y CRUDWeb.fxp están enlazados con su proyecto de librería compartida, CRUCLib.fxpl.

Cuando se usa un Flex Library Project, la regla general es que los modelos de datos, controladores, servicios, eventos y clases de utilidad deban ser toda incluidos. Generalmente, el proyecto de librería no debería contener algún código específico de UI a menos que se pueda compartir dicha interfaz a través de diferentes proyectos. Esta práctica ayuda a asegurar una buena encapsulación y rehusó del código a través de diferentes plataformas, dispositivos y resoluciones.

Presentador

El presentador es el rockstar de la arquitectura de la aplicación. Cada estado funcional de la aplicación tiene una clase presentador. Las instancias de los presentadores son inyectadas dentro de los archivos vistas, o a través de la inyección de metadatos con un framework como Swiz, referencias de un modelo Singleton, o pasando el presentador a través del constructor. En la lista de proyectos debajo, las instancias de los presentadores para las clases principales están referenciados desde un modelo Singleton mientras que los presentadores de los ítem renderers son creados al vuelo en la clase controlador. Por ejemplo, la clase ítemDetailsView en MobileShoppingCart.fxp tiene una referencia a un presentador variable en la línea 36. A partir de este objeto presentador la lógica del negocio de la aplicación es referenciada por la vista. De forma similar, la lista de componentes en cada aplicación web y móvil muestra una lista de objetos presentador. La lista control en MainView.mxml en MobileShoppingCart.fxp está la lista de elementos que el usuario esta visualizando. Estos datos son objetos presentador siendo visualizados por la vista.

Todas las propiedades visualizadas por la vista a través del presentador. El presentador comunica a las vistas vía eventos. Esto es porque cada clase presentador extiende EventDispatcher. Revisa la clase ItemPresenter está contenida en el proyecto ShoppingCartLib.fxpl (com.adobe.shoppingcart.presenter). Observa como ItemPresenter extiende EventDispatcher y dispara eventos en cuanto algo ha cambiado. De esta forma, el presentador expone una API pública de métodos que las vistas pueden llamar para visualizar la UI apropiadamente.

El presentador tiene como una instancia del objeto IEventDispatcher, en este caso la instancia del controlador, que se usa para despachar eventos. Esta es la forma en que el presentador se comunica con la porción de la lógica del negocio en la aplicación. El presentador no siempre tiene una instancia del controlador, o hacer el contrato entre el presentador y el controlador.

Controlador

El controlador maneja la comunicación entre las diferentes partes de la aplicación. Las decisiones del estado de la aplicación son realizadas por el controlador. Cuando la aplicación se inicia, una instancia del controlador es creada. En el mismo proyecto revisa preinitalizeHandler en WebShoppingCart.mxml y MobileShoppingCart.mxml. Aquí es donde el controlador es creado por las versiones web y móvil de la aplicación Shopping Cart. El controlador crea instancias del objeto presentador y los almacena en el modelo. Además, el controlador pone todas las propiedades en el modelo.

El controlador además escucha por eventos desde el presentador. Cuando un presentador lanza un evento, por ejemplo, cuando cambia la pantalla actual, es el controlador el que manipula el evento. El controlador entonces hace una decisión lógica acerca de cómo debe ser manejado. El controlador puede hacer un llamado dentro de la capa de servicio o poner propiedades directamente en los presentadores.

Las propiedades que deben mantenerse en sincronización a través de varios presentadores a veces se almacenan en el modelo, pero la mayor parte de cada presentador tiene su propio estado y propiedades. No hay razón para no tener modelos con estados y propiedades en los presentadores como MVP dicta, sin embargo en nuestra experiencia, este solo agrega una capara extra de complejidad sin muchas ganancias.

En ocasiones encontramos la necesidad de un comportamiento controlador para ser diferente en función de la meta del proyecto. En estos casos, extendemos el controlador y sobre escribimos los métodos que necesitan una implementación personalizada. Este controlador extendía la clase que nosotros instanciamos durante la inicialización principal para un tipo de proyecto específico.

Vista

El código de las vistas a veces no es compartido a través de proyectos. Alternativamente, el proyecto Flex móvil contiene la UI específica móvil y el proyecto Flex contiene la UI no específica para móvil. De esta forma, la interfaz de usuario esta afinada por el factor de forma especifico sobre el cual se está ejecutando la aplicación.

Crear un nuevo proyecto Flex o ActionScript para cada una de las pantallas que necesitan soportar la aplicación. Pantallas similares, como las teléfonos móviles y las tabletas, pueden ser capases de usar el mismo proyecto en función de las necesidades de tu aplicación, aunque Flex tiene soporte para la creación de la UI específicamente para smartphones en comparación con las tabletas.

El código específico de la UI (Archivos MXMl, CSS, Assets como imágenes y fuentes) debería ser creado en cada uno de los proyectos. Mientras mucho del código de la vista es creado específicamente por el factor de forma al cual va dirigido el proyecto, todo el código del núcleo de la aplicación puede ser compartido. Cada una de las vistas que puedes crear en tus proyectos podrá comunicarse con el resto de la aplicación a través del presentador. Dado que ningún código de la lógica se mantiene en las vistas, hay muy poca necesidad de duplicar código en vistas a través de proyectos. En su lugar, puedes simplemente  enlazar las propiedades en el presentador y hacer llamadas de métodos en el presentador como respuesta a los gestos del usuario.

Modelo

El modelo es usado para almacenar las instancias de los presentadores. Las instancias de los presentadores son referenciadas desde ambos, el controlador y las vistas. El modelo tiene instancias de los presentadores así que ambos el controlador y la vista pueden tener acceso a la misma instancia.

Las vistas nunca deberían referencias propiedades en el modelo. En lugar, las vistas deberían solo saber acerca de su presentador (y tal vez un estado de enumeración o alguna declaración así). Las referencias a los objetos del modelo directamente desde una vista rompe el patrón de encapsulación. En pocas palabras, el único contrato que una vista debería conocer es la del presentador.

Si estas usando un framework como Swiz tú puedes simplemente inyectar los presentadores dentro de tus vistas y  renunciar a ellos en el modelo. El framework Swiz crea y administra la instancia de los presentadores por ti.

Capa de Servicios

Es altamente recomendado usar servicios delegando los que son definidos por una interfaz. Esto permite un fácil intercambio de implementación de servicio diferente sin cambiar ningún otro código de la aplicación. Esto es especialmente poderoso si estas desarrollando contra la burla, o todavía sin terminar, servicios durante la etapa inicial de desarrollo de aplicaciones.

En el contexto de la arquitectura que usamos, el controlador tiene instancias del objeto servicio. El controlador hace llamados sobre el objeto del servicio y escucha por las respuestas. Usamos un AsyncToken como el contrato del servicio para escuchar estos resultados; las fallas son muy útiles en este caso.

Diseñando e Implementando tu UI de aplicación

Puedes trabajar con diseñadores para llegar a la apariencia y los patrones de interacción para la UI de tu aplicación, sin tener en cuenta si está orientada a web, escritorio o móvil. Nuestro equipo trabajo con diseñadores para diseñar cada vista, especialmente para los proyectos móviles. Nuestros diseñadores pasaron tiempo considerando como los usuarios interactuaran con el dispositivo en el que se está ejecutando la aplicación, el tamaño de la pantalla y la densidad por pulgada para una variedad de diferentes dispositivos y los paradigmas de la navegación del usuario están acostumbrados al usar dispositivos móviles. Con toda esta información, así como también las comodidades que Flex ofrece, nos permiten ser capaces de resolver un diseño que a la vez es agradable y fácil de implementar con Flex.

Trabajando con Diseñadores

El diseñador de una buena experiencia de usuario puede tomar una aplicación desde MUY BIEN a Impresionante. Una buena comunicación entre diseñadores y desarrolladores requiere un balance entre forma y función que puede resultar en una aplicación que no solo es fácil de usar sino que además luce genial y funciona genial también!  En nuestra experiencia, muchas organizaciones confunden la experiencia de usuario con el diseño visual. Con frecuencia el rol de un diseñador de experiencia de usuario esta se pasa por alto y termina siendo el diseñador visual, o el desarrollador. El diseñador de experiencia de usuario pasa tiempo analizando como se debería de interactuar con la aplicación, incluyendo la visualización y navegación de los datos en un estado de la aplicación. En nuestra experiencia, los proyectos que tienen un diseñador dedicado o un especialista enfocado a la experiencia de usuario, resultan en un mejor software.

En nuestro proyecto, todos los proyectos web tienen wireframes que fueron creados por el diseñador visual en Adobe Illustrator CS5 o Adobe Fireworks CS5. Los wireframes fueron convertidos en código funcional Flex o a través del uso de Flash Catalyst CS5.5 o por el desarrollador de Spark skins para los componentes Flex basados en wireframe proporcionados por el diseñador visual. Además, el tema Wireframe de Flash Builder trabaja muy bien al dibujar una simple UI para la aplicación en las primeras etapas. Para aprender más acerca de cómo puedes usar Flash Builder 4.5 y Flash Catalyst CS5.5 para desarrollar skins y assets para tu proyecto, revisa este articulo de Jacob Surber.

Skinning

La arquitectura de skinning introducida en Flash 4 hace la creación de vistas personalizadas algo muy muy fácil, si es para tu proyecto móvil o web.  Para aprender acerca de esta nueva arquietctura de skinning, llamada Spark, revisa este articulo.

El SDK Flex 4.5 se basa en Spark para todos los componentes móviles y su funcionalidad. Todos los componentes optimizados para su uso móvil en el SDK Flex 4.5 contienen skins móviles especiales. Por razones de rendimiento, estos skins están creados en ActionScript.  Estos skins móviles son ligeros y no tienen tantos estilos expuestos como los skins por defecto de Flex 4. Para muchos de los proyectos móviles, creamos nuevos skins en ActionScript 3 sin embargo somos capaces de usar skins de MXML en muchos lugares.

La regla general de los skins basados en MXML para proyectos Flex móviles está bien, especialmente cuando se usan escasamente. Pero si  comienzas a notar problemas de rendimiento, cambia a skins basados en ActionScript para buscar un mejor rendimiento. Para los proyectos móviles Shopping Cart, Expense Tracker y Dashboard, cuando se crean nuevos skins para componentes móviles, extendimos el skins por default de ActionScript en oposición a los skins de MXML por defecto.

Frecuentemente escribiendo código de programación en los archivos de skins es la mejor manera de traducir el diseño visual de Flex. Esto puede parecer tedioso al primero, pero después de un tiempo se convertirá en una segunda naturaleza. Esto también significa que tendrás un mejor rendimiento! En muchos casos escribiendo código en los archivos de skins resulta en un skins visualmente superior cuando se embeben assets. Incluso si no quieres usar puro ActionScript para esto, puedes usar FXG. En general, FXG es recomendado para su uso en proyectos Flex móviles. Nota como la mayoría de los skins en el proyecto móvil Shopping Cart están creados con FXG. Los skins creados de esta forma son más pequeños y fáciles de mantener a lo largo de la vida de una aplicación.

Para el arte que no puede ser fácilmente recreado via FXG, llega a ser necesario el uso de assets externos. Mientras que Flex soporta la carga y el embed de muchos tipos de assets, algunos formatos tienen a trabajar mejor que otros. Para vectores estáticos, FXG es la mejor opción. Para gráficos bitmap estáticos, archivos JPF tienden a ser más pequeños y de fácil uso. Cuando sea posible, los gráficos bitmap con transparencia deben ser recreados como un vector. Este es un buen tip de rendimiento. En general, animamos a los diseñadores a usar menos gráficos bitmap.

Creando listas rápidamente para proyectos Web y Móviles

Los controles de datos consientes son importantes y frecuentemente utilizados en los proyectos Flex. En todos los proyectos móviles, las listas son utilizadas para visualizar datos y los usuarios interactúan con listas con el fin de profundizar en la aplicación. Del mismo modo, los proyectos web usan listas y otros componentes parecidos para visualizar datos e información contextual para el usuario final.

El componente List de Spark ha sido optimizado para su uso móvil en el SDK Flex 4.5. Además, el Spark DataGrid hace su debut con el SDK Flex 4.5. En ambos casos, es importante comprender como crear ítem renderers de alto rendimiento para usarlos en los componentes y así visualizar datos. Los ítem renderer son a menudo el principal culpable de frenar la interactividad y la suavidad de las listas y componentes basados en listas. Las siguientes secciones te darán tips acerca de cómo crear ítem renderers de buen rendimiento para su uso con Spark List y Spark DataGrid.

Escribiendo rápidamente Renderers en la aplicación Web Shopping Cart

Un ítem renderer es una clase definida para visualizar datos enlazados a un componente basado en listas. Cuando recorres un Spark List, el ítem renderer es dibujado frecuentemente. Este redibujo puede a veces alentar tu aplicación. El esfuerzo dedicado a escribir eficientes e inteligentes ítem renderers mejorara en gran medida la experiencia al recorrer la lista en tu aplicación sea móvil o no.

El componente Spark List tiene la propiedad use VirtualLayout habilitada por defecto. Esto significa que los item renderers serán reusados cuando la lista sea recorrida y se requieran nuevos datos en la vista. Esto es muy útil cuando se visualizan y navegan datos a través de listas con muchos datos.

Cuando un ítem renderer es creado o reciclado, la propiedad data es puesta con el nuevo dato que necesita ser visualizado. Con el fin de administrar esta configuración de datos, necesitas sobre escribir el setter para la propiedad data. En itemPreviewListRenderer.mxml, te darás cuenta que la propiedad data esta actualmente instanciada por un objeto presentador. Cuando estableces, la propiedad de datos se presenta como un ItemPresenter  y entonces establecer la propiedad de clase presentador. Los componentes visuales, a su vez,  están vinculados a las propiedades del presentador y hacen llamadas de método al presentador. Este es un ejemplo muy poderoso de cómo son usados los presentadores al encapsular la lógica.

Escribiendo rápidamente Renderers en la aplicación móvil Shopping Cart

Cuando desarrollamos el proyecto móvil Shopping Cart, una cantidad significativa de atención fue requerida al optimizar los ítem renderers usados en cada vista que contiene un componente Spark List. La clase por defecto de ItemRenderer que te puede ser familiar por su uso en proyectos Flex web y de escritorio no es recomendada para su uso en proyectos móviles Flex. En su lugar, nuevas clases de ítem renderer son presentadas específicamente para la optimización móvil. Esto incluye LabelItemRenderer, un renderer móvil por default para mostrar una línea de texto, IconItemRenderer, un renderer por default para mostrar texto y una imagen.

La clase base que deberían usar cuando crees un ítem renderer para texto en un componente lista usado en un proyecto móvil es LabelItemRenderer. LabelItemRenderer extiende de UIComponent y tiene una huella mucho más pequeña de ItemRenderer desde que ItemRenderer extiende de Group y por lo tanto pesa más. LabelItemRenderer es el ítem renderer por default para el componente lista en los proyectos móviles de Flex. Su renderer es un simple elemento de texto que se muestra en la siguiente imagen. LabelItemRenderer hereda la propiedad labelField y muestra en el componente lista el elemento llamado label. Label es una instancia de un StyleableTextField. StyleableTextField extiende TextField y permite, como el nombre indica, mecanismos para aplicar estilos CSS al control que muestra el texto. Mientras que el texto TLF es genial para su uso en aplicaciones web o de escritorio, TextField funciona mucho mejor en escenarios móviles. TextField es especialmente útil en aplicaciones web cuando se recorren elementos pesados de texto.

Elige LabelItemRenderer para el desplazamiento de datos con mejor rendimiento. Cuando escribas tus propios ítem renderers, hereda de LabelItemRenderer. En general, copia las praticas y los principios usados en LabelItemRendererm como código de programación para la medición, la orientación y sensibilidad hacia el uso excesivo del enlace de datos.

IconItemRenderer extiende de LabelItemRenderer. Además de la visualización de texto permitido por LabelItemRenderer, IconItemRenderer permite visualizar mas elementos como:

  • Label
  • Message
  • Icon
  • Decorator
  • IconPlaceHolder

El elemento label es el mismo que en LabelItemRenderer y muestra el texto enlazado al renderer. El elemento Message muestra un secundario (y opcional) elemento de texto que también es una instancia de StyleableTextField.

El elemento Icon es una instancia del componente BitmapImage. BitmapImage ha sido aumentado en el SDK Flex 4.5 para un mejor rendimiento desde que este puede esconder el asset visual que mostrara. El elemento Icon es la imagen que aparece a la derecha del ítem renderer por default como se muestra en la imagen anterior.

El elemento decorator es también una instancia de BitmapImage. Es a menudo puesto como un icono y aparece a la izquierda del renderer por default. Se recomienda que el decorator sea puesto como una imagen asset para rendimiento optimo.

El iconPlaceholder es también una instancia de BitmapImage. Esta es la imagen que se muestra la imagen icon es cargada o si la imagen icon no se encuentra. Al igual que decorator se recomienda sea embebido para un mejor rendimiento.

Cuando necesitas personalizar un ítem renderer para una Lista móvil, tiene stre sopciones: extender UIComponente, extender LabelItemRenderer, o extender IconItemRenderer. En el proyecto móvil Shopping Cart, revisa ItemPreviewImageRenderer.as en el paquete com.adobe.mobileshoppingcart.view.renderer. Este ítem renderer extiende de IconItemRenderer y toma ventaja de los elementos existentes definidos.

Usando el Spark DataGrid

En el proyecto web Expense Tracker, usamos en Spark DataGrid que es nuevo en el SDK Flex 4.5. El Spark DataGrid tiene muchas mejoras sobre el DataGrid MX. Soporta totalmente la personalización visual a través de un contrato de skinning Spark. Además, el Spark DataGrid soporta renderer para ambos header e ítems, tiene soporte completo para funcionalidad avanzada en columnas, como redimensionamiento y filtra miento y es totalmente accesible como también editable. Puedes verlo en acción en DataGridView.mxml incluido en CRUDWeb.fxp.

Definiendo columnas para un DataGrid

El Spark DataGrid tiene una propiedad columns del tipo IList. Las columnas deben contener objetos GridColumn. En la aplicación web Expense Tracker, el usuario tiene la posibilidad de encender o apagar las columnas a través de la configuración de los controles.

En la arquitectura mencionada arroba, el presentador tiene todos los estados para las vistas, el presentador tiene la lista de columnas que están actualmente “encendidas” como visibles por el usuario. Desde que GridColumn está dentro de la categoría de un objeto de vista, GridColumn cumple con los criterios que se pondrán en  el proyecto de librería compartido CRUDLib para ser compartido con el proyecto móvil Expense Tracker.

Para evitar esto he hecho una nueva interfaz y modelo de objetos:

IGridColumnModel y GridColumnModel. IGridColumnModel es una representación única de datos de un objeto GridColumn. La clase principal presentador tiene una lista de los objetos GridColumnModel en el ArrayCollection columnList. La vista, a su vez escucha por cambios en el ArrayCollection columnList y entonces usa una clase factory personalizada para crear instancias de los objetos GridColumn. La clase factory es nombrada GridColumnFactory y tiene un método estático llamado buildGridColumn() que toma un objeto IGridColumnModel y devuelve una GridColumn. Esto permite a todas las vistas estar en el proyecto apropiado y el estado aun debe ser enlazado en el código presentador.

Asi como los otros ítem renderers, un ojo debe mantenerse eficiente cuando se crean ítem renderer de DataGrid, aquí hay unos cuantos tips acerca de cómo crear ítem renderers para DataGrid:

  • Construye algunos objetos formatter en el GridColumn en lugar de construirlos directamente en el ítem  renderer. Esto reducirá el número de objetos formatter que se necesitan crear y además, GridColumn tiene soporte nativo para aplicar formatters. Con este soporte, la propiedad label del ítem renderer será formateada por el GridColumn.
  • Los GridItemRenderer deben usar el método prepare() en lugar de poner el dato al inicializar y tratar actualizaciones.
  • No anides excesivamente los contenedores o agregues elementos innecesarios a un ítem renderer de DataGrid. Mantener la lista de visualización para cualquier ítem renderer bien formado es la clave para mejorar el desempeño.

Usando Graficas MX en proyectos web y móvil

Aunque los componentes Spark son requeridos para proyectos móviles de Flex, hay una excepción es permitir el uso de componentes de graficas MX como ColumnChart, BarChart, PieChart y más. Cuando creas un nuevo proyecto móvil en Flash Builder 4.5, los componentes de graficas ya están incluidos en la librería del proyecto así que estos componentes son inmediatamente disponibles en el code hinting y en la vista de diseño.los proyectos web y móvil de Sales Dashboard usan los componentes de graficas para mostrar información financiera. La capa de datos compartidos aso como los componentes compartidos en la UI están incluidos en DashboardChartLib.fxpl. Este es un ejemplo donde el código de la UI es compartido entre ambos proyectos a través de un simple Flex Library Project. DashboardMobile.fxp y DashboardWeb.fxp contienen todos el código de UI, aparte de los componentes de graficas, que son específicamente para los factores de forma móvil y web (como ítem renderer específicos para móviles).

A donde ir desde aquí

Este articulo apenas roza la superficie de todas las nuevas características del Adobe Flash Builder 4.5 y el SDK Flex 4.5. Esperamos que tengan sentido para ti algunas cosas que podrás hacer en esta nueva versión del framework y la herramienta, especialmente acerca de crear contenido para smartphones y tabletas. Estamos emocionados por los amigos que instalaran las tres aplicaciones para web y para móvil y que aprendan a separar el código y las mejores prácticas para escribir un muy buen código Flex!

Descargar proyectos de ejemplo:
Shopping Cart
Sales Dashboard
Expense Tracker

Este articulo esta publicado en Adobe Developer Connnetion (devnet) bajo licencia Creative Commons y traducido en este blog por Jesús Macedo