Le téléphone portable dans tous ses états

Navigation dans Windows Phone : Principes fondamentaux

Yochay Kiriaty

Télécharger l'exemple de code

Les applications Silverlight pour Windows Phone utilisent un modèle de pages semblables au Web, permettant aux utilisateurs finaux de naviguer d'une page à l'autre. Un bouton matériel Retour permet de naviguer facilement vers les pages précédentes (sans prendre de la place à l'écran) et la journalisation (ou l'historique) de votre navigation est intégrée à la plateforme pour faciliter la navigation ou la transition entre différentes applications. Cet article en deux parties a pour objet :

• de vous présenter le modèle de navigation de pages sur Windows Phone,
• de vous fournir les meilleurs méthodes nécessaires pour tirer pleinement profit des API actuelles (telles que l'intégration à l'aide du bouton matériel Retour, le chargement et le déchargement de pages optimisés et l'assurance que votre modèle de navigation répond aux recommandations de la certification Windows Phone),
• et de vous présenter des recettes réalisables et faciles à suivre pour créer les navigations les plus complexes qui ne sont pas implémentées dans les API actuelles, y compris du contenu temporaire et des transitions de pages.

Modèle de navigation de Windows Phone

Le modèle de navigation de Windows Phone est constitué d'un cadre (PhoneApplicationFrame) et d'une ou de plusieurs pages (PhoneApplicationPage) dans lesquelles se trouve le contenu chargé dans le cadre.

Le cadre PhoneApplicationFrame expose la plupart des évènements de navigation, ainsi que la méthode de navigation utilisée pour parcourir les pages. Il détermine également la zone client pour l'application et réserve l'espace pour la barre d'application et la barre d'état système. 

PhoneApplicationPage dispose de notifications spécifiques à chaque page en fonction du moment où l'utilisateur se rend sur la page ou la quitte. Il gère également les évènements en lien avec le bouton matériel Retour.

PhoneApplicationFrame et PhoneApplicationPage partagent tous les deux un service en charge de la navigation elle-même, NavigationService. Windows Phone prend en charge la journalisation (le suivi de l'historique des pages chargées de manière à pouvoir retourner sur une page précédente) et expose des API pour pouvoir revenir en arrière. Le téléphone ne prend pas en charge la navigation vers une page suivante.

Windows Phone présente trois boutons matériels dédiés : Retour, Démarrer et Rechercher. La gestion du bouton matériel Retour implique des exigences de certification d'application spécifiques :

• une application ne devrait pas empêcher l'utilisateur de revenir sur une page précédente. La seule exception possible est une invite lors d'une perte de données (vous pouvez alors inviter à confirmer, puis laisser à l'utilisateur le choix de naviguer en arrière).
• Si une fenêtre contextuelle, le panneau de saisie du logiciel (SIP) ou toute autre boite de dialogue temporaire sont ouverts, une pression sur le bouton matériel Retour devrait faire disparaître cette boite de dialogue sans quitter la page en cours (en annulant en réalité le bouton de navigation Retour).
• Le fait d'appuyer sur le bouton Retour dans le premier écran d'une application doit permettre de quitter celle-ci. Cette fonctionnalité est gratuite. Si vous n'empêchez pas la navigation, l'environnement est à votre service (en fait, il s'agit là de la seule façon de quitter une application Silverlight). Il n'existe pas de méthode Exit dans les API exposées.
• Pour que l'expérience utilisateur (UX) reste cohérente avec les apps, le bouton Retour ne devrait servir qu'à naviguer vers la page précédente.

À l'instar du bouton Retour et de son rôle essentiel dans la navigation, le bouton Démarrer participe également à la navigation. Lorsque l'utilisateur appuie sur le bouton Démarrer, l'application en cours d'exécution est désactivée et un changement de contexte se produit alors que vous naviguez vers le menu Démarrer. À partir de là, un utilisateur peut soit lancer une autre application, dans laquelle il peut naviguer, soit choisir de revenir en arrière (à l'aide du bouton matériel Retour) vers l'application qui s'exécutait précédemment. Cela crée en réalité un modèle de navigation dans lequel le bouton Retour navigue dans les pages d'une application en cours d'exécution ou à travers la pile d'une application exécutée précédemment.

Les API Windows Phone

Comme nous l'avons vu plus haut, la navigation possède deux éléments essentiels : PhoneApplicationFrame et PhoneApplicationPage.

PhoneApplicationFrame se comporte comme le RootVisual pour l'application. Au démarrage, un cadre PhoneApplicationFrame est instancié dans la classe App dans App.xaml.cs (voir figure 1).

Figure 1 Instanciation de RootFrame dans 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;
}

Le runtime navigue automatiquement vers l'instance de PhoneApplicationPage qui est spécifiée par l'attribut NavigationPage dans le DefaultTask sur le manifeste de l'application WMAppManifest.xml, comme montré ici :

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

En s'approchant un peu plus des responsabilités et des API, PhoneApplicationFrame expose la plupart des méthodes de navigation et des évènements dont nous avons besoin pour cet article. La figure 2 répertorie les méthodes, les propriétés et les évènements les plus pertinents dans PhoneApplicationFrame.

Figure 2 Les méthodes, les propriétés et les évènements de PhoneApplicationFrame

Nom	Type	Description
Naviguer	Méthode	Navigue vers une nouvelle page PhoneApplicationPage spécifiée par le paramètre URI. Le paramètre est un URI, un appel Navigate instancie donc en réalité la nouvelle page et navigue vers elle (vous ne lui transmettez pas une page déjà instanciée).
CanGoBack	Propriété en lecture seule	Renvoie true si la pile de retour de l'application (l'historique de journalisation) n'est pas vide. Cela signifie que des utilisateurs ont navigué vers l'avant au moins une fois au sein de l'app. Si l'application est dans la première page chargée dans l'app, CanGoBack renvoie false et vous ne pouvez pas appeler GoBack par le biais de la programmation mais l'utilisateur final peut toujours appuyer sur le bouton matériel Retour et quitter l'application en revenant sur celle exécutée précédemment.
CanGoForward	Propriété en lecture seule	Non applicable à Windows Phone. Renvoie toujours false car la navigation vers l'avant n'est pas prise en charge.
UriMapper	Propriété	Obtient/définit un UriMapper. Cela va dépasse l'objet de cet article mais il est intéressant de mentionner que le mappage URI est pris en charge.
GoBack	Méthode	Navigue vers l'entrée la plus récente de la pile de retour. Cette méthode renvoie une exception s'il n'existe pas d'entrée dans la pile de retour ; vérifiez toujours CanGoForward avant d'appeler cette méthode.
GoForward	Méthode	Non pris en charge dans Windows Phone ; renvoie une exception InvalidOperationException
Navigation	Événement	Se produit lorsqu'une nouvelle navigation est demandée. À ce stade, l'annulation est toujours possible en configurant la propriété Cancel dans le paramètre NavigatingCancelEventArgs sur true. Consultez les notes sur les raisons pour lesquelles vous ne devriez pas annuler les navigations de retour dans cet évènement.
Naviguée	Événement	Se produit lorsqu'une navigation est exécutée. Cela ne signifie pas que le contenu de la page naviguée a été chargé. Cela se produit simplement lorsque le contenu a été trouvé et navigué.
NavigationFailed	Événement	Se produit lorsqu'une erreur a été rencontrée.
NavigationStopped	Événement	Se produit lorsque la navigation est arrêtée soit par l'appel de la méthode StopLoading, soit, ce qui est plus courant, lorsqu'une nouvelle navigation est demandée alors qu'une autre est en cours.

Ceux qui sont familiers avec la classe Frame de Silverlight ne devraient pas être dépaysés par ces méthodes héritées, pour la plupart, de Frame. La liste de la figure 2 n'inclut uniquement les fonctionnalités PhoneApplicationFrame les plus pertinentes pour la navigation.

Procédure de code : Pour voir tous ces évènements et propriétés en œuvre, explorez AllNavigationsEvents.xaml.xs dans l'échantillon de code joint à cet article. La figure 3 montre dans quel ordre les évènements se produisent.

Figure 3 La séquence des évènements pendant que vous naviguez dans les pages

PhoneApplicationFrame détermine également la zone client que l'application obtiendra et réserve l'espace pour la barre d'application et la barre d'état système. Ce détail s'avère pertinent à mesure que nous naviguons dans les pages qui disposent d'une barre d'application, parce qu'elle est spécifiée au niveau de la page et qu'une animation système affiche et masque la barre d'application tandis que la page se charge.

Le deuxième intervenant dans la navigation est PhoneApplicationPage. Il joue deux rôles essentiels dans la navigation :

• la gestion des activations du bouton matériel Retour,
• et la fourniture d'évènements pour le cycle de vie des pages de manière à savoir quand une page est activée/désactivée.

Pour l'intégration avec le bouton matériel Retour, PhoneApplicationPage expose un évènement BackKeyPress. La page dispose également d'une méthode OnBackKeyPress virtuelle qu'il vous est possible de remplacer dans l'instance d'une de vos pages de manière à gérer et même annuler un évènement d'activation du bouton Retour.

PhoneApplicationFrame possède un évènement Navigating et une notification (ou un rappel) OnNavigatingFrom. Au sein des deux, vous pouvez annuler les navigations vers d'autres pages à l'intérieur de l'application en définissant e.Cancel = true dans le paramètre NavigationCancelEventArgs transféré vers ces méthodes ; en raison d'un bogue connu sur la plateforme, il déconseillé d'utiliser ces évènements/méthodes pour annuler des navigations du bouton Retour. Si vous annulez une activation du bouton matériel Retour dans cet évènement, votre navigation stoppera et l'application ne sera pas redémarrée. Pour annuler une activation du bouton matériel Retour, les deux seules méthodes conseillées sont l'évènement PhoneApplicationPageBackKeyPress et le rappel OnBackKeyPress.

Pour consulter la liste des évènements et des méthodes dans lesquels les navigations, ainsi que l'activation du bouton Retour, peuvent être annulées et pour trouver des conseils sur la manière dont il est possible de vérifier s'il s'agissait d'une navigation vers une page précédente, reportez-vous à la figure 4.

Figure 4 Évènements et méthodes dans lesquels les navigations peuvent être annulées

Propriétaire	Évènement/Notification	Peut annuler une nouvelle navigation	Peut annuler des navigations vers une page précédente	Vérifie l'absence de navigations vers une page précédente
PhoneApplicationFrame	Navigation	Oui	Non	Oui ; vérifiez que e.NavigationMode != NavigationMode.Back
PhoneApplicationPage	OnNavigatingFrom	Oui	Non	Oui ; vérifiez que e.NavigationMode != NavigationMode.Back
PhoneApplicationPage	OnBackKeyPress	Non (appelé uniquement lorsque l'activation de la touche Retour est appelée)	Oui	Non nécessaire ; appelé uniquement lorsque l'activation de la touche matérielle Retour est appelée)
PhoneApplicationPage	BackKeyPress (évènement)	Non (appelé uniquement lorsque l'activation de la touche Retour est appelée)	Oui	Non nécessaire ; appelé uniquement lorsque l'activation de la touche matérielle Retour est appelée)

PhoneApplicationPage vient compléter ces évènements afin que le cycle de vie de la navigation se termine avec les rappels de méthode les plus utiles pour la page, OnNavigatedTo and OnNavigatedFrom. Pour mieux comprendre à quel moment ces rappels sont appelés, et pour s'en souvenir facilement, il est conseillé d'ajouter au nom de leur méthode la mention « this page » (cette page). Une méthode est appelée lorsque l'utilisateur a « navigated from this page » (navigué vers cette page) et l'autre sera appelée ultérieurement, lorsque l'utilisateur aura « navigated from this page » (navigué à partir de cette page) vers une autre.

La figure 3 montre la séquence des évènements pendant que vous naviguez dans les pages. Le caractère symétrique de NavigatedTo et NavigatedFrom en fait les méthodes idéales pour le démarrage et l'arrêt d'un travail qui est nécessaire lorsque la page est visible mais pas lorsque la page est dans la pile de retour. Remarquez également que NavigatedTo est toujours déclenchée avant le chargement de la page, alors ne supposez pas que les contenus de la page sont chargés à ce moment-là.

C'est l'existence de la pile de retour qui rend OnNavigatedTo et OnNavigated From essentielles pour Windows Phone. Le système d'exploitation maintient la pile de retour pour les pages vers lesquelles vous pouvez retourner, ce qui implique qu'elles ne sont pas immédiatement déchargées, détruites ou nettoyées de la mémoire lorsqu'une navigation passe d'une page à une autre. Au lieu de cela, les pages sont déplacées vers la pile de retour et gardées actives (en mémoire), si bien que lorsque l'utilisateur clique pour retourner sur cette page, elle est simplement ramenée vers l'arborescence visuelle. La page n'est pas recréée (à moins que l'application ait été désactivée et supprimée entre le moment où l'utilisateur a quitté la page et celui où il a cliqué pour y retourner). Puisque la journalisation de la navigation vers des pages suivantes n'est pas prise en charge, le fait de naviguer d'une page vers la précédente rend la première éligible au nettoyage de mémoire (en imaginant qu'il n'existe aucune autre référence vers cette page).

La figure 5 montre un diagramme illustrant le cycle de vie d'une méthode PhoneApplicationPage.

Figure 5 Le cycle de vie de PhoneApplicationPage

Lorsque que vous naviguez de la page 1 à la page 2, puis à la 3, les pages ne sont pas nettoyées de la mémoire avant que vous ayez appelé la méthode GoBack. Stockées dans la pile de retour, les pages inactives sont toujours en mémoire. Si ces pages sont à l'écoute des évènements globaux, les écouteurs d'évènements sont toujours actifs.

En dépit du fait qu'une page n'est pas nettoyée de la mémoire lorsque vous la quittez, elle n'est plus ni visible ni active jusqu'au moment où vous retournez dessus, vous devriez donc vous assurer de procéder au nettoyage et à la libération de ressources coûteuses lorsque l'utilisateur a quitté une page. Par exemple, si vous utilisez GeoCoordinateWatcher pour écouter les changements d'emplacement, vous devriez arrêter l'écouteur sur OnNavigatedFrom, puis le redémarrer lorsque l'utilisateur retourne sur votre page (et que votre page OnNavigatedTo est appelée).

Procédure de code : Pour voir comment les pages sont conservées en mémoire pendant qu'elles sont dans la pile de retour, parcourez la page GarbageCollectedSample fournie avec le téléchargement du code d'accompagnement. Elle conserve un décompte des pages en mémoire que vous pouvez voir croître à mesure que vous naviguez d'une page vers une autre et décroître lorsque vous retournez en arrière.

Ceci conclue la première partie de notre série. Le mois prochain, nous nous pencherons sur la navigation avancée.

Yochay Kiriaty est développeur technique chez Microsoft et se concentre sur des technologies client telles que Windows et Windows Phone. Il a coécrit les livres « Présentation de Windows 7 pour les développeurs » (Microsoft Press, 2009) et « Learning Windows Phone Programming » (Apprentissage de la programmation dans Windows Phone) (O'Reilly Media, 2011).

Jaime Rodriguez est développeur technique chez Microsoft et conduit l'adoption de technologies client émergentes telles que Silverlight et Windows Phone. Vous pouvez le joindre sur Twitter : @jaimerodriguez ou sur blogs.msdn.com/jaimer.

Je remercie notre expert technique d'avoir relu cet article : Peter Torr