La plupart des applications mobiles sont (logiquement) multipages : que ce soit sur un contrôle de type pivot, panorama, ou une simple navigation entre des pages, il faut prévoir la meilleure façon possible pour l’utilisateur de naviguer entre les pages.

La base de la navigation

Le framework de navigation introduit dans Silverlight 3 a été repris dans Windows Phone 7. On dispose de deux types d’objets : PhoneApplicationFrame et PhoneApplicationPage. Chaque application possède une unique PhoneApplicationFrame et de multiples PhoneApplicationPages.

Dans une application WindowsPhone, chaque PhoneApplicationPage est en général contenue dans sa propre page en XAML. Pour naviguer d’une page à l’autre, il suffit d’appeler la méthode Navigate() de la classe statique NavigationService, qui est contenue dans l’espace de nommage Microsoft.Phone.Navigation.

La base de la navigation se fait donc très simplement de la façon suivante :

NavigationService.Navigate(new Uri("/DetailsPage.xaml", 
UriKind.Relative));

Le passage d’argument entre les pages

Il arrive (c’est même fréquent) qu’on doive passer des arguments entre les pages. Il y a pour cela deux manières de procéder.

La première et la plus simple est de créer un objet qu’on assignera au datacontext de la page vers laquelle on navigue. On pourra ensuite directement binder les éléments de la page cible sur cet objet :

_selectedItem = (sender as ListBox).SelectedItem;
FrameworkElement root = Application.Current.RootVisual 
    as FrameworkElement;
root.DataContext = _selectedItem;

La seconde manière consiste à passer des arguments directement dans l’URI de la page cible. Dans ce cas, dans la page cible, il est possible de récupérer les arguments en utilisant une autre classe statique, le NavigationContext, et notamment sa méthode QueryString. Voici un exemple :

Dans la page principale :

NavigationService.Navigate(new Uri("/DetailsVille.xaml?Ville="
        + ((Ville)listBox1.SelectedItem).Nom + "&Pays=" 
        + ((Ville)listBox1.SelectedItem).Pays, 
        UriKind.Relative));

Et dans la page cible :

string ville = this.NavigationContext.QueryString["Ville"];
stringpays = this.NavigationContext.QueryString["Pays"];

Si l’on veut utiliser des URL « simples » ou de la logique de routage dans le code, il est possible d’utiliser des UriMappers pour refactorer les URL des pages au moment de la navigation. Voici un exemple simple (tiré de la librairie MSDN) qui illustre bien le principe des UriMapper :

<navigation:Frame x:Name="ContentFrame" 
                  Style="{StaticResource ContentFrameStyle}"
Source="/Home" Navigated="ContentFrame_Navigated" 
                  NavigationFailed="ContentFrame_NavigationFailed">
    <navigation:Frame.UriMapper>
        <uriMapper:UriMapper>
            <uriMapper:UriMapping Uri="" 
                                  MappedUri="/Views/Home.xaml"/>
            <uriMapper:UriMapping Uri="/{pageName}" 
                                  MappedUri="/Views/{pageName}.xaml"/>
        </uriMapper:UriMapper>
    </navigation:Frame.UriMapper>
</navigation:Frame>

La gestion du bouton back

La plupart du temps, on peut laisser le système gérer le bouton back. Il reviendra automatiquement en arrière dans la pile des pages. Ceci étant dit, il peut être utile de capturer cet évènement, afin par exemple de reforger une url avec des arguments pour la page appelante, ou pour démarrer le storyboard d’une animation de changement de page.

Dans le handler de l’évènement PhoneApplicationPage_BackKeyPressed, il faut commencer par annuler la navigation par défaut, avant de rajouter son code. Voici un exemple de gestion de l’appui sur le bouton back, tiré du template d’application Windows Phone List Application

private void PhoneApplicationPage_BackKeyPress(object sender, 
    System.ComponentModel.CancelEventArgs e)
{
    // Cancel default navigation
    e.Cancel = true;
    // Do page transition animation
    PageTransitionDetails.Begin();
}

Les différentes manières d’agencer les pages

On peut imaginer plusieurs manières d’agencer les pages d’une application : le plus simple étant justement de ne pas les agencer. Une page remplace l’autre à l’écran et on navigue simplement entre elles de manière plus ou moins linéaire avec des boutons et des menus.

Il est également possible avec Windows Phone 7 d’utiliser d’autres agencements pour vos données, que ce soit sous forme de page ou pas. Les deux contrôles d’agencement de pages les plus connus sont le pivot (comparable à un TabControl) et le panorama (dont les meilleurs exemples sont les hubs)

Il convient cependant de ne pas utiliser ces contrôles n’importe comment : sans qu’il y ait de règle établie, on peut d’une manière générale considérer :

- Le pivot est un moyen efficace d’afficher des données, alors que le panorama est un moyen immersif d’afficher du contenu

- Le panorama peut être considéré comme la « couverture » de votre application, comme la couverture d’un magazine

- Un pivot peut servir de filtre, un panorama peut servir pour naviguer à travers un contenu « éclaté » sur plusieurs vues, et de préférence varié.

- Les panoramas sont faits pour attirer l’utilisateur à l’intérieur de l’application. Les pivots pour séparer les données en catégories, tris, etc.