Programación para Windows Phone 7: Guardar el estado

Este es un artículo de una serie dedicada al desarrollo de aplicaciones para Windows Phone 7 en Silverlight. Como primer ejemplo estamos creando una aplicación sencilla de representación de datos y la iremos refinando en sucesivos episodios:

1. Aplicación base: representación de datos y visionado de vídeos.
   
2. Mejoras visuales y navegación
   
3. Guardar el estado (tombstoning)
   
4. Mejoras de rendimiento
   
5. Interacción con otros servicios
   
6. Preparación para el Marketplace
   

Hoy toca el episodio 3: Guardar el estado, donde aprenderemos cómo hacer que nuestra aplicación no pierda los datos cuando es desactivada.

¿Por qué guardar el estado?

En Windows Phone 7 las aplicaciones se pueden desactivar de diversas maneras, pero en todas ellas el usuario esperará que al volver a la aplicación ésta conserve el estado en el que estaba cuando la dejó por última vez.

Las situaciones más comunes son:

• Pulsación del botón de inicio o de búsqueda: se desactivará la aplicación en curso, para reactivarla hay que pulsar el botón de retroceder
  
• Ejecución de una tarea desde la aplicación: lanzar una llamada, abrir una url en el webbrowser externo y otras tareas harán que la aplicación se desactive temporalmente.
• Bloqueo del teléfono
• Recepción de una llamada, mensajes de texto, eventos de calendario

Aparte de esos casos también deberíamos considerar el caso de cierre de aplicación. Recordemos que estamos en un dispositivo móvil y puede estar usando una tarifa de datos que penaliza el exceso de descarga.

¿Cuándo guardar el estado?

Tanto al cerrar como al desactivar la aplicación, ésta acaba eliminándose de la memoria. Al desactivar se guarda cierta información para saber en qué página xaml se desactivó la aplicación, de manera que al reactivar se abrirá esa página automáticamente. En estos casos el sistema nos da la oportunidad de guardar el estado de la aplicación, así los datos se podrán recuperar durante la reactivación y no hará falta descargar esa información de nuevo. A este hecho se le conoce en Windows Phone 7 como Tombstoning.

Mientras que al abrir y cerrar las aplicación ocurren los eventos Application_Launching y Application_Closing, el tombstoning y la posterior recuperación ocurren en Application_Activated y Application_Deactivated. Podemos encontrar los eventos en el archivo app.xaml.cs:

Código :

// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
    System.Diagnostics.Debug.WriteLine("Launching");
}
// Code to execute when the application is activated (brought to foreground)
// This code will not execute when the application is first launched
private void Application_Activated(object sender, ActivatedEventArgs e)
{
    System.Diagnostics.Debug.WriteLine("Activated");
}
// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
    System.Diagnostics.Debug.WriteLine("Deactivated");
}
// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
    System.Diagnostics.Debug.WriteLine("Closing");
}

¿Cómo?

En el caso de nuestra aplicación de demostración nos conviene guardar los datos en los dos modos: cierre y tombstoning. En tombstoning para evitar que la aplicación se quede sin datos al volver y en cierre para evitar cargas adicionales cuando no hacen falta, de manera que guardaremos un caché de los datos.

Para ello vamos a escribir en los eventos de desactivación y de cierre las llamadas para guardar el estado:

Código :

// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
    // Ensure that required application state is persisted here.
    ViewModel.SaveToState();
}
// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
    ViewModel.SaveToIsolatedStorage();
}

En el evento Deactivated guardaremos el modelo en el State, una colección de valores que nos permitirá guardar y recuperar de manera muy rápida el contenido de nuestra colección.

Código :

public void SaveToState()
{
    IDictionary stateStore =
           PhoneApplicationService.Current.State;
    stateStore.Remove(keyName);
    stateStore.Add(keyName, this);
}

