AIR firstrun manager

flex3 - airLas 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:

File URI
Directorio de instalación File.applicationDirectory app:/
Directorio de almacenamiento File.applicationStorageDirectory app-storage:/
Escritorio File.desktopDirectory
etc… (más info…)

 

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:
Estructura de directorios del proyecto
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
[mxml]



[/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

 

Referencias

1 Comentario

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase