Me sorprendió ver que el desarrollo de aplicaciones para escritorio basadas en AIR no fue tan popular como me lo esperaba. Quizá me equivoque cuando digo lo anterior, pero a mi no me ha parecido que así haya sido. El desarrollo de aplicaciones en AIR no es ni reservado exclusivamente para desarrollo en Flash ni mucho menos algo difícil de hacer.

El desarrollo de aplicaciones en AIR es sencillo

Se me ocurren dos razones por las que esto ha pasado. La primera es que tal vez pensamos que AIR es solo para uso con aplicaciones tipo Flash. La otra es que probablemente pensamos que el desarrollo de aplicaciones para escritorio es muy difícil. La verdad es que aceptar cualquiera de estas dos razones sería aceptar una mentira.

En este artículo no voy a explicar como instalar el runtime de AIR ni el SDK. La razón de esto es por que a mi nunca me sale tal y como lo dicen las instrucciones y siempre termino haciendo todo a mi manera. Sin embargo, si quiero hacer énfasis en el hecho de que para seguir esta serie necesitas tener ambos, tanto el runtime como el SDK, instalados en tu computadora. Así que entremos en materia.

Anatomía de una aplicación AIR

Empecemos por ponernos un poco “porno” y desnudar por completo una aplicación AIR de modo que podamos entender sus componentes. Una aplicación AIR se compone de mínimo dos archivos. Uno es un archivo XML que se usa para describir la aplicación y un archivo principal el cual se carga al iniciar la aplicación.

El archivo XML:

El archivo XML es de suma importancia. Si hasta hoy no conoces o no sabes usar XML no te preocupes, este archivo sigue siempre el mismo formato y totalmente fácil de crear. Simplemente tienes que establecer algunos valores según quieras que tu app se comporte, se presente o se identifique.

La función del archivo XML es fundamental ya que es la que literalmente mantiene a la aplicación unida. Piensa en este archivo como un amarre para tu aplicación. El formato general es el siguiente:

<?xml version="1.0" encodign="utf-8" ?>
     <application xmlns="http://ns.adobe.com/air/application/1.0">
     <id></id>
     <filename></filename>
     <name></name>
     <description></description>
     <version></version>
     <initialWindow>
          <content></content>
          <title></title>
          <systemChrome></systemChrome>
          <transparent></transparent>
          <visible></visible>
          <minimizable></minimizable>
          <resizable></resizable>
     </initialWindow>
</application>

Como vez, el contenido es totalmente predecible. Seguro que ya sabes de que se trata cada uno de los elementos. No voy a entrar en explicaciones sobre XML, porque eso da para un par de libros, así que solo me voy a centrar a explicar lo que está pasando en esta pieza de XML en particular. El archivo XML empieza con la declaración de XML:

<?xml version="1.0" encodign="utf-8" ?>

En donde se establece la versión de xml que se está usando en este caso 1.0, y el “enconding” en este caso utf-8.  Asegúrate de que no haya ningún espacio antes de esta declaración. Después el archivo continua con el elemento raíz.

<application> todo lo que pasa en nuestro XML, pasa dentro de este elemento raíz. Los elementos siguientes son totalmente claros, pero aún así, por el simple gusto de saber que la información es 100% clara, procedo a explicar cada uno de ellos. Una vez más, si así lo deseas, puedes saltar esta info y continuar más abajo.

<id></id> Este elemento establece un identificador para la aplicación. AIR usa este identificador para poder distinguir entre una aplicación y otra. Se recomienda que la estructura de este identificado sea la conocida como “reverse domain format” o formato de dominio en reversa. Si alguna vez programaste en Actionscript usando clases externas lo más seguro es que estés familiarizado con este formato.

Si no fue así, lo más seguro es que estés familiarizado con este formato (no, no me equivoque, es lo mismo). La verdad es que este formato es muy popular y es usado para evitar choque entre identificadores ya que se supone que los dominios son únicos, al usar tu dominio estás asegurándote que tu identificador será único. Veamos un ejemplo de como establecer el valor de <id></id> 

<id>com.wordpress.imbuzu.miAppAIR</id>

