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

¿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.

Flash Builder ha vuelto a evolucionar con esta release llamada “Burrito”. “Burrito” no está completo, esta es su primera release, pero en ella podremos experiementar algunas de sus nuevas características y mejoras y el soporte sobre el nuevo Flex SDK “Hero”, el cual también es una preview release.

Desarrollo de aplicaciones mobile y multi-screen

Flash Builder “Burrito” nos ofrece un completo soporte para el desarrollo, testeo y despliegue de aplicaciones mobile AIR usando el nuevo SDK de Flex (Hero) o ActionScript.
Podemos crear proyectos mobile hechos en Flex o ActionScript y empaquetarlos para diferentes plataformas móviles. De momento sólo para Android, pero en las siguientes versiones se soportarán Apple iOS y BlackBerry Tablet OS.

Mejoras en la productividad

Plantillas de código

Las plantillas de código nos permiten insertar patrones de códig frecuentemente usados (Ctrl + Space en windows o Cmd + Space en mac). Tenemos plantillas de código para ActionScript y también para mxml. Podemos definir las nuestras y también importarlas o exportarlas:

Asistente de plantilla de código para ActionScript:

Asistente de plantilla de código para MXML:

Estas plantillas de código se pueden editar en Preferences > Flash Builder > Editors > Code Templates > ActionScript/CSS/MXML.

Completado de tags Metadata

