2011-04-05 7 views
5

¿Existe una mejor práctica para manejar apropiadamente el tombstoning y la tecla de retroceso?¿Manejar apropiadamente las palabras Tombstoning y Back por motivos de rendimiento?

Como se indica en el documento de MSDN, debe guardar los datos transitorios en el método OnNavigatedFrom. Ok, entonces el código para guardar los estados cuando se desembarca es claro.

Pero ahora si presiona la tecla Atrás también se llama al método OnNavigatedFrom y si no agrega comprobaciones adicionales, primero guardará los estados en el diccionario y poco después se destruirá la página. Y también lo hará el diccionario PhoneApplicationPage.State. Entonces, el código de guardado es completamente CPU, disco y tiempo de batería perdidos.

Esto es lo que he hecho para prevenirlo:

protected override void OnNavigatingFrom(System.Windows.Navigation.NavigatingCancelEventArgs e) 
    { 
     // when navigating back 
     if (e.NavigationMode == System.Windows.Navigation.NavigationMode.Back) 
     { 
      backKeyPressed = true; 
     } 
    } 

    protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e) 
    { 
     if (backKeyPressed) 
     { 
      // Don't save states on back key! 
      backKeyPressed = false;  // set it anyway 
      return; 
     } 

     // Tombstoning 
     // save objects 
     this.SaveState("text", someText); 
     ... 
    } 

Como recordatorio: OnNavigatingFrom solamente se llamará cuando se navega fuera/atrás de la página, pero no cuando la aplicación se extingue.

Nota al pie: el código mostrado solo cubre las páginas que solo pueden retroceder. Es por eso que agregué backKeypressed al OnNavigatingFrom. Necesita controles adicionales si la página puede navegar a otra página.

  1. ¿Hay alguna forma mejor de hacerlo en cada página que crees?
  2. Ahora, ¿realmente tengo que agregar la variable backKeyPressed y verificar en cada página que creo?
  3. ¿No debería el framework proporcionarnos algo para nosotros, por lo que no tenemos que preocuparnos demasiado por esto?

¿Qué piensas sobre esto?

EDIT:

pregunta Actualizado el que sea más claro.

Respuesta

2

su enfoque de verificar la dirección de navegación en OnNavigatingFrom es de hecho la práctica recomendada para evitar el golpe de rendimiento innecesario del estado de ahorro justo antes de que la página se elimine de la backstack.

Hay una aclaración que quiero agregar a su código de muestra: Debe verificar la propiedad 'NavigationMode' en 'NavigationCancelEventArgs' para determinar si se trata de una navegación hacia adelante o hacia atrás.

A continuación, solo guarde el estado en OnNavigatedFrom si se trata de una navegación hacia adelante, como se muestra en la muestra. Esto ayudará a mejorar su rendimiento cuando el usuario navega hacia atrás.

+0

Gracias por la pista con NavigationMode. Sería bueno si este comportamiento se simplificará en el futuro. Algo así como: agregar NavigationMode a OnNavigatedFrom o un nuevo método propio para tombstoning o algo así. Entonces no tendremos que usar una variable backKeyPressed separada. – Buju

+0

Sí, eso está en la lista de pendientes :-) –

+0

¡gracias! :) – Buju

1

Todo lo que siempre necesitó saber sobre el tombstoning está cubierto en la serie de entradas de blog de 4 partes Real-World Tombstoning in Silverlight for Windows Phone 7 de Jeff Prorise. Es posible que desee prestar especial atención a la parte 2, donde Jeff habla de aclarar el estado cuando la aplicación se cierra.

+0

gracias por la sugerencia de utilizar IsolatedStorage para desembarque. Aún así, no respondió correctamente el caso para el manejo de tombstoning + tecla de retroceso en cada página que creas. Si se encuentra en OnNavigatedFrom, debe admitir 3 casos: navegando hacia atrás, desechando y navegando hacia otra página. – Buju

+0

Bueno, solo está almacenando el mismo conjunto de valores, por lo que no va a completar el servicio de estado, además, el único momento en que necesita hacer algo está en OnNavigatedFrom, por lo que no será un problema almacenar su estado transitorio en ese punto independientemente.Si el rendimiento se convierte en un problema, entonces estás almacenando las cosas equivocadas en el momento equivocado y en el lugar equivocado :) –

+1

+1: La forma en que lo veo, el diccionario 'PhoneApplicationPage.State' solo debe usarse para guardar cosas como cuánto bajó un ListBox que el usuario había desplazado, o qué PivotItem estaba activo. El proceso de cómputo intensivo, como guardar los datos del modelo de visualización persistente, debe realizarse en el evento 'Application.Deactivated'. – Praetorian

Cuestiones relacionadas