Durante el cierre de la aplicación guardaremos la información en el IsolatedStorage, un almacen de datos único y seguro para nuestra aplicación y usuario. Para ello tendremos que serializar nosotros mismos nuestra colección de datos y guardarla en un fichero.

Código :

public void SaveToIsolatedStorage()
{
    using (IsolatedStorageFile file=IsolatedStorageFile.GetUserStoreForApplication())
    {
        using (IsolatedStorageFileStream stream=file.OpenFile(keyName, System.IO.FileMode.Create))
        {
            XmlSerializer ser=new XmlSerializer(this.GetType());
            stream.Position=0;
            ser.Serialize(stream, this);
        }
    }
}

Recuperación del estado

Durante la recuperación de la aplicación tenemos dos eventos, según el momento en el que se encuentre: al arrancar la aplicación se ejecutará Application_Launching y al recuperar desde una desactivación será Application_Activated. En nuestra aplicación crearemos una función para saber si tenemos que recuperar el estado, en función de la edad y del estado de la colección, así evitaremos cargar los datos mientras la lista que tenemos sea lo suficientemente nueva.

Código :

 private bool isValid()
 {
     if (ViewModel.Videos == null || ViewModel.Videos.Count == 0)
     {
         return false;
     }
     else if (ViewModel.LastRefresh == null || (DateTime.Now - viewModel.LastRefresh.Value).Hours ] 2)
     {
         return false;
     }
    return true;
 }
 // Code to execute when the application is launching (eg, from Start)
 // This code will not execute when the application is reactivated
 private void Application_Launching(object sender, LaunchingEventArgs e)
 {
     if (!isValid())
     {
             ViewModel.LoadFromIsolatedStorage();
             if (!isValid())
                 ViewModel.LoadData();
     }
 }
 // Code to execute when the application is activated (brought to foreground)
 // This code will not execute when the application is first launched
 private void Application_Activated(object sender, ActivatedEventArgs e)
 {
     // Ensure that application state is restored appropriately
     if (!isValid())
     {
         ViewModel.LoadFromState();
         if (!isValid())
             ViewModel.LoadData();
     }
 }

Para cargar la colección del IsolatedStorage hacemos la operación inversa. Miramos si existe dentro del Storage e intentamos deserializar lo que habíamos guardado:

Código :

public void LoadFromIsolatedStorage()
{
    using (IsolatedStorageFile file=IsolatedStorageFile.GetUserStoreForApplication())
    {
        if (file.FileExists(keyName))
        {
            using (IsolatedStorageFileStream stream=file.OpenFile(keyName, System.IO.FileMode.Open))
            {
                XmlSerializer ser=new XmlSerializer(this.GetType());
                MainViewModel model=(MainViewModel)ser.Deserialize(stream);
                loadModel(model);
            }
        }
    }
}

En el caso de la reactivación podemos mirar directamente en la lista State:

Código :

public void LoadFromState()
{
    IDictionary stateStore =
            PhoneApplicationService.Current.State;
    if (stateStore.ContainsKey(keyName))
    {
        MainViewModel model=(MainViewModel)stateStore[keyName];
        loadModel(model);
    }
}

En el método loadModel(model) usamos el modelo que hemos recuperado para rellenar el principal de nuestra aplicación.

Tombstoning en XNA

Hasta aquí hemos explicado los eventos que tendremos para el caso de que queramos guardar el estado en una aplicación Silverlight. Si programamos para XNA cambiará la información que guardemos, pero los casos serán muy parecidos y tendremos los mismos eventos. En otro artículo trataremos el tema desde el enfoque de XNA.

Conclusiones

En este episodio hemos aprendido las dos maneras que tenemos de guardar el estado de la aplicaciones, cuándo y por qué debemos hacerlo para mejorar la experiencia del usuario.

Podéis descargar el código de ejemplo en codeplex.

En el próximo episodio vamos a realizar unos cuantos cambios para mejorar aún más el rendimiento de la aplicación y que esta sea mucho más fluida.

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.