Archivo de la etiqueta: adobe

Adobe AIR III – Actualizando automáticamente las aplicaciones

Programación, R.I.A., Técnico, , ,

He aquí otra de esas cosas superchulas que vemos en aplicaciones de otros. Ejecutas una aplicación y automáticamente te dice que hay una nueva versión y si quieres actualizarla. Si aceptas, se actualiza ella sola.

Esto en AIR es extremadamente sencillo, sólo necesitaremos unas pocas líneas de código 🙂 .

La primera parte consiste en invocar la comprobación desde tu aplicación, en el evento creationComplete.

private function actualiza():void{
appUpdater.updateURL = "http://tuservidor.com/update.xml";
appUpdater.isCheckForUpdateVisible = false;
appUpdater.addEventListener(UpdateEvent.INITIALIZED, onUpdate);
appUpdater.addEventListener(ErrorEvent.ERROR, onError);
appUpdater.initialize();
}

private function onUpdate(event:UpdateEvent):void {
	appUpdater.checkNow(); // Go check for an update now
}
private function onError(event:ErrorEvent):void {
	Alert.show(event.toString());
}

La segunda es crear un xml en la ruta indicada en “updateURL” con la información de la última versión disponible y la url a la misma. Muy sencillo.

<?xml version="1.0" encoding="utf-8"?>
<update xmlns="http://ns.adobe.com/air/framework/update/description/1.0">
<version>v0.2</version>
<url>http://tuservidor.com/tuaplicacion.air</url>
<description><![CDATA[
v0,2
Aquí puedes incluir información sobre la nueva versión...
Nuevas funciones, opciones...
]]></description>
</update>

Sube el XML al servidor junto a la nueva versión de la aplicación. Recuerda que al compilarla deberás decirle que la versión ha cambiado ya que este es el parámetro que se utiliza para la comprobación, el número de versión.

Eso es todo, tu aplicación se actualizará automáticamente si hay nuevas versiones.

En el próximo capítulo veremos cómo detectar el estado de la conexión a Internet y su utilidad.

Adobe Air II – Aplicaciones en la barra de tareas

Programación, R.I.A., Técnico, , ,

Después de ver cómo crear los distintos tipos de ventana con los que se puede crear una aplicación AIR, veremos hoy como hacer una de esas cosas tan chulas que se minimizan en un icono al lado del reloj de Windows.

Es muy sencillo una vez, de nuevo, se entiende el concepto. No todos los sistemas operativos permiten lo que queremos hacer, Windows, Mac OSX y algunos Linux. Para saber si lo soporta AIR dispone de dos métodos, supportsSystemTrayIcon, para entornos tipo Windows, y supportsDockIcon, para entornos tipo Mac.

Antes de meternos en berenjenales necesitaremos, al menos, dos iconos para nuestra aplicación (gif o png si es transparente) a 16×16 píxeles y a 128×128.

En este código veremos cómo asignar un icono en la barra de tareas o en el Dock y crear un menú contextual en este icono con la opción “Salir”, puedes añadir tantas opciones como estimes oportuno.

private function appTray():void{
    var icon:Loader = new Loader();
    var iconMenu:NativeMenu = new NativeMenu();
    var exitMenu:NativeMenuItem = iconMenu.addItem(new NativeMenuItem("Salir"));
    exitMenu.addEventListener(Event.SELECT, function(event:Event):void {
        NativeApplication.nativeApplication.icon.bitmaps = [];
        NativeApplication.nativeApplication.exit();
    });

    if (NativeApplication.supportsSystemTrayIcon) {
        icon.contentLoaderInfo.addEventListener(Event.COMPLETE, iconLoadComplete);
        icon.load(new URLRequest("icons/icono16.png"));

        var systray:SystemTrayIcon = NativeApplication.nativeApplication.icon as SystemTrayIcon;
        systray.tooltip = "Mi Aplicación";
        systray.menu = iconMenu;
        systray.addEventListener(ScreenMouseEvent.CLICK, restauraVentana);
    }

    if (NativeApplication.supportsDockIcon){
        icon.contentLoaderInfo.addEventListener(Event.COMPLETE,iconLoadComplete);
        icon.load(new URLRequest("icons/icono128.png"));
        var dock:DockIcon = NativeApplication.nativeApplication.icon as DockIcon;
        dock.menu = iconMenu;
    }
}

private function restauraVentana(e:ScreenMouseEvent):void{
	stage.nativeWindow.visible=true;
	stage.nativeWindow.orderToFront();
}

Como veis, creamos el menú que le vamos a asignar y cargamos el icono adecuado dependiendo del soporte del sistema operativo. Eso es todo.

Simplemente llamaríamos a esta función en el evento creationComplete de la aplicación y ya la tendríamos integrada en la barra de tareas o en el Dock.

Éste es el resultado.

Aplicacion AIR en la barra de tareas

Sencillo ¿no?. En el siguiente capítulo, aplicaciones que se actualizan automáticamente si hay una versión nueva.

