Hemos hablado en diferentes posts de las caractarísticas de lo que será AIR 2. De momento ya tenemos disponible la beta 2 y con ésta he querido experimentar algunas de sus características. En este artículo veremos algunas de estas características mediante una aplicación de ejemplo y así probar parte de lo que nos aportará la nueva versión de AIR.

Introducción

Hemos posteado anteriormente este artículo en el que comentamos lo que nos aporta AIR 2. En la beta 2 de AIR 2, las mejoras que se recogen, a “grosso modo”, son las siguientes:

• Mejoras en el Print Job para tener un control mayor de la impresión desde AIR.
• Sockets TLS/SSL, que nos permiten conectar a servidores que requieran TLSv1 o SSLv3.
• Soporte para acceso a Flash, así podremos reproducir contenido protegido.
• Mejoras en la API IME, diseñada para usar con el nuevo Flash Text Engine (FTE).

Información, descarga e instalación de la beta 2

En el siguiente link encontrareis la página de AIR 2, con toda la información que necesiteis y explica como descargar e instalar en cualquier sistema operativo.

Probando AIR 2

Para probar algunas de las características de AIR 2, he desarrollado una aplicación que contiene un tab navigator. Cada uno de sus tabs contiene una de las posibilidades de AIR 2 analizadas. Aquí os dejo el proyecto para que lo podais probar y trastear. Descomprimidlo y tendreis el proyecto FXP para importar directamente:
AIR2Enhancements.fxp

Detección de soportes de almacenamiento y apertura con la aplicación por defecto.

Algo que encontrábamos a faltar hasta ahora en AIR era la posibilidad de acceder a dispositivos de almacenamiento. AIR 2 es capaz de detectar estos dispositivos y acceder a ellos. Para ello, debemos tener en cuenta 2 clases:

• StorageVolumeInfo: Es una clase singleton que reconoce los cambios en estos dispositivos. Cuando hay algun cambio, lanza un evento de tipo StorageVolumeChangeEvent. Podemos controlar dos tipos de eventos: storageVolumeMount y storageVolumeUnmount.
• StorageVolume: encapsula la información del dispositivo.

Con estas clases podremos ver la información que nos apetezca del dispositivo.

Por otra parte, la API de la clase File tiene un método llamado openWithDefaultApplication(), que nos permite abrir el fichero con el programa que tiene asignado por defecto el sistema operativo.

En la siguiente imagen vemos el primer tab de la aplicación que muestra los soportes de almacenamiento. Nos permite navegar por todos ellos y también podremos abrir los documentos con la aplicación por defecto:

File promises

File promises es una nueva API que nos permite acceder a ciertas URL’s y arrastrarlas fuera de la aplicación AIR para que se guarden en nuestra máquina local. La clase URLFilePromise se encarga de hacer esta operación mediante la implementación de la interface IFilePromise y usando URLStream y URLRequest.

Para crear una file promise, mediante la clase URLFilePromise, pasamos al clipboard el array de file promises deseadas. Cuando se termina el proceso de drag and drop hacia la máquina local, el runtime descarga los datos para cada file promise. A continuación vemos una imagen de ejemplo de nuestra aplicación:

Native process execution

Con esta API se nos permite interactuar con procesos nativos del sistema operativo. Para realizarlo, las siguientes clases nos dan esta capcidad:

• NativeProcess: tiene la capacidad de lanzar procesos en el sistema operativo en el que se alberga la aplicación.
• NativeProcessStartupInfo: proporciona información básica que nos servirá para lanzar un proceso en el sistema operativo.
• NativeProcessExitEvent: este evento se lanza una vez termina el proceso. Puede ser que no se lance nunca si es que estamos ejecutando un proceso contenido en la misma aplicación AIR.

Para probar esta característica y debido a que estamos usando una versión beta de AIR 2, debemos insertar este tag en el fichero descriptor de la aplicación:

He codificado la aplicación de manera que controle en qué sistema operativo nos encontramos y sólo nos deje lanzar una de las aplicaciones, la que soporte nuestro SO. Aquí va una captura para ver como se lanza una aplicación nativa:

Network interfaces

