Voy a dar una charla durante el evento AdobeEnVivo que se dará online durante la semana que viene, del martes 14 al sábado 18.

La charla, que será el jueves 16 a las 16h (hora en España: 22h), intentará dar una visión clara de las cosas que se pueden hacer con AIR que no se pueden hacer con el Flash Player. Será un recorrido por las distintas APIs que caracterizan el runtime de AIR.

Finalmente puede que haya algo de reflexión de lo qué es AIR, el sentido que tiene y el lugar que ocupa en el mercado, etc….

Aparte de mi aportación, la parrilla del evento es MUY extensa y los ponentes hablarán de cosas muy variopintas, desde After Effects hasta Flex 4 pasando por Flash Lite, Catalyst, Cold Fusion, Live Cycle, etc…

El evento contará con la participación de un montón de Adobe User Group managers, co-managers, y otras personalidades de la escena Adobiana.

Si trabajas con productos de Adobe y hablas castellano seguro que encuentras una o más charlas de tu interés.

• URL acceso al evento online
• Parrilla de charlas
• Anuncio en Garage Flash

Y hablando de los talleres de verano… no está de más mencionar que ya se han abierto las inscripciones para este año que, al igual que el pasado, van a tener lugar en Alicante. Será durante los días 28, 29 y 30 de Agosto en la Villa Universitaria de Alicante a un precio inmejorable de 100 EUR.
Ahora mismo quedan 32 plazas ( yo ya he reservado la mía! ) de las 50 de las que se dispone, lo cuál no está nada mal teniendo en cuenta que solo hay una charla confirmada :)
UPDATE: ya son 2 charlas confirmadas!
Dejo aquí algunos enlaces de interés:

• Micro site talleres 2009
• Parrilla de sesiones
• Formulario de registro
• Acceso a los micro sites de otros años

Nos vemos en Alicante!

• Descarga Flash Builder 4 y Flash Catalyst
• Flex 4 “Gumbo” preview

Los objetivos que me he marcado para realizar esta implementación son básicamente dos:

• Reutilización: Crear una librería que implemente Memento de tal forma que se pueda utilizar sin tener que preocuparse de crear clases Memento concretas.
• Persistencia: Crear una capa de persistencia para que los Mementos se puedan almacenar no solo en memoria sino tambien en un SharedObject, en una base de datos, en un archivo, etc..

Estructura del proyecto de ejemplo en Flex builder:

Si comparamos la estructura del proyecto con la de la versión del primer post se pueden ver una serie de diferencias que voy a enumerar a continuación.

• ObjectSnapshot: Para empezar la interfaz IMemento ya no está y se ha sustituído por la clase ObjectSnapshot. Esta clase es la implementación maestra de un Memento. Gracias a esto ya nunca más tendremos que preocuparnos de implementar un Memento. Extendiendo de la clase flash.utils.Proxy se ha podido crear una implementación que cabe en cualquier escenario debido a la potencia que nos ofrece el hecho que es una clase dinámica (dynamic). Como los Mementos no son objetos que se requieran en escenarios de gran rendimiento ( yo no voy a más de 2 CTRL+Z por segundo.. :) ) el hecho de utilizar una clase dinámica no nos penaliza.
• IRestorable: Esta interfaz sustituye a IOriginator de la otra versión. Es básicamente lo mismo pero con otro nombre más significativo (para mi) y añadiendo par de métodos más que obligan a los implementores a disponer de un IPersistable.
• IPersistable: Interfaz que deben implementar todos los drivers que van a permitir guardar los Mementos (ObjectSnapshots) en distintos soportes. La condición que impone a los implementores es disponer de un método write() y otro read().
• carpeta persisters: Una colección de implementaciones base de IPersistable. Se puede ver que una limitación que tienen estos objetos es que las peticiones deben siempre síncronas. Igual en un post futuro esto cambia…

Los conceptos son los mismos pero he intantado adaptar la implementación para que saque más partido de las características de ActionScript 3.
Lo mejor es descargar el ejemplo y jugar un poco:

Descarga ejemplo

En el zip hay un proyecto ActionScript para Flex Builder.

El otro día se me planteó la duda de si sería posible hacer algo parecido a un gestor de descargas con AIR. Después de experimentar un poco con las APIs de network junto con un poco de investigación de cómo trabaja el protocolo HTTP internamente he sacado un prototipo de lo que podría ser el core de este hipotético gestor de descargas.
Aquí enumero las funcionalidades que se esperan de un gestor de descargas y si están implementadas en el prototipo:

• pause / resume download:

  Esta es la funcionalidad más importante y esencial de un gestor de descargas. La posibilidad de pausar / reanudar el proceso de descargan tantas veces como sea necesario.
  Esta funcionalidad si está implementada en el prototipo.

• multipart download:

  Esta funcionalidad no es esencial pero si un plus a tener en cuenta para cualquier gestor de descargas que se precie. La posibilidad de segmentar la descarga de un mismo archivo en varios hilos de tal forma que el proceso de descarga sea más rápido, hasta un 200% más rápido (existen limitaciones en la velocidad de descarga de las conexiones individuales).
  Esta funcionalidad si está implementada en el prototipo.

• Posibilidad de persistir la sesión de descarga:

  Esta funcionalidad es esencial sobretodo si se quiere descargar grandes archivos que requieren que se reanude la descarga después de cerrar la aplicación o incluso hacer un reboot del sistema operativo. También es útil en el caso de caídas de red o cuelgues de la aplicación (crash recovery).
  Esta funcionalidad no está implementada en el prototipo.

Descarga ejemplo

Descarga el código fuente del prototipo