Los diferentes tag Metadata se muestran cuando escribimos en carácter ‘[‘ a una clase, método o declaración de variable. Nos aparece la lista de tags válidos:

Si el tag metadata tiene propiedades, como puede ser el nombre del evento en el tag metadata Event, podemos usar el asistente de contenido para rellenar esta información:

Un aspecto interesante es que “Burrito” soporta tags metadata de librerías SWC third party, pero se require poner el fichero metadata.xml en ellas.

Sobreescritura e implementación de métodos

A menudo necesitamos sobreescribir o implementar métodos de una super clase o de una interface. “Burrito” nos ofrece un nuevo menu contextual para facilitarnos esta tarea:

Este asistente nos permitirá determinar que sobreescribir o implimentar:

Ayuda rápida

La ayuda rápida nos facilita aún más la codificación. Aquí vemos un ejemplo de esta ayuda:

Según el ámbito en el que la invoquemos tendremos unas opciones u otras. Éstas son las posibles:

• Renombrar en el fichero actual, permite renombrar variables, métodos, clases o parámetros en el fichero actual.
• Renombrar en el workspace.
• Convertir una variable variable local en un campo de la clase en la que nos encontramos.
• Asignación a una variable, crea una nueva variable para asignarle la expresión que hayamos introducido.
• Separación de la declaración de la variable, para separar la declaración de la asignación.
• Generar getters y setters.
• Organizar imports.

Generación de código

“Burrito” nos permite crear elementos en el código que aún no existen. Podemos generar:

• Variables, al escribir el nombre de la variable podemos invocar su creación.
• Métodos, parecido al anterior pero con métodos:



• Clases e interfaces:



• Event handlers:

Un flujo de trabajo mejorado entre diseñador y desarrollador

Mediante Flash Builder 4 y Flash Catalyst CS5 los diseñadores y desarrolladores pueden colaborar en el desarrollo de proyectos Flex.
Flash Catalyst también ha sido mejorado en la nueva versión llamada “Panini”. Estas mejoras están muy centradas a cerrar el ciclo de interacción con Flash Builder 4. Ahora tenemos bidireccionalidad de movimiento entre estas dos herramientas, como podemos ver en la siguiente imagen, cosa que no pasaba en las versiones anteriores.

Ahora Flash Catalyst permite generación de código y soporta la creación de interfaces redimensionables.
Para permitir las nuevas funcionalidades en el nuevo Flash Catalyst “Panini”, se han tenido que añadir nuevas características a Flash Builder “Burrito”:
El desarrollador debe tener en cuenta al trabajar con un diseñador la compatibilidad de ciertas características en Flash Catalyst; para eso hay configuraciones a nivel de protecto para hacerlo compatible con Flash Catalyst. Flash Builder nos permite marcar un proyecto como compatible con Flash Catalyst, esto hará que aparezcan advertencias si ciertos componentes, atributos o configuraciones del proyecto pueden ser problemáticos al importar el proyecto en Flash Catalyst.
Flash Catalyst permite convertir artwork a skins de componentes con custom skinnable components definidos por el developer. Flash Builder proporciona un asistente para poder generar las clases ActionScript, especificar los skin states, skin parts y la lógica de negocio del componente.

Actualización del soporte a la plataforma y rendimiento mejorado

Esta versión de Flash Builder está corriendo sobre la última versión de Eclipse (3.6 “Helios”). En Mac OS X Flash Builder usa la versión “Cocoa” de Eclipse no da soporte a la anterior versión “Carbon”.
Flash Builder ahora incluye las últimas versiones de las tecnologías de Adobe: incluye el SDK Flex “Hero”, Adobe AIR 2.5 y Flash Player 10.1.

Otro ámbito en el que se ha mejorado es en el instalador de Flash Builder. Ya no tenemos descargas separadas para la versión plug-in o la standalone. Después de la instalación de la versión standalone, podemos usar una herramienta que se encuentra en el directorio de utilities, dentro del directorio de instalación de “Burrito” para configurar si Flash Builder debe trabajar con una o más versiones de Eclipse.

También se ha mejorado el rendimiento y el uso de memoria, reduciendo hasta un 65% ciertas operaciones pesadas para conseguir un entorno más productivo. Se esperan realizar más reformas en estos aspectos que se verán aplicados en la final release.

Más información en:

AdobeTV

Adobe ha anunciado que están trabajando en una nueva versión de Flash Builder llamada “Burrito”. En esta versión quieren da más potencia al IDE y que los developers ganen más productividad.

Aquí os dejo el enlace.

Con este post comenzamos una serie de recomendaciones, tips y tutoriales enfocados a cubrir aquellos temas básicos de la tecnología Flex que esperamos sean de utilidad para los entusiastas de la plataforma.

Uno de los primeros tips que es importante conocer cuando hacemos aplicaciones con Flex utilizando Flex/Flash Builder es el manejo de los archivos de salida. De forma automática cuando generamos un proyecto nuevo con la herramienta se crean varias carpetas: bin-debug, html-template, src y libs.

Es común encontrar por la red aplicaciones Flex de desarrolladores que al compilar sus proyectos por descuido o desconocimiento suben las aplicaciones SWF generadas en la carpeta bin-debug, esta versión contiene información adicional que es utilizada cuando utilizamos el comando debug de la herramienta.

La forma correcta de subir nuestras aplicaciones al servidor sería aprovechando las versiones generadas a partir del comando “Export Release Build”, ya que al no incluir esa información adicional su peso es considerablemente menor que la versión de depuración.

Tomemos como ejemplo una aplicación sencilla que contiene 3 componentes: Button, TextInput y DataGrid. Al compilar estar aplicación el SWF generado en la carpeta bin-debug tiene un peso de 449 kb.

Ahora ejecutemos el comando Project > Export Release Build, el tamaño de la aplicación generada es de tan solo 276 kb, siendo el ancho de banda uno de los recursos más preciados en las aplicaciones de Internet es importante tener cuidado con estos pequeños detalles.

Hace tiempo en algún taller de Flex recuerdo que utilicé el hashtag #flex101 para hablar de los fundamentos de la tecnología, por lo que los invito a compartir sus mejores tips en Twitter a la cuenta de @madeinflex no duden que en una entrada posterior merecerá que hagamos una compilación de los mejores.

La metadata, conocida en otros lenguajes como anotaciones, es una potente herramienta para comunicarse con Flex Builder que permite realizar un abanico de tareas que van desde la generación de código hasta chequeos especiales en tiempo de compilación pasando por integración con el sistema de autocompletado del IDE.
En esta entrada veremos el funcionamiento de la anotación PercentProxy, con la cual podemos definir parámetros en unidades numéricas o porcentuales.

Sintaxis

[PercentProxy("propiedadPorcentual")]
Argumentos:

• propiedadPorcentual (obligatorio) es la versión de cálculo porcentual del getter/setter al que afecta.

Posicionamiento

Esta anotación debe situarse antes de la declaración de un getter/setter de tipo numérico.

Descripción

Este tag de metadata (indocumentado) es la solución a la falta de sobrecarga de métodos en el lenguaje ActionScript 3. Cuando el compilador se encuentra una declaración porcentual en MXML para un valor que debería ser numérico y la propiedad está marcada con la anotación [PercentProxy] internamente se crea la lógica necesaria para que la asignación apunte al setter que le toca.

Ejemplo

TestPercentProxy.mxml

DataGridColumnPorcentualSize.as

La clase DatGridColumn que viene en el SDK de Flex no permite asignar los anchos de las columnas porcentualmente (por buenas razones). Para ilustrar el uso de la anotación en cuestión se puede ver en la clase DataGridColumnPorcentualSize la lógica añadida para que se soporte este tipo de asignación.

La metadata, conocida en otros lenguajes como anotaciones, es una potente herramienta para comunicarse con Flex Builder que permite realizar un abanico de tareas que van desde la generación de código hasta chequeos especiales en tiempo de compilación pasando por integración con el sistema de autocompletado del IDE.
En esta entrada veremos el funcionamiento de la anotación ArrayElementType, con la cual podemos definir Arrays tipados en MXML.

Sintaxis

[ArrayElementType("elementType")]
Argumentos:

• elementType (obligatorio) es un nombre de clase completo. ej: com.madeinflex.Usuario

Posicionamiento

Esta anotación debe situarse antes de la declaración de una variable de tipo Array.

Descripción

La anotación en cuestión permite definir el tipo de dato de los elementos que son aceptados en un Array.
Esta funcionalidad solo está disponible en Flex Builder en tiempo de compilación y cuando declaramos dicho Array mediante MXML.

Ejemplo

Ejemplo.mxml

com/madeinflex/Usuario.as

ListaUsuarios.mxml

Si modificamos Ejemplo.mxml y añadimos un elemento de cualquier tipo que no sea Usuario, por ejemplo un String, obtendremos un error diciendo algo como: "In initializer for usuarios': type String not assignable to target Array element type":

Conclusión

Es un buen ejemplo de integración con Flex Builder a través de metadata pero la funcionalidad en si realmente no es demasiado útil ya que solo funciona para código MXML y en tiempo de compilación.
Nota: Si se requiere tener Arrays tipados en tiempo de ejecución ver la clase __AS3__.vec.Vector disponible a partir de Flash Player 10.

Como ya sabíamos, Adobe ofrecía una copia de Flex Builder gratuita a cualquier estudiante que pudiera demostrar esto, presentando normalmente algún documento escaneado que nos identifique como tal.

Pues ahora, y ya que el temporal económico aprieta, Adobe ha tenido la genial idea de ofrecer esto mismo, una copia de Adobe Flex Builder gratuita, a todo el que se haya quedado sin trabajo, eso si, tanto en el primer como en el segundo caso no podremos usar esta con propósitos comerciales, no podía ser todo.

Al menos no todo son malas noticias. No quedará desarrollador desempleado sin Flex Builder.

Os dejo el link del post original de The Flash Blog de Lee Brimelow.

A por ella, un saludo a todos

La gente de Farata Systems ha liberado su framework "Clear Toolkit framework" para desarrollo de enterprise RIAs con Flex y Java. El framework está disponible en sourceforge bajo licencia MIT.
Clear Toolkit framework dispone de varios componentes:

• Clear Data Builder: plugin de Eclipse para generación de aplicaciones CRUD para BlazeDS o LCDS a partir de sentencias SQL o Java DTOs
• DTO2Fx: generador de clases ActionScript a partir de sus homólogas en Java
• Log4Fx: plugin de Eclipse para la API de logging de Flex. Automatiza y hace el proceso de logging más amigable
• Fx2Ant: generador de ANT build scripts optimizados para proyectos de Flex Builder
• clear.swc: Librería avanzada de componentes Flex situada en el paquete com.farata.components

Además de lo mencionado puedes ver el roadmap para la version 4 aquí.
Algunos enlaces relacionados:

• Clear Toolkit framework
• Introducing Enhanced Flex Components from Clear Toolkit Framework
• Clear Data Builder: data synchronization in a multi-user environment

Queridos compañeros:

La nueva release de Adobe AIR está en las calles.
Si bien es cierto que esta actualización no representa una gran mejora en lo que respecta a nuevas funcionalidades, si que soluciona una buena lista de bugs , con los que estoy seguro mas de uno os habéis encontrado alguna vez.

Destacaría entre ellos:

-Mejora de uso de memoria en reproducción de video

-Evitar que nuestra aplicación falle y se nos cierre por tener activado el AdBlock de Safari en ciertas peticiones.

-Errores desinstalando AIR Apps (este último no me importaba   ) , entre otros..

Esta nueva versión es la 1.5.1, y para los que tenéis aplicaciones desarrolladas en AIR, como sabéis, debéis actualizar vuestro descriptor de aplicación a la versión 1.5.1 para poder usar la nueva API introducida, InvokeEvent.reason, muy útil en mi opinión ya que nos permite conocer, no solo cuando ha sido lanzada nuestra aplicación, sino desde donde (login o standard).
Para disfrutar de las demás mejoras no es necesario actualizar la versión en vuestro descriptor.
Así pues, a seguir desarrollando mas y mejor.

Un saludo a todos.