Le modèle de navigation des applications Windows Phone XAML
Dans la vague de rapprochement entre Windows Phone et Windows, le modèle de navigation de Windows Phone s’est rapproché de celui de Windows. Mais tout d’abord, qu’est-ce qu’un modèle de navigation ?
Présentation
On appelle modèle de navigation l’ensemble des comportements autour de la navigation : lancement de l’application, navigation entre application, navigation à l’intérieur de l’application, gestion d’état.
L’idée directrice lors de ce changement de modèle de navigation est de se rapprocher de Windows mais tout en gardant les spécificités du format téléphone (les utilisateurs n’attendent pas forcément le même comportement qu’une tablette).
Fonctionnement
Du point de vue des classes mises en jeux dans la navigation, adieu la PhoneApplicationFrame et la Page héritées de Silverlight. La navigation se fait désormais dans une Frame qui instancie des Pages, ces deux classes font partie de l’espace de nom Windows.UI.XAML.
La navigation n’est plus basée sur une URI mais plutôt sur le type de la page de destination éventuellement accompagné par un paramètre de navigation.
Spécificités Windows Phone
Par défaut dans Windows Phone les pages ne sont pas mises en cache. Pour les mettre, il faut définir la propriété NavigationCacheMode de la page dans le constructeur de celle-ci. Il est à noter que la page d’accueil est automatiquement mise en cache et ce pour avoir un lancement fluide.
Désormais, le Fast App Resume est activé par défaut, contrairement à la version précédente. Pour rappel, ce mécanisme précise de réutiliser une instance de l’application si elle existe plutôt que d’en créer une nouvelle.
Par rapport à Windows, un téléphone possède toujours un bouton Précedent “Physique” (il peut être physique ou logiciel et géré par l’OS mais considéré physique par le framework). Par conséquent, il ne faut pas proposer de bouton précédent dans l’interface. Il faut à la place s’abonner à l’évènement BackPressed pour déclencher l’action adéquate (un retour arrière dans le journal de navigation par exemple).
Si l’évènement n’est pas traité, un appui sur le bouton physique provoquera une sortie de l’application.
Gestion d’état
Le tombstoning n’existe plus (du moins le mot n’est plus le même), la gestion d’état est la même que sur Windows. Dès que l’application n’est plus au premier plan, elle passe au bout de quelques secondes dans l’état suspendu. Il faut donc sauver l’état et le journal de navigation (via GetNavigationState).
Lors de la reprise de l’application il est nécessaire d’adapter son contenu en fonction de l’état précédent (qui est disponible via l’énumération ApplicationExecutionState).
Dans le cas où celle-ci ne s’exécutait pas (ApplicationExecutionState.NotRunning), un lancement normal est correct.
Si l’application s’exécutait, il est nécessaire de restaurer l’état et le journal de navigation (si cela est pertinent, c’est-à-dire que les données affichés ne sont pas obsolètes).
Il est à noter que dans les cas d’utilisation de ressources exclusives (comme par exemple l’appareil photo), il est nécessaire de libérer la ressource dès que l’application n’est plus au premier plan et de la récupérer lorsqu’elle est restaurée.
Le dernier point très important est le comportement du bouton retour. Par défaut sur Windows Phone, un utilisateur doit toujours revenir à l’endroit où il était avant. Dans le cas d’une navigation entre plusieurs applications cela peut s’avérer complexe.
Exemple :
- L’utilisateur navigue dans votre application MonApp.
- Il bascule sur une autre application AutreApp.
- Il reçoit un toast de MonApp et clique dessus.
- Il arrive à un endroit précis de MonApp (deep linking).
- Dans ce cas-là, le bouton Précédent doit rammener à l’état antérieur : AutreApp (étape 2) et non pas l’état précédent de MonApp (étape 1)
- Une fois de retour dans AutreApp, s’il relance MonApp, il faudra restaurer l’état de MonApp (étape 1)
Pour pallier à ces difficultés, il est possible d’utiliser deux Frames différentes, une pour la navigation normale et une deuxième dans les cas de Deep Linking comme l’arrivée par toast ou par une tuile secondaire.