Asuntos móviles

Navegación con Windows Phone: conceptos básicos

Yochay Kiriaty

Descargar el ejemplo de código

Las aplicaciones de Silverlight de Windows Phone tienen un modelo de página similar al de las páginas web, donde los usuarios finales se desplazan de una página a otra. Existe un botón dedicado de hardware, denominado Atrás, destinado para navegar fácilmente a las páginas anteriores (sin gastar espacio de la pantalla) y el registro (o historial) de la navegación está integrado con la plataforma, para facilitar la navegación o transición entre distintas aplicaciones. En este artículo de dos partes:

• Le presentaremos el modelo de navegación de páginas en Windows Phone.
• Le proporcionaremos los procedimientos recomendados para sacarle el máximo provecho a su API actual, lo que incluye la integración con el botón del hardware Atrás, la carga y descarga optimizada de páginas y el aseguramiento de que su modelo de navegación satisfaga las directivas de certificación de Windows Phone.
• Le presentaremos recetas fáciles de seguir que se puedan realizar para crear las navegaciones más complejas que no están implementadas a las API actuales, lo que incluye contenido transitorio y transiciones de página.

Modelo de navegación de Windows Phone

El modelo de navegación de Windows Phone consiste en un marco (PhoneApplicationFrame) y una o más páginas (PhoneApplicationPage) que mantienen los contenidos cargados en el marco.

PhoneApplicationFrame expone la mayor parte de los eventos de navegación y el método Navigate que usará para desplazarse entre páginas. También determina el área de cliente para la aplicación y reserva el espacio para la barra de aplicación y la bandeja de sistema. 

PhoneApplicationPage tiene notificaciones específicas para página para cuando se navega hacia una página y cuando se sale de ella. También controla los eventos relacionados con el botón de hardware Atrás.

Tanto PhoneApplicationFrame y PhoneApplicationPage comparten un NavigationService, este servicio es el que en realidad realiza la navegación. Windows Phone es compatible con el registro (el seguimiento del historial de páginas cargadas, de manera que se pueda volver a una página anterior) y expone las API de manera que pueda volver. Phone no es compatible con la navegación hacia delante.

Windows Phone tiene tres botones de hardware dedicados: Atrás, Iniciar y Buscar. Existen requisitos específicos de certificación de aplicación para controlar el botón de hardware Atrás:

• Una aplicación no debe impedirle al usuario volver a una página anterior. La única excepción posible es una consulta donde esté implicada la pérdida de datos: podrá solicitar la confirmación y permitir acceso al usuario si desea navegar en retroceso.
• Si es un elemento emergente, el Software Input Panel (SIP) u otro diálogo transitorio está abierto, presionar el botón de hardware Atrás debe descartar el cuadro pero no abandonar la página actual (lo que, en efecto, cancela la navegación del botón Atrás).
• Presionar el botón Atrás mientras se está en la primera pantalla de una aplicación debe cerrarla. Esta funcionalidad es gratuita. Si no se impide la navegación, el marco procede a salir por usted; lo que es más, esta es la única manera de salir de una aplicación Silverlight. No existe un método Exit en la API expuesta.
• Para mantener una experiencia de usuario (UX) coherente para todas las aplicaciones, el botón Atrás sólo se debe usar para navegar en retroceso.

Además del rol crucial del botón Atrás para la navegación, el botón Iniciar también participa en la navegación. Cuando el usuario presiona el botón Inicio, la aplicación en ejecución se desactiva y se realiza un cambio de contexto al navegar hacia delante al menú Inicio. Desde aquí, un usuario puede iniciar otra aplicación y navegar desde la aplicación nueva o puede escoger navegar hacia atrás (usando el botón de hardware Atrás) a la aplicación que estaba en ejecución. Esto tiene como resultado la creación de un modelo de navegación donde el botón Atrás recorre las páginas de una aplicación en ejecución o a través de la pila de aplicaciones que estaban en ejecución.

API de Windows Phone

Como se indicó anteriormente, los principales actores en la navegación son PhoneApplicationFrame y PhoneApplicationPage.

