Antes de seguir escribiendo más código, es el momento de hacer un alto en el camino para repasar un poco de teoría. Y parece que lo más apropiado (al menos desde mi punto de vista) es comprender primero cuál es el ciclo de vida de una aplicación en Windows Phone: Desde que aprietas el icono en tu lista de aplicaciones o en un «tile» (baldosa) hasta que sales (o crees haber salido) de tu aplicación.
Empecemos con una referencia para contextualizar -> Aquí.
En la primera versión de Windows Phone, el sistema operativo permitía la ejecución de una única aplicación en primer plano en un momento dado. Para facilitarle la vida al programador el S.O. activaba y desactivaba aplicaciones de manera automática pero exponía una serie de eventos que el programador podía manejar para almacenar y recuperar el estado de la aplicación. Con Mango, el S.O. además mantiene una imagen de la aplicación en memoria tanto tiempo como le sea posible . De esta manera, se crea la sensación para el usuario de que la aplicación continua su ejecución desde el punto donde la dejó la última vez.
Al proceso por el cual el sistema operativo finaliza el proceso asociado a tu aplicación cuando navegas fuera de la misma se le llama «tombstoning» o «tombstone». Tombstone significa «Lápida» y no quisiera traducir «tombstoning» como lapidar ya que esto último es más bien matar a pedradas, cosa que de momento asumiré que el Sistema Operativo no va a hacer con el proceso de tu aplicación. En cualquier caso, tanto el nombre como la acción, son bastante descriptivas.
El sistema operativo está llevando a tu proceso a mejor vida pero en un estado de «animación suspendida» almacenando información sobre el estado en que quedó la misma (última página de la aplicación y el historial de navegación dentro de la misma). Si decides navegar de vuelta a tu aplicación, el sistema operativo restaura el proceso de la misma y le pasa el estado en que se quedó cuando saliste de ella por última vez.
En Mango, este modelo se mejoró y es conocido como «fast application switching» o «FAS». Intercambio Rápido de Aplicaciones.
Siguiendo con ello: si quieres controlar este proceso, deberás de manejar los eventos asociados a esta desactivación y posible tombstoning. Generalmente vas a querer mantener información sobre dos cosas:
- El Estado de la Aplicación (Application State). Que no se encuentra asociado a ninguna página en particular y que puede gestionarse mediante los eventos que expone la clase PhoneApplicationService. Esencialmente cuatro: Activated, Closing, Deactivated, Launching. Para aquellos que no controlen el inglés, el matiz es importante, cuando se utiliza el pasado, terminado con la partícula «ed» en este caso el significado es que el evento se lanza cuando ha finalizado la acción que maneja el evento. Es decir, en este caso, cuando la aplicación ya se ha activado o ya se ha desactivado. En el caso del gerundio, terminado con la partícula «ing», el significado es que el evento se está lanzando en algún momento, desde que se comenzó la acción que maneja el evento, pero sin que esta haya terminado todavía. Así, en este caso, los eventos Closing y Launching se lanzan en algún momento antes de que la aplicación termine de cerrarse o antes de que la aplicación termine de estar lista para arrancar.
- El Estado de la Página (Page State). Que representa el estado (posición del cursor, información almacenada, etc…) de la página donde quedó la aplicación en el momento del cierre. Normalmente se suele manejar dicho estado desde los manejadores de eventos OnNavigatedTo y OnNavigatedFrom.
Vale. ¿Cómo sé cuándo el sistema operativo va a ponerle la lápida a mi aplicación y cuándo no? Existe alguna regla al respecto, en general supón que ocurrirá siempre que navegues fuera de tu aplicación… Pero, no podía ser de otra manera, existen excepciones.
Imagina que dentro del contexto de tu aplicación (muchas lo hacen) necesitas sacar una foto o video, escoger una imagen de tu biblioteca, seleccionar un contacto de tu agenda, lanzar el reproductor de medios… En, general, realizar una acción que (estando estrictamente fuera de tu aplicación) tiene para el usuario un sentido dentro del discurso de la misma. Bien, en esos casos, el Sistema Operativo no le va a poner la lápida a tu aplicación (tobmstone, ya sabes). Salvo, claro está que se esté quedando sin memoria, en cuyo caso no se va a andar con miramientos, compréndelo.
Bien. Momento de tomar un respiro y ver si hemos digerido lo anterior.
¿Lo tienes? Bien, sigamos pues que ya queda poco.
Cuál es entonces el ciclo de vida de una aplicación. Pues voy a poner mi versión de un gráfico que he visto por ahí en varios sitios, no porque me sienta original, simplemente porque se entiende mejor cuando intentas hacer un blog en español.
Ciclo de vida de una aplicación en Windows Phone
Si no le has echado un vistazo al artículo que enlacé al comienzo, hazlo ahora. Encontrarás una diferencia importante entre los diagramas que se pintan ahí y el que he pintado aquí. Esencialmente el diagrama en el artículo de la MSDN distingue entre dos estados (no transiciones) de «desactivación» de tu aplicación. En el que el sistema operativo mantiene tu aplicación en memoria (un durmiente, dormant) y en el que lo ha enterrado y puesto la lápida (tombstone).
En esta entrada he preferido no hacer la distincion ya que no tienes forma de saber cuándo el sistema operativo va a realizar a ciencia cierta la operación de tombstone, así que prepárate para ella y te curarás en salud.
Bien, espero que con esto quede claro. A mi, desde luego, me ha ayudado aunque es probable que tenga que repasar algún que otro concepto más antes de seguir adelante con la aplicación.
jdmveira 