Adobe Air I – Tipos de ventanas y cómo hacer aplicaciones con nuestro propio chrome

Programación, R.I.A., Técnico, ,

Aprovechando que los últimos días me he metido de lleno a desarrollar una pequeña aplicación con Adobe Air, comienzo una serie de artículos dónde iré contando algunos de los entresijos de este sistema ya que parece muy sencillo pero cuando quieres hacer cosas concretas parece que se complica un poco.

Hoy veremos la parte fundamental de una aplicación, las ventanas en sí mismas. Se conoce como “chrome” al entorno sobre el que se crea la ventana. Habitualmente es el propio sistema operativo el que lo hace, son las ventanas clásicas de la mayoría de aplicaciones. En AIR se crean como “WindowedApplication” en la propia aplicación (veremos más adelante que éste es un detalle importante) y en el xml descriptor de la aplicación se configuran estos parámetros:

<initialwindow>
    <systemChrome>standard</systemChrome>
    <transparent>false</transparent>
</initialWindow>

El resultado, bajo Windows, sería la clásica ventana con la estética del sistema operativo.

Ventana Standard en Adobe Air

Vale, pero yo quiero crear mi ventana sin el chrome del sistema operativo.

La primera opción es configurar así los parámetros:

<initialwindow>
    <systemChrome>none</systemChrome>
    <transparent>true</transparent>
</initialWindow>

Y obtenemos una ventana con un chrome AIR.

Venatana none en Adobe Air

Queda muy bonita, pero yo lo que quiero es que no tenga nada de chrome, ni barra superior ni barra inferior, quiero definir yo toda la estética y funcionalidad de mi aplicación. Bienvenidos a la madre del cordero. Esto, que debería estar bien explicado en la documentación, no hay manera de entenderlo, de hecho creo que no se llega a explicar la manera concreta de conseguirlo.

La clave del problema es que, en este caso, la aplicación en el MXML no se definde como  “WindowedApplication” sino como “Application” estándar, el de cualquier aplicación Flex, y en el descriptor definimos:

<initialwindow>
    <systemChrome>none</systemChrome>
    <transparent>true</transparent>
    <visible>true</visible>
</initialWindow>

Y conseguimos el resultado esperado, sólo nuestra ventana sin adornos.

Ventana con chromless personal en Adobe Air

Es importante remarcar que en este caso hay que ponerle el parámetro visible=true dentro del xml ya que si no lo hacemos no se verá nada hasta que se ponga a true, perdí varias horas hasta averiguar porqué no veía nada.

Esto es todo por hoy. En el siguiente capítulo veremos cómo crear aplicaciones que se quedan como un icono al lado del reloj en Windows o en el Dock de Mac OSX.

Domina rápidamente Adobe Air

Programación, Proyectos, R.I.A., Técnico, , , , , , , ,

Leo en el blog de Mario Casario esta entrada donde anuncia la disponibilidad gratuita y bajo licencia Creative Commons de la guía Adobe AIR 1 for JavaScript Developer en formato PDF.

Para los que no lo sepáis, Air es la tecnología de Adobe para desarrollar rápidamente aplicaciones de escritorio utilizando otras tecnologías ya existentes: HTML, Javascript y Flash. Así de sencillo, aplicando lo que ya sabes puedes generar aplicaciones de escritorio multiplataforma (Windows y Mac ahora mismo, Linux en camino).

Air está de moda y más desde la compra de Twhirl por parte de Seesmic, de hecho Twitter es de lo más utilizado para crear aplicaciones Air.

Con Air puedes crear rápidamente pequeñas aplicaciones con acceso al sistema de archivos local, bases de datos locales (SQLlite), arrastrar y soltar… todo lo que necesitas para crear tus aplicaciones.

Os aseguro que es increíble lo que se puede hacer con poquísimas líneas de código.

Flash Player, sockets y políticas de seguridad

Programación, Proyectos, R.I.A., Técnico, , , , , ,

El pasado miércoles 9 de abril Adobe liberó una actualización de su Flash Player numerada como 9.0.124. Esta noticia pasaría completamente desapercibida si no fuese por las implicaciones que tiene. De hecho no entiendo como una actualización con los cambios que conlleva se ha numerado como una actualización menor y no se le ha dado más importancia.

El cambio fundamental de esta nueva versión radica en el modelo seguridad de la máquina virtual Flash al de acceder a sockets remotos y al utilizar headers HTTP. Recordemos que la opción de abrir sockets binarios y conectarse a ellos permitiendo aplicaciones bajo cualquier protocolo apareció en julio de 2006 junto a la versión 9 de Flash Player. Hasta ahora el modelo de seguridad de sockets era el mismo que para cualquier llamada remota bajo Flash, el famoso crossdomain.xml. Según esto, para acceder a cualquier archivo que no resida bajo el mismo host que sirve el swf que hace la llamada, el host servidor debe autorizar a la maquina virtual Flash la carga de ese archivo a través de ese crossdomain.xml, si no existe o no se autoriza el acceso, no se podrá acceder. Este es, por tanto, un archivo de políticas de seguridad y decide quién puede conectarse con Flash a tu servidor. A mi, personalmente, siempre me ha parecido algo ridículo, es como si para cargar un archivo de cualquier host desde tu navegador tuviesen que autorizártelo, pero siempre habrá quien encuentre ventajas en la seguridad. Si el archivo está publicado en Internet se supone que ya estas autorizado a leerlo, ¿para qué complicar más todo el proceso requiriendo más políticas de seguridad?. Y vaya si se complica…