Un ordenador tiene diferentes interficies de red. Con AIR 2.0 podemos acceder a esta información mediante la clase NetworkInfo. Esta clase nos permite obtener información como por ejemplo: la IP local y las interficies de red. En la siguiente imagen vemos el resultado:

Resolución de DNS

Como sabemos, cada dominio de la red tiene una IP asociada. Un DNS hace la conversión entre los nombres de dominio y las direcciones IP.

AIR 2.0 nos proporciona una DNSResolver, la cual nos permite preguntar a DNS. Cuando se obtiene la información, se nos notifica mediante un evento de tipo DNSResolverEvent.

Una IP puede ser de tipo IPv4 (32-bits) o IPv6 (64-bits). El AIR actual sólo soporta IPv4, pero el nuevo AIR 2.0 reconoce IP’s de tipo.

Hay diferentes tipos de registros en los DNS, AIR 2.0 soporta los siguientes:

• ARecord: Esta clase nos devuleve información de direcciones de tipo 64-bits IPv6. Los registros AAAA se suelen usar para convertir hostnames en direcciones IP.
• AAAARecord: nos devuelve información sobre direcciones de tipo 32-bits IPv4.
• MXRecord: nos proporciona información sobre el mapeo del nombre de un dominio hacia una lista de intercambio de mail.
• SRVRecord: nos devuelve la información de localización de servicios sobre los registros SRV. Se utiliza para los nuevos protocolos en lugar de la creación de protocolos específicos.
• ResourceRecord: clase para encapsular la información del registro DNS.
• PTRRecord: nos permite acceder a la información de registros PTR. Los registros PTR se utilizan normalmente para la realización de consultas DNS inversas.

A continuación una muestra de una consulta que hace nuestra aplicación:

Conclusión

Hemos visto algunas de las características que nos proporcionan las betas de AIR 2.0. Hay muchísimas más características que dejo que experimenteis personalmente. Encontrareis bastante información y ejemplos por internet.
Seguiremos probando betas hasta que salga la release oficial de AIR 2.0.

El día de hoy se anunció en Adobe Labs, AIR 2 beta 2. Es importante darle un vistazo puesto que las aplicaciones compiladas con beta 1 ya no podrán ejecutarse con el runtime de AIR 2 beta 2, así mismo hay algunas características importantes en esta versión entre las que destacan…

• Interacción Mejorada con la Impresora: Nuevo soporte de impresión que permite un control más fino sobre la manera en que el contenido se imprime desde una aplicación AIR, incluyendo la elección de impresora, tamaño del papel y número de copias.
  Una nueva API que permite recuperar información adicional de la impresión, como el área a imprimir, los colores y status de actividad. También es posible mandar a imprimir sin mostrar el diálogo de imprimir.
• Soporte para comunicación de sockets TLS/SSL: Ahora es posible conectarse a un servidor que requiere comunicaciones por socket tipo TLSv1 o SSLv3.
• API IME y Mejoras en la Entrada de Texto: Interesantes mejoras para soportar la entrada de texto con software IME mediante un API diseñada para utilizar el Flash Text Engine.

También hay algunas aplicaciones de ejemplo que podemos ir descargando para revisar a detalle estas características.

Hola comunidad de madeInFlex, este es mi primer post y lo hago para presentarles un pequeño proyecto OpenSource que comencé a inicios de este año. Su nombre es codeDraw y no es más que un editor visual para crear gráficos vectoriales para aplicaciones Flash, Flex, MTASC y haXe. Con él podemos “crear MovieClips” gráficamente y luego exportar su código a una clase AS2.0/3.0 y utilizarlo en nuestros proyectos, de ahí su nombre. Está desarrollado completamente sobre Flex y AIR, por lo que, en esencia, utiliza ActionScript para generar ActionScript.

Quisiera orientar este post a exponer, de manera resumida, aspectos técnicos del mismo y así compartir algunas ideas:
codeDraw no fue desarrollado sobre ninguno de los frameworks populares de MVC para Flex (Cairngorm, Swiz, PureMVC, etc.). Puede parecer algo alocado, pero se le desarrolló uno propio bastante sencillo. De igual forma, los tradicionales son mucho más robustos y el objetivo no es recomendar hacer uno, pero si aclarar el detalle para mejor entendimiento del código de la solución.

