En este artículo analizaremos la funcionalidad que la página principal de la aplicación, Default.html, va a tener gracias a su código Javascript asociado.

Default.js

En este fichero encontraremos las instrucciones de Javascript que van a dotar de funcionalidad a la página Default.html.

Lo primero que llama la atención es que todo el código está escrito en una función anónima de JavaScript, para evitar que se puedan propagar variables al objeto global desde ella; esto es considero hoy en día como una buena práctica. También es destacable la siguiente sentencia, que aparece en la primera línea de código una vez definida la función:

'use strict';

Se trata del "modo estricto", un nuevo modo de funcionamiento de JavaScript que se definió con la versión 5 del estándar. En este modo JavaScript se convierte en un lenguaje más seguro y más rápido estableciendo restricciones a una serie de prácticas que, aun siendo habituales en algunos casos, han sido siempre consideras como malas.

En cuanto al código en sí se reduce a tres pasos:

• Implementar un manejador para el evento onactivated.
• Implementar otro manejador para el evento oncheckpoint.
• Arrancar la aplicación con el método start().

Empezamos con el método start, por ser el más sencillo de los tres. Su única función consiste en poner en marcha el sistema de entrega de eventos. Es decir, hasta el momento en que se ejecute start(), los posibles eventos que la aplicación esté pendiente de recibir, estarán retenidos.

Los otros dos son eventos relacionados con el ciclo de vida de las Aplicaciones Metro, al que le dedicamos un artículo en este manual con anterioridad. Resumiendo dicho artículo, las Aplicaciones Metro van a tener un ciclo de vida que pasará por varias fases como son:

• Activación: la aplicación es lanzada por el usuario o bien por otros medios como son los contratos del sistema, como Share o Search (los veremos más adelante en profundidad).
• Suspensión: si el usuario saca de primer plano a la aplicación, pasados unos segundos Windows 8 suspenderá la aplicación, llevándola a un estado en memoria en el que no consume recursos y responde a estímulos de ningún tipo.
• Terminación: si Windows 8 detecta falta de recursos, comienza a descargar aplicaciones suspendidas de memoria para liberarlos.

Las Aplicaciones Metro tienen posibilidad de “reaccionar” a dos de estas fases: activación y suspensión, mientras que la terminación se realiza sin previo aviso de ningún tipo. Los eventos implementados en default.js se refieren, precisamente, a estas dos fases.

Evento OnActivated

En el caso del manejador de onactivated, como podemos imaginar, sirve para la aplicación realice alguna acción específica al ser activada. Veamos su código:

app.onactivated = function (eventObject) {
if (eventObject.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {
if (eventObject.detail.previousExecutionState !== Windows.ApplicationModel.Activation.ApplicationExecutionState.terminated) {
// TODO: This application has been newly launched. Initialize
// your application here.
} else {
// TODO: This application has been reactivated from suspension.
// Restore application state here.
}
WinJS.UI.processAll();
}
};

En este código, en primer lugar, se analiza qué ha motivado la activación de la aplicación, a través de la propiedad ActivationKind. Esta propiedad nos ofrece muchos valores distintos, algunos de los cuales podemos ver en la siguiente tabla:

Valor	Descripción
launch	El usuario lanzó la aplicación o pulsó en su tile
search	El usuario quiere buscar con la aplicación
shareTarget	El aplicación se ha activado como destino de una operación de compartir
file	Una aplicación ejecutó un fichero que esta aplicación es capaz de manejar
protocol	Una aplicación ejecutó una URL cuyo protocolo esta aplicación es capaz de manejar

Estos son sólo algunos de los 11 valores distintos que ActivationKind nos ofrece. Muchos de estos valores tienen una relación directa con el concepto de “Contracts” o Contratos, una de las novedades más importantes en Windows 8.

Windows 8 propone una serie de Contratos que van a describir una serie de requisitos. Las Aplicaciones Metro que implementen estos contratos podrán participar en interacciones gestionadas por Windows y que permitirán comunicar aplicaciones entre sí, sin necesidad de un conocimiento entre ambas. Simplemente la existencia del contrato y de sus características fijas permitirá esta comunicación que será gestionada de punto a punto por Windows. Por ejemplo, en un contrato de tipo Share, una aplicación implementará las características necesarias para compartir información, mientras que otra aplicación implementará las requeridas para recibir información. Entre medias Windows gestionará todo el proceso.

Volviendo a los tipos de activación descritos en ActivationKind, muchos de ellos se refieren a activaciones ocurridas como parte de la participación en uno de los flujos descritos por estos contratos y gestionados por Windows. De este modo será aquí, en este punto del código de la aplicación, donde deberemos implementar la funcionalidad correspondiente para gestionar una activación por tipo de contrato.

En el código que veíamos antes el tipo de activación que se va a gestionar es simplemente “lauch”, correspondiente al lanzamiento manual del usuario. A la hora de gestionar dicha activación se está teniendo en cuenta, al consultar el valor de la propiedad previousExecutionState, si la aplicación se suspendió en su última ejecución o si ésta es su primera activación. En la enumeración ApplicationExecutionState vamos a tener los valores mostrados en la siguiente tabla.

Valor	Descripción
notRunning	La aplicación no está ejecutándose
running	La aplicación está ejecutándose
suspended	La aplicación está suspendida
terminated	La aplicación se terminó después de suspenderse
closedByUser	La aplicación fue cerrada por el usuario

Para terminar con el manejador del evento onActivated, la última línea corresponde a una llamada a processAll(), que se encargará de aplicar el binding declarativo de todos los elementos descritos en la vista. Este método devuelve un objeto promise al que podremos suscribirnos para realizar algún trabajo al finalizarse el proceso de bindeo de los controles.

Evento OnCheckpoint

El otro evento al que se está suscribiendo la aplicación gestiona el proceso contrario; es decir, se lanzará cuando la aplicación esté a punto de ser suspendida, o bien cuando se invoque al método checkpoint(). Podemos ver su código a continuación.

app.oncheckpoint = function (eventObject) {
// TODO: This application is about to be suspended. Save any state
// that needs to persist across suspensions here. You might use the
// WinJS.Application.sessionState object, which is automatically
// saved and restored across suspension. If you need to complete an
// asynchronous operation before your application is suspended, call
// eventObject.setPromise().
};

En este punto la aplicación tendrá que guardar su estado en menos de 5 segundos, que es el tiempo que Windows esperará para que se complete el proceso. Si la aplicación se demora más tiempo, será terminada.

Para almacenar esta información la forma más sencilla es utilizar la propiedad sessionState, que nos permitirá almacenar síncronamente los datos que queramos en ella y que es guardada y restaurada desde la suspensión hasta una posterior activación por Windows, sin necesidad de nuestra intervención.

Conclusiones

En este artículo hemos empezado a ver cómo se gestiona el ciclo de vida de las aplicaciones desde un punto de vista del código, después de que en un artículo anterior viéramos desde un punto de vista teórico qué etapas existen y cómo se suceden en la vida de una aplicación.

Hemos visto también qué son los contratos y cómo afectan a la activación de una aplicación. Más adelante volveremos sobre estos temas para dotar de más funcionalidad y más enganche con el usuario a nuestra Aplicación Metro.

Bibliografía

Centro de Desarrollo de Windows (español)