Hasta ahora los sockets se trataban como archivos en lo que a políticas de seguridad se refiere, es decir, el crossdomain.xml del host al que conectábamos nos autorizaba el acceso igual que con cualquier llamada http. Si tienes una aplicación que utiliza sockets y actualizas a Flash Player 9.0.124 verás que ahora no te funciona, te salta una excepción de seguridad. Los chicos de Adobe se han inventado un sistema de políticas de seguridad exclusivo para sockets e independiente de las llamadas http.

Desde Adobe se han currado una ayuda/explicación de 7 páginas. Ninguna pega a no ser porque llegas al final de la lectura con la pregunta, vale, pero ¿qué tengo que hacer para que funcione? Es decir, mucha lectura pero poca, muy poca ayuda, da la impresión de que repiten lo mismo en todas las páginas sin aclarar nada.

La solución es sencilla a la par que curiosa y complicada para muchas aplicaciones. Debes crear una pequeña aplicación que, bajo el puerto 843 por defecto (aunque puedes usar otros puertos), debe responder a las peticiones de acceso con el crossdomain.xml. La mayoría de la gente ha entendido que debes tener tu servidor web a la escucha en el puerto 843 y devolver el crossomain.xml desde allí (como veis no está clara la documentación), pero NO es eso, no es una llamada HTTP la que te va a hacer el swf para pedir autorización. Veámoslo con un ejemplo práctico. Supongamos que fuese una solicitud HTTP, a grosso modo haríamos:

telnet www.tuhost.com 843
GET /crossdomain.xml HTP/1.0
HTTP/1.x 200 OK
Date: Tue, 15 Apr 2008 17:24:26 GMT
Server: Apache
Last-Modified: Thu, 28 Oct 2004 21:57:25 GMT
Content-Length: 128
Content-Type: text/xml

<xml version="1.0" encoding="UTF-8">.....</xml>

El xml final sería nuestro crossdomain.xml. Esto sería lo mismo que si cargamos el crossdomain.xml desde el puerto 80. Vale, pues esto es lo que NO va a hacer el swf, por tanto, no sirve. Esto es lo que va a hacer:

telnet www.tuhost.com 843
<policy-file-request/>
<xml version="1.0" encoding="UTF-8">.....</xml>

La diferencia es evidente, en el segundo caso, al contectar con el servidor simplemente le decimos <policy-file-request/> y nos debe devolver el xml del crossdomain.xml. No es el protocolo HTTP, es uno inventado que sólo responde a una petición.

El puerto no tiene porqué ser el 843, puedes modificarlo, pero Adobe pretende que 843 sea el estándar y, de hecho, está solicitando su homologación con el IANA.

Desde Adobe incluso se han puesto cachondos y te dicen que lo ideal es modificar tu aplicación en el servidor para que acepte la llamada <policy-file-request/> y responda con el XML, así no necesitarás una aplicación adicional. Pues nada chicos, a modificar todos los servidores smtp, pop, irc (nuestro caso), ftp… para que acepten la llamada. ¡Qué ridículo!

Como soy un tío enrollado os paso la solución completa. En esta URL tenéis un ejemplo de servidor en TCL/TK que funciona a la perfección y no consume recursos. Configura el puerto y la ruta al crossdomain.xml y a funcionar. Recuerda que si el puerto es inferior al 1024 deberá ser un usuario privilegiado quién ejecute la aplicación, deberías, entonces, enjaularla (chroot) para evitar posibles puertas. En realidad lo que hacemos es responder con el crossdomain.xml a cualquier petición que nos hagan, sea la correcta o no, ¿qué mas da? No vamos a hacer absolutamente nada más con ese puerto. Tendréis que preocuparos también de que se quede residente como demonio en vuestro servidor y, además, habrá que comprobar periódicamente que sigue a la escucha. Para esto recomiendo hacer un script que haga llamadas reales y espere el código XML necesario, comprobar simplemente con un netstat que el servidor ocupa el puerto no nos salvará de que el servidor se quede zombie. Por supuesto no olvides abrir tu firewall a ese puerto.

Actualización.
Acabo de terminar el artículo y a través de flexcoders me llega este enlace, mucho más claro y sencillo que la ayuda inicial. Ah! y con ejemplos de servidores en Perl y Python. En líneas generals viene a contar lo mismo que acabo de contar yo :P.