codeDraw incorpora un pequeño núcleo para la gestión de los objetos gráficos en tiempo de ejecución. Sucede que, históricamente, los desarrolladores de ActionScript que necesitan construir gráficos utilizando los clásicos métodos “lineTo” y “curveTo”, deben crear sus propios métodos de control de la información de los trazos. De esta forma, crearlos nuevamente, con las características o posiciones actualizadas, resulta mucho más factible.

Los paneles fueron desarrollados en módulos Flex e incorporados al principal utilizando el MVC. Actualmente codeDraw cuenta con 4: herramientas de dibujo y selección, panel de propiedades, capas y filtros.

Los documentos se almacenan en unos ficheros XML de extensión (codeDraw XML).

A continuación les dejo algunos screenshots, generalmente ilustran más que muchos parrafos …  :smile:

codeDraw aún se encuentra en un estado de desarrollo bastante joven. Faltan muchos bugs por revisar, balance y énfasis en la usabilidad del mismo, pero otras prioridades me han obligado a posponer su desarrollo por un tiempo. Por lo pronto, tengo pensado concluir la documentación del código y finalmente publicarlo a todos aquellos que lo puedan necesitar o estén interesados en contribuir.

• Más información, screenshots, etc. en el Blog oficial
• Descargar codeDraw 0.5 Beta

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.

Me complace anunciar el inicio del primer concurso promovido por MadeInFlex: mifAIRContest’08.

La idea nació el 31 de Marzo en el pasado “onAIRTour Europe 2008″, desde entonces y cuando nuestro trabajo nos lo ha permitido, lo hemos estado cocinando con todo cariño para vosotros y… no creáis que lleva pocos ingredientes y sí muchos los cocineros que han intervenido.

Para hacerlo aún más jugoso hemos hecho coincidir la entrega de premios en el tercer MIF OnSite, esta vez tendrá lugar en Madrid y os recomiendo no perdéroslo porque las charlas preparadas van a ser magníficas.

En el siguiente enlace tenéis toda la información sobre las bases del concurso así como de los premios.

Anímate a participar, aunque no ganes ningún premio toda la comunidad Flex te lo agracederá puesto que todos los fuentes de las aplicaciones presentadas serán publicados para así poder aprender todos un poquito más.

Recordar que MIF lo hacemos entre todos y sin vuestra colaboración no sería posible realizar este tipo de concursos y eventos.

Las aplicaciones hechas con AIR tienen la peculiaridad que se instalan.
Una vez instaladas, estas aplicaciones, al igual que cualquier otra aplicación de escritorio, a menudo es necesario que modifiquen o creen archivos para mantener preferencias, configuraciones, logs, etc...
En este artículo se muestra un sistema que permite automatizar toda esta gestión acorde con los requisitos que tienen las aplicaciones de escritorio en relación al sistema operativo que las alberga.

AIR Sandboxes

En AIR disponemos de varios sandboxes:

1. Application sandbox: Es el directorio dónde se ha instalado la aplicación. Al ser un sandbox con privilegios altamente sensibles a la seguridad del sistema se restringe su uso únicamente a la aplicación en si (más info).
2. Non-application sandbox: Todo el contenido que no está dentro del Application sandbox está en este sandbox.

El Application sandbox lo pone dificil para realizar operaciones con archivos en el directorio de instalación de la aplicación AIR, de hecho es una mala práctica ya que si lo hiciéramos, por ejemplo, no tendríamos la oportunidad de mantener dichos archivos a través de las distintas releases de nuestra aplicación.
Es por esto que muchas aplicaciones utilizan una convención a nivel de sistema operativo que es guardar la información en un directorio de almacenamiento, el llamado storage directory.

Directorio de almacenamiento

El directorio de almacenamiento es el lugar idóneo para guardar toda la información generada por la aplicación. Este directorio en diferentes sistemas operativos está situado en lugares distintos, es por eso que la API de acceso al sistema de archivos de AIR nos abstrae de ello mediante diferentes sistemas:

Carpeta "firstrun"

Teniendo un directorio de almacenamiento y habiendo visto que lo tenemos disponible de forma sencilla a través de las APIs de AIR vamos a ver cómo hacer posible crear un sistema que nos permita automatizar la gestión de archivos externos a la aplicación y que además nos ofrezca la oportunidad de mantenerlos a través de las distintas versiones de nuestra aplicación. Es decir, si hago una nueva release quiero que algunos (o todos) de estos archivos se borren o modifiquen para que estén a punto para ser usados con las nuevas prestaciones que la nueva versión ofrece.

Para ello cuando diseñamos nuestra aplicación tenemos que tener en cuenta que habrá un directorio que no va a estar en el lugar de instalación de la aplicación.
Una estrategia que he tomado prestada de ver comose instala Flash es crear un directorio firstrun. Este directorio va a contener un template de archivos y directorios que en el momento de ejecutar la aplicación por primera vez se va a mover al directorio de almacenamiento.
En la aplicación de ejemplo en Flex Builder tengo esta estructura:

Como se puede ver tengo una carpeta firstrun con algo de contenido. Es este contenido el que se va a mover al storage folder.

Implementación del sistema

Ahora que tenemos todo el sistema montado la única cosa que queda es implementar la lógica que gestione el movimiento de archivos de un lado al otro de forma que nos podamos despreocupar del asunto.
Para ello vamos a servirnos de la clase com.joangarnet.air.core.BaseWindowedApplication, la cual vamos a utilizar en sustitución de mx.core.WindowedApplication. Es decir, en la raíz de nuestro archivo mxml principal vamos a tener lo siguiente:
FirstrunManagerTest.mxml

Lo que debemos tener en cuenta de esta subclase de WindowedApplication es que tiene tres parámetros de interés:

• firstrunDirectory: La ruta relativa desde la raíz del classpath de nuestra aplicación hasta la carpeta firstrun.
• firstrunCheck: Esto es un handler que se ejecuta cuando los procesos de chequeo y movimiento de archivos se han ejecutado. Normalmente nuestra aplicación empezará a partir de aquí.
• isDebug: Esto es un flag que fuerza a que siempre se sobrescriba el directorio de almacenamiento de la aplicación, lo cual es deseable cuando estamos en fase de desarrollo.

Aparte de esto cabe decir que para que se lance el proceso de sobrescritura de archivos en el directorio de almacenamiento se tienen que dar una de estas dos situaciones:

1. Que sea la primera vez que se instala la aplicación en el sistema
2. Que la versión de la aplicación sea diferente que la que hay (o hubo) instalada

En el caso 2 esto quiere decir que si sacamos una nueva versión de la aplicación tenemos que tener el cuidado de reflejarlo en el archivo descriptor de la aplicación (en este ejemplo FirstrunManagerTest-app.xml cambiando el valor del nodo <version>.
Con esto y mirando un poco los comentarios de la clase com.joangarnet.air.core.BaseWindowedApplication para adaptarla a cada caso particular (puede que la lógica que hay por defecto no sea la que tú necesitas) se puede tener un sistema de firstrun a la altura de cualquier otra aplicación.

Descarga del ejemplo

Ejemplo firstrun manager

Referencias

• AIR security
• Updating AIR applications

I'm back from 360Flex Milano. It's been a really nice time there and I've enjoyed a lot the conferences and people. It's always fantastic to share with others experiences, experiments, etc. And of course we've laught a lot! We've been having a really good time with Koen, Marco, Cyril, Giorgio, Sumi, Sakri, Matteo, Luca, Tomislav, Peter, Guy, etc...

Here are the slides I used during my preso and all sample projects.

Just wanted to thank Tom and John the hard work they've done and hope to see them next year again!

Aquellos que habéis tenido que usar el control RichTextEditor os habréis dado cuenta de lo pobre que es el soporte que da FlashPlayer al HTML y de lo difícil que se hace trabajar con html.

El componente que muestro a continuación sólo sirve para aplicaciones AIR y es una paquetización del editor FCKEditor con lo cual aporta todas sus funcionalidades y permite la edición rica de contenidos html. Aunque funcional, se trata sólo de una prueba de concepto para mostrar lo que se puede hacer.

La idea básica sobre la que reside el componente es crear una página html al vuelo cada vez que se le asigne un valor al campo html. La página html generada se renderiza en un control y cuando se quiere acceder al html que el usuario haya modificado se hace a través de DOM y de las funciones Javascript que FCKEditor expone.

Un ejemplo de uso sería:

Lo que faltaría implementar que dejo en vuestras manos sería:

• Soporte para Bindings en la propiedad html
• Soporte para las funcionalidades de ajuste de tamaño según las normas de UIComponent

Os podéis descargar el código de ejemplo así como el del componente de aquí.

Aunque no salga en la lista de prestaciones, AIR soporta de forma indirecta la transformación de XML's a través de XSLT's. El kit de la cuestión recae en el uso del componente HTML o mejor aún de HTMLLoader, teniendo en cuenta que el componente HTML es un wrapper de HTMLLoader en Flex.

El componente HTMLLoader lo que hace es delegar la interpretación y renderizado de código html en WebKit (el core de Safari). Y es este, WebKit, el que por sí mismo soporta XSLT de una forma muy sencilla.

A continuación muestro una pequeña prueba de concepto de cómo poder invocar xslt's contra xml's a través de una pequeña clase.

En el navegador, una forma de aplicar xslt a un xml directamente sería hacer lo siguiente:

1. Creamos el xml que queremos transformar (model.xml)

2. Creamos la xlst que queremos (transformacion.xsl)

3. Aplicamos la xlst al xml mediante una processing instruction del estilo <?xml-stylesheet href="transformacion.xsl" type="text/xsl" ?>

Si cargamos modelo.xml en un navegador, éste parseará el xml y le aplicará la xslt indicada en la processing instruction dando como resultado un html (que es el que visualizaremos en el navegador).

Una de las funcionalidades que no podemos olvidar de HTMLControl es que es operativo aunque no esté incluido en la displayList. Podemos crear una clase que, usando un HTMLLoader pero sin representarlo visualmente, intercepte el XML, le añada la processing instruction y que capture el html resultante.

Este sería el circuito normal. Mediante HTMLLoader.loadString podemos cargar en el componente un xhtml generado al vuelo (el que queramos concatenado con la processing instruction). El problema de esto es que por algún extraño motivo, loadString no carga la xsl de transformación. Pero sí que funciona utilizando html.load (). Para paliar este comportamiento anómalo la siguiente clase lo que hace es crear un fichero temporal (que después se elimina) y que es el que el HTMLLoader cargará.

A continuación se muestra la clase XSLTProcessor.as

Una forma de usarlo sería desde una aplicación AIR basada en Flex:

Aún y tratarse de una aplicación funcional la clase anterior es una prueba de concepto que casi no he probado. La xsl es un poco chorra, pero es la primera que he encontrado en google.

La verdad que se me ocurren bastantes circunstancias en las que una xsl puede simplificar mucho un desarrollo. No sólo tenemos que pensar en las xsls como una herramienta para la capa de presentación, también podemos usarlas para transformar, adaptar o preparar modelos de datos: por ejemplo ordenación de árboles xml, agrupación, etc.

Hasta hace un tiempo era dificil encontrar artículos sobre RIA y Flex/AIR en la blogosfera hispana, pero poco a poco se empieza a ver que la revolución RIA llega a los medios generalistas y a la base de la comunidad desarrolladora, imprescindible para que una tecnología / visión se asiente.

En este artículo sobre tendencias RIA en 2008 de Error500 se discute sobre esta revolución y la tendencia en 2008.

Aquí en MIF llevamos mucho tiempo hablando sobre la misma , y los diferentes agentes que acompañan a Flex /AIR en este ecosistema. Y a vosotros ¿Que os parece? , ¿como veis el estado del RIA en el mercado? ¿creeis que la mayoría de la empresas son sensibles a la palabra "RIA"? ¿que os parece la competencia, Silverlight, AJAX, OpenLazlo, JavaFX, etc..? ¿Para cuando el desarrollo RIA en el movil de manera extensiva y comoda?
Esperamos vuestros comentarios para enriquecer el debate. s2.