Como vez, he usado mi dominio (imbuzu.wordpress.com) en reversa y le he agregado el nombre de mi app (miAppAIR). De esta manera es poco probable que alguien más asigne el mismo id. Por el contrario, si no usara este formato y solo pusiera:

<id>miAppAIR</id>

Lo más probable es que alguien más use el mismo id, entonces la etiqueta pierde totalmente su sentido y su función.

Me confieso: La primera vez que yo vi una declaración en “reverse domain format” me imaginé que mi archivo tenía que estar alojado en esa dirección, pero NO es así. Tu archivo no tiene que estar alojado en esa dirección. Esa es solo una forma de asegurar IDs únicos que no se repiten en ninguna app en ningún otro lugar del mundo.

<filename></filename> Esta etiqueta establece el nombre que se le dará a la aplicación cuando se instale. Por ejemplo si nuestra aplicación se llama miAppAIR (no es un buen nombre para una app real), esta etiqueta quedaría así:

<filename>miAppAIR</filename>

<name></name> El nombre de la aplicación. A diferencia de filename, que establece el nombre del archivo, name establece el nombre de la aplicación. En otras palabras, el nombre que vez cuando abres la aplicación. En nuestro caso podríamos establecer esta etiqueta de la siguiente manera:

<name>Mi App AIR</name>

<description></description> Con esta etiqueta damos una breve descripción de la aplicación. Esta etiqueta es opcional. El mensaje de descripción será presentado al usuario mientras la aplicación está siendo instalada, por lo que es buena idea incluir una descripción, así por lo menos el usuario tiene algo que hacer mientras la app se instala -leer la descripción-. Nosotros podemos por ejemplo poner:

<description>Mi primer aplicación en AIR</description>

<version></version> Esta etiqueta describe la versión de nuestra aplicación. Ejemplo: <version>1.0</version>

Después tenemos el elemento <initalWindow> el cual contiene las especificaciones para el formato de la ventana inicial. Dentro de este elemento tenemos algunas etiquetas con las cuales definimos las características que queremos en nuestra ventana. A continuación explico estas etiquetas: <title></title> Especifica el titulo de la ventana inicial.

<systemChrome></systemChrome> Acepta dos valores, “standard” y “none” y nos sirve para especificar el tipo de system Chrome que la aplicación debería usar.

<transparent></transparent> Especifica si el fondo de la ventana debería ser transparente. Solo aplica si systemChrome tiene como valor none. Esta etiqueta es opcional. Si no se especifica, su valor por defecto es false. Acepta los valores true y false.

<visible></visible> Especifica si la aplicación es visible cuando se inicia. Su valor por defecto es false y es una etiqueta opcional.

<minimizable></minimizable>Acepta los valores true y false. Toma como valor por defecto true y sirve para especificar si la ventana puede ser minimizada o no.

<maximizable></maximizable> Al igual que la etiqueta anterior, acepta los valores true y false, con valor true por defecto. Sirve para especificar si la ventana puede ser maximizada o no.

<<resizable></resizable> Acepta los valores true y false. True es el valor por defecto. Indica si la ventana puede ser cambiada de tamaño.

Eso concluye el archivo XML. Por otro lado, el archivo html es simplemente el archivo principal de nuestra aplicación. En nuestro caso podemos poner un archivo que simplemente consista de lo siguiente:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
     <head>
     <meta http-equiv="content-type" content="text/html; charset=iso-2022-jp" />
     <title>MiAppAIR</title>
     </head>
     <body>
          <p>Esta es mi app en AIR</p>
     </body>
</html>

Si instaláramos esa aplicación y la abriéramos, veríamos una ventanita con el texto “Esta es mi app AIR”. Seguro que eso no es muy emocionante, pero por ahora es lo único que vamos a hacer. En próximos artículos veremos como probar nuestras aplicaciones sin necesidad de instalarlas cada vez que hagamos un cambio y desarrollaremos nuestra primera aplicación que realmente haga algo. Espero sus comentarios y sugerencias.

Segunda parte: Desarrollando y probando nuestras aplicaciones con AIR