Vuelvo a la carga con la tercera entrada de la serie #FirefoxOSDeveloper, donde aprenderemos un poco más sobre la distribución estándar de paquetes de aplicaciones para este recién sacado SO móvil.


Firefox-OS-Developer-Phone-

Aprovecho también la entrada para comunicaros que, si bien Firefox OS Mobile era un sistema operativo  en fase beta, desde antesdeayer podemos considerarlo una realidad, que cuenta no solo con terminales para desarrolladores, sino también dispositivos comerciales de fabricantes de la talla de ZTE, Alcatel, Sony o LGE, y con el apoyo de decenas de operadoras de varios países, con Telefónica al frente. Durante este año se empezarán a vender los terminales, encaminados como era de esperar a un mercado inicial de gama media/baja, y en países como España, Brasil, Venezuela y Colombia.

Packages

Como seguramente no todos los que han llegado a esta entrada (bien sea porque son asiduos al blog, o por búsquedas orgánicas) están al tanto de como es la arquitectura de aplicaciones para dispositivos móviles, creo oportuno empezar por este punto.

Para el desarrollo de una app, y su correcta interpretación por parte del SO de turno, es necesario fijar una estructura de carpetas y ficheros que facilite por un lado la labor de los desarrolladores y diseñadores de cara a futuras implementaciones, y por otro la estandarización de la distribución interna de las aplicaciones para markets e instaladores por defecto contemplados en el sistema.

Por tanto, una aplicación, como la mayoría de proyectos de desarrollo, parte de un esquema al cual llamamos paquete (package).

Dependiendo del sistema operativo (o el tipo de proyecto) sobre el que estamos trabajando, cada package contendrá un número mínimo de archivos y/o carpetas, con una denominación más o menos obligatoria.

Si alguna vez habéis programado webs, seguramente estéis usando una estructura semejante a la contenida en paquetes, que por lo general parte de la necesidad de una página inicial llamada index (index.html, index.php,…) que será la encargada de mostrarse tan pronto se acceda a la dirección. Dicha página, contiene a su vez enlaces internos a la hoja o hojas de estilo, que quizás estén en una carpeta que se desprende del directorio raiz llamada css, enlaces internos a código JavaScript (o Ajax, o jQuery,…), contenidos a su vez en otra carpeta js, e imágenes, que pueden estar en una carpeta images.


PabloYglesias-folder

La estructura que acabo de detallar, se convierte en package para Firefox OS Mobile cuando incluimos al menos un archivo manifest, en este caso, manifest.webapp, y todo ello lo comprimimos en un archivo .zip.

El porqué de los packages y la certificación de los markets

Instalar en un SO un archivo es más sencillo que pasarle listas enormes de archivos y que tenga que ir uno a uno compilándolos o interpretándolos. Además, un paquete permite certificar una aplicación de forma mucho más sencilla por parte de las stores, de tal forma que para el sistema operativo, resulta muy sencillo saber tan pronto accede a un paquete si éste está certificado (cuenta con el visto bueno) del market, o por el contrario no (y por tanto, no ha pasado los criterios de seguridad y privacidad predefinidos para instalarse). Como estaréis pensando, esta certificación no es más que una private key que se embebe en el código del zip, sirviendo además como categorizador de aplicaciones en Firefox OS Mobile, atendiendo al nivel de acceso interno que requiere la aplicación:

  • Aplicaciones certificadas (Certified App): Son aplicaciones destinadas a tener acceso a funciones críticas del teléfono, como la configuración del mismo. Este tipo de certificación es por tanto solo accesible si la firma el fabricante y la compañía, y a efectos prácticos, son iguales a las aplicaciones privilegiadas con la salvedad que en éstas el permiso a APIs críticas está aceptado implícitamente (sin necesidad de preguntar al usuario).
  • Aplicaciones privilegiadas (Privilieged App): Una aplicación con privilegios o privilegiada es aquella que tiene acceso a APIs internas del SO de forma explícita. El mejor ejemplo son las aplicaciones nativas de iOS y Android, donde antes de instalarlas, tienes que aceptar tú mismo que permites que dicha aplicación acceda a diferentes servicios de tu terminal. Para publicarla en la tienda, tiene que ser aprobada por ellos después de un análisis exhaustivo del código.
  • Aplicaciones regulares (Plain Package App): Se trata de aplicaciones que no necesitan acceder a ninguna API interna (como por ejemplo una webapp básica). Por tanto, no piden permisos, y no tienen derecho a ellos.

Instalación de paquetes en el terminal

Hay dos maneras de publicar una aplicación. O bien hosteadas en el servidor del market, o bien en un espacio propio.

En el primer caso, el zip subido genera en el market un manifest propio llamado mini-manifest, que estará basado en el manifiesto que hemos incluido dentro del zip, y será éste el que se envía al API installPackage() cuando queremos instalar la aplicación en el terminal. Una vez instalada, se usará el manifest implementado por el desarrollador.

En las aplicaciones alojadas en servidores propios, este paso lo tendrá que llevar a cabo el desarrollador, mediante un archivo externo al .zip llamado package.manifest que hará las veces de “mini-manifest” y tendrá una estructura semejante a la siguiente:

{
"name": "My App",
"package_path": "http:///package.zip",
"version": "1.0"
}


Y un archivo de instalacción install.html cuyo algoritmo sería algo así:

Packaged app installation page

Otros archivos a tener en cuenta

Hemos hablado de manifest.webapp y del package.manifest, pero si habéis descargado el Firefox OS Boilerplate App Template de mi cuenta de Github, observaréis que existen dos ficheros más que acompañan al resto del paquete:

  • manifest.appcache: se trata de un manifiesto contemplado en HTML5 para mostrar la aplicación (o la web) sin conexión. En él, definimos qué archivos deben cargarse en local, de forma que cuando no tengamos conexión, podamos acceder a la aplicación con todas o la mayoría de las prestaciones que ella nos proporciona. Todos los datos son guardados en el caché del terminal, y tiene una estructura tal que así:

CACHE MANIFEST

# Version 0.6799999

index.html
css/base.css
js/base.js
js/webapp.js
js/offline.js


NETWORK:
*

FALLBACK:
/ fallback.html

El archivo manifest.appcache cuenta con tres apartados:

CACHE: Esta es la sección predeterminada para las entradas. Los archivos incluidos en esta sección (o inmediatamente después de CACHE MANIFEST) se almacenarán en caché explícitamente después de descargarse por primera vez.

NETWORK: Los archivos incluidos en esta sección son recursos permitidos que requieren conexión al servidor. En todas las solicitudes enviadas a estos recursos se omite la caché, incluso si el usuario está trabajando sin conexión. Se pueden utilizar caracteres comodín.

FALLBACK: Se trata de una sección opcional en la que se especifican páginas alternativas en caso de no poder acceder a un recurso. En la demo, cargaría el archivo fallback.html cuando no tenga acceso de red.

  • Readme.md (o readme.markdown): es un fichero que sirve de descripción para proyectos abiertos en repositorios como GitHub. No es necesario por tanto, aunque su uso se ha extendido y suele contemplarse como buenas prácticas en proyectos genéricos.

En la siguiente entrada, que tendrá de hashtag #FirefoxOSDeveloper, nos metermos un poco en explicar el funcionamiento de algunas de las APIs implementadas.
Para facilitaros el seguimiento del tutorial, os dejo los enlaces a cada una de las entradas anteriores:

Otros artículos relacionados