PhoneApplicationFrame actúa como RootVisual para la aplicación. En el inicio, se crea la instancia de PhoneApplicationFrame en la clase App, en App.xaml.cs (ver la figura 1).

Figura 1 Creación de instancia de RootFrame en App.xaml.cs

private void InitializePhoneApplication()
{
  if (phoneApplicationInitialized)
        return;

  // Create the frame but don't set it as RootVisual yet; this allows the splash
  // screen to remain active until the application is ready to render.
  RootFrame = new PhoneApplicationFrame();
  RootFrame.Navigated += CompleteInitializePhoneApplication;

           
  // Handle navigation failures
  RootFrame.NavigationFailed += RootFrame_NavigationFailed;

  // Ensure we don't initialize again
  phoneApplicationInitialized = true;
}

El tiempo de ejecución navega automáticamente a la instancia de PhoneApplicationPage, lo cual se especifica en el atributo NavigationPage en DefaultTask del manifiesto de aplicación WMAppManifest.xml, como se indica aquí:

<Tasks>
  <DefaultTask  Name ="_default" NavigationPage="MainPage.xaml"/> 
</Tasks>

Si nos aproximamos a las responsabilidades y las API, PhoneApplicationFrame expone la mayor parte de los métodos y los eventos de navegación que necesitaremos para este artículo. La figura 2 indica los métodos, las propiedades y los eventos más pertinentes de PhoneApplicationFrame.

Figura 2 Métodos, propiedades y eventos de PhoneApplicationFrame

La mayor parte de ellos se hereda de Frame, de manera que aquellos que estén familiarizados con la clase Frame de Silverlight reconocerán a estos métodos. La lista de la figura 2 no incluye todas las características de PhoneApplicationFrame, sólo las relacionadas con la navegación.

Tutorial del código: Para ver todos los eventos y las propiedades en acción, explore AllNavigationsEvents.xaml.cs en el código de ejemplo que está agregado a este artículo. También podrá ver el orden en el que se inician estos eventos en la figura 3.

Figura 3 La secuencia de eventos que transcurren al navegar entre páginas

PhoneApplicationFrame también determina el área de cliente que la aplicación obtendrá y reserva el espacio de la barra de aplicación y de la bandeja de sistema. Este detalle se volverá pertinente a medida que naveguemos entre páginas que tengan una barra de aplicación, puesto que está especificado en el nivel de la página y existe una animación de todo el sistema para mostrar y ocultar la barra de aplicación a medida que se carga una página.

El segundo actor en la navegación es PhoneApplicationPage. Juega dos papeles cruciales en la navegación:

• Control de la presión del botón de hardware Atrás.
• Entrega de eventos de ciclo de vida de página con la finalidad de saber si una página está activada o desactivada.

Para la integración con el botón de hardware Atrás, PhoneApplicationPage expone un evento BackKeyPress. La página también tiene un método virtual OnBackKeyPress que se puede omitir en la instancia de una página para controlar e incluso cancelar un evento de presión del botón Atrás.

PhoneApplicationFrame tiene un evento Navigating y una notificación/devolución de llamada OnNavigatingFrom. En ambos se puede cancelar navegaciones a otras páginas de la aplicación al configurar e.Cancel = true en el parámetro NavigationCancelEventArgs que se pasa a estos métodos. Debido a un conocido error en la plataforma, no se debe cancelar las navegaciones del botón Atrás desde estos eventos/métodos. Si cancela la presión del botón de hardware Atrás en este evento, se interrumpirá la navegación y se deberá reiniciar la aplicación. Los únicos dos métodos recomendados para cancelar la presión del botón de hardware Atrás son el evento BackKeyPress de PhoneApplicationPage y la devolución de llamada OnBackKeyPress.

Consulte la figura 4 para ver una lista de eventos y métodos donde se puede cancelar la navegación, con recomendaciones sobre si se puede cancelar la presión de Atrás y concejos sobre cómo confirmar si el evento fue una navegación en retroceso.

Figura 4 Eventos y métodos en los que se puede cancelar la navegación

PhoneApplicationPage complementa estos eventos para completar el ciclo de vida de navegación con las devoluciones de llamada de los métodos OnNavigatedTo y OnNavigatedFrom a la página. Para comprender mejor y recordar más fácilmente cuando se llaman a estas devoluciones de llamada, lo óptimo es completar los nombres de método con un "esta página". Un método se llama cuando el usuario “navegó a esta página” y después se llama al otro método cuando el usuario “navega desde esta página” a otra.

La Figura 3 muestra la secuencia de eventos que transcurren al navegar entre páginas. La simetría entre NavigatedTo/NavigatedFrom hace que estos dos métodos sean ideales para empezar y finalizar el trabajo necesario cuando la página es visible, pero no es necesario cuando la página está en la pila de retroceso. Observe también que NavigatedTo siempre se inicia antes de que ser cargue una página, entonces no suponga que el contenido de la página se carga en este momento.

La razón por la cual OnNavigatedTo y OnNavigatedFrom son cruciales para Windows Phone es debido a la pila de retroceso. El SO mantiene la pila de retroceso de páginas a las cuales se puede volver, de manera que las páginas no se descarguen inmediatamente, destruyan o se recopilen los elementos no usados cuando ocurra la navegación de una página a la otra. En lugar de esto, las páginas se mueven a la pila de atrás y se mantienen activos (en la memoria) y cuando el usuario hace clic para volver a esa página, esta simplemente se agrega al árbol visual. No se vuelve a crear la página (a no ser que se desactive y se haya aplicado un marcador de exclusión a la aplicación en el intertanto que el usuario dejara la página e hiciera clic en Atrás). Dado que no se admite el registro hacia delante, las páginas son elegibles para la recopilación de elemento no utilizados al navegar de una página hacia la página anterior (suponiendo que no hay otras referencias a la página).

La figura 5 muestra un diagrama que ilustra el ciclo de vida de una PhoneApplicationPage.

Figura 5 El ciclo de vida de PhoneApplicationPage

Al navegar desde Page1 a Page2 y después a Page3, no se recopila la información no utilizada de las páginas hasta que se llame al método GoBack desde la página. Las páginas inactivas están en la pila de retroceso, pero aún están en memoria. Si estas páginas están escuchando eventos globales, los escuchas de eventos seguirán estando activos.

Pese a que no se recopile la información no utilizada de una página al abandonarla, esta dejará de ser visible o activa hasta que se navegue de regreso, por lo tanto debe asegurarse de hacer cualquier clase de limpieza y de lanzamiento de recursos de alto gasto cuando el usuario haya abandonado una página. Por ejemplo, si está escuchando a los cambios de localización usando GeoCoordinateWatcher, debe detener al escucha en OnNavigatedFrom y volver a iniciarlo cuando el usuario navegue de regreso a la página y se llame a la página OnNavigatedTo.

Tutorial del código: Para ver cuántas páginas se retienen en la memoria mientras están en la pila de retroceso, explore la página GarbageCollectedSample que se incluye en la descarga de código adjunto. Este mantiene en ejecución un recuento de páginas en la memoria y podrá ver que aumenta a medida que se dirige a nuevas páginas y disminuye al volver atrás desde una de ellas.

Eso concluye la primera parte de nuestra serie. En el próximo mes nos enfocaremos en temas avanzados de navegación.

Yochay Kiriaty es un evangelista técnico senior de Microsoft, que se enfoca en tecnologías de cliente tales como Windows y Windows Phone. Él es coautor de los libros “Introducing Windows 7 for Developers” (Microsoft Press, 2009) y “Learning Windows Phone Programming” (O’Reilly Media, 2011).

Jaime Rodríguez es un evangelista principal de Microsoft para la dirección de la adopción de tecnologías de cliente emergentes, tales como Silverlight y Windows Phone. Puede ponerse en contacto con el por Twitter: @jaimerodriguez o en blogs.msdn.com/jaimer.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Peter Torr