Localisation d’une application XAML

Il existe de très nombreuses façons de localiser une application, que ce soit pas le code-behind ou même le XAML et il n’est pas nécessaire ici de refaire une passe sur toutes ces solutions. je vais parler ici de la plus simple et bien souvent la plus propre car elle simplifie le code au maximum mais elle demande de la rigueur notamment dans la maintenance du fichier de ressource et spécifiquement sur le nom des clés. Voyons pourquoi.

La solution la plus simple de localiser votre application est de définir l’attribut x:Uid sur tous les éléments que vous souhaitez localiser. Que ce soit un bouton, un textblock ou tout autre élément, votre objet peut avoir cet attribut et celui-ci va correspondre à la clé du fichier de ressource pour retourner une chaine de caractère spécifique.

Pour se faire commencez par ajouter un fichier de ressource à votre projet (Ajouter > nouveau élément > Fichier de ressource)

Puis dans ce fichier, ajoutez vos clés et la chaine traduite puis notez la spécificité des clés de la capture suivante :

Vous remarquerez que ertaines clés finissent par .Text. C’est par ce suffixe que le moteur XAML va savoir, grâce à l’attribut x:Uid, aller chercher la clé puis utiliser le suffixe pour déterminer l’attribut de l’élément à localiser. Pour être plus clair, pour localiser le texte d’un label et d’un bouton comme ci-dessous

<TextBlock x:Uid=”Cle1” />

<Button x:Uid=”Cle2” />

Les clés devront s’appeler

Il est ainsi permis de localiser n’importe quel attribut d’un élément XAML. Par contre, cela demande une bonne organisation du fichier de ressource car si un label est utilisé à la fois sur un bouton et un label, du fait que l’attribut visé sera différent, le nom de la clé aussi et finalement l’information devra être dupliquée.

Le cas particulier de l’application bar

L’application bar est un cas particulier et je n’aurai personnellement jamais trouvé la solution sans notre évangéliste de choc David Catuhe. Voici les détails.

Un bouton d’AppBar XAML Metro ressemble au code suivant :

<Button x:Name="Add" Style="{StaticResource AddAppBarButtonStyle}" >

Avec un style qui redéfinit les propriétés d’automation pour définir le label du bouton (Automation.Name)

<UserControl.Resources>
...
    <Style x:Key="WebViewAppBarButtonStyle" TargetType="Button" 
           BasedOn="{StaticResource AppBarButtonStyle}">
        <Setter Property="AutomationProperties.Name" Value="Votre texte"/>
        <Setter Property="Content" Value="&#xE12B;"/>
    </Style>
</UserControl.Resources>

Sauf que, comme expliqué plus haut le mécanisme de localisation se base sur le nom de la clé, ce qui donnerait dans notre cas NotreCle.Automation.Name et là... c’est le drame. En effet, le moteur XAML n’apprécie pas du tout d’avoir deux fois un “.” dans la clé car il ne sait pas s’il doit chercher un attribut Name ou un attribut Automation.Name. Nous sommes bloqués.

Du fait des mécanismes internes concernant les propriétés d’automation notamment que le fait que la valeur de Automation.Name est automatiquement prise depuis la valeur de la propriété Content, il peut être tentant de passer par cette propriété mais dans ce cas, impossible d’utiliser la propriété Content pour afficher une image grâce à la police Segoe UI par exemple.  Encore bloqués.

La solution de se passer complètement d’un label n’étant pas une solution viable, il me fallait trouver autre chose tout en restant au maximum dans la mentalité du full XAML (sans code-behind). La solution se trouve simplement dans une syntaxe non documentée qui permet de localiser un champ non accessible normalement :

VotreCle.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name

Ainsi dans notre cas et notre bouton about, la clé sera “AppBar-General-About.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name” tandis que le XAML ressemblera à ceci

<Button  x:Name="About" 
                Style="{StaticResource AboutAppBarButtonStyle}" 
                x:Uid="AppBar-General-About" 
               ...>
 </Button>

Quid des message box?

Contrairement aux Winforms où vous étiez obligés d’avoir une partie (notamment les boutons OK, Cancel, Oui, Non, etc.) liés non pas à la langue de votre application mais à celle du système, les applications Metro vont vous permettre de localiser le contenu de ces boutons mais surtout d’en rajouter autant que vous voulez en leur assignant des actions, simplement avec une classe de ce type :

public static class MessageBox
        {
            /// <summary>
            /// Display a error messagebox
            /// </summary>
            /// <param name="title"></param>
            /// <param name="message"></param>
            public static async Task<bool> Show(string title, string message)
            {
                MessageDialog dialog = new MessageDialog(message, title);
                bool result = false;
                dialog.Commands.Add(
                new UICommand(Localizer.GetKey("General-OK"), new UICommandInvokedHandler((cmd) => result = true)));
                dialog.Commands.Add(
                   new UICommand(Localizer.GetKey("General-Cancel"), new UICommandInvokedHandler((cmd) => result = false)));
                await dialog.ShowAsync();
                return result;
            }

            /// <summary>
            /// Display a error messagebox with additionnal commands
            /// </summary>
            /// <param name="title"></param>
            /// <param name="message"></param>
            public static async void Show(string title, string message, List<UICommand> commands, int defaultCommandIndex)
            {
                MessageDialog dialog = new MessageDialog(message, title);
                foreach (UICommand comm in commands)
                {
                    dialog.Commands.Add(comm);
                }

                if (defaultCommandIndex <= (commands.Count - 1))
                {
                    dialog.DefaultCommandIndex = (uint) defaultCommandIndex;
                }

                await dialog.ShowAsync();
            }
        }

Ainsi, il vous faudra donc user de ces trois techniques pour localiser complètement votre application mais vous pourrez ainsi permettre à l’utilisateur d’avoir une application complètement traduite dans la langue de son choix, même si son système ne gère pas cette langue.

Et pour le HTML5?

Et bien pour le HTML5, un mécanisme plus ou moins similaire a été mis en place et il devient très simple de localiser son application.

Je vous encourage également à lire l’article très clair de David Catuhe concernant ce sujet ou bien vous inspirer du sample du SDK concernant la localisation.

- Louis-Guillaume Morand -

Hier, Microsoft a mis a disposition une version preview (moins avancé qu’une beta!) de Windows 8, son futur système d’exploitation. Celui-ci, optimisé pour les PC et les tablettes, capable de fonctionne sur de nouveaux types de processeurs comme ARM, vient surtout avec une interface graphique entièrement revue utilisant le style allégé dit “Metro” .

Malheureusement, certains rétifs au changement (dont moi) voudraient retrouver le menu de Windows 7, si fonctionnel! mais en gardant le menu démarrer de Windows 8 avec le panel de Widgets

Pour le faire, c’est assez simple:

1. ouvrer la fenêtre de commande (Win + R)
2. tapez “regedit”
3. Allez à la clé HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
4. Changez la valeur de la clé RPEnabled de 1 à 0

Le système prend cela en compte tout de suite, pas besoin de redémarrer. Pour le faire marcher, il faut cliquer sur la touche Windows une fois, pour faire apparaitre le menu metro, puis encore une fois pour revenir au bureau avec le menu Démarrer Classique. Et voilà!:

In my case, I prefer the old menu and I’d like to keep the new start menu screen (with the widgets) but to be allowed to use the classic menu with its lovely finder as well.

To do that, you just need :

1. to open a command prompt (Win + R)
2. to type “regedit”
3. To go to the key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
4. To change the value of the key RPEnabled from 1 to 0

The change is applied without having to restart the computer. To display the old menu, you just have to click the Win key once to display the Metro menu, then to click the Win key again. And voilà!

Une fois téléchargé l’iso de votre choix, vous pouvez utiliser au choix Virtual PC ou Virtual Box pour les fans du 64 bits et créer une machine virtuelle. Si le paramétrage de la machine virtuelle semble basique, vous risquez d’avoir une belle erreur au moment de l’installation notamment avec l’écran suivant :

La solution est toute simple, il faut revoir le paramétrage de la machine virtuelle et voici la liste des paramètres primordiaux:

Version du système:

L’activation des IO-APIC

et la mémoire graphique (si possible au moins 64Mo)

et vous voilà avec le minimum requis pour installer et posséder une machine virtuelle sous Windows 8.

A noter que j’ai par ailleurs laissé les paramètres par défaut mis par Virtual Box mais qu’il peut être nécessaire d’activer l’option VT-x /AMD-v ainsi que PAE/NX pour améliorer les performances. Il en va de même pour les accélérations 2D et 3D que j’ai pour le moment laissés désactivés.

Il est temps de voir ce que cette preview, non finie et non optimisée pour les perfs, a dans le ventre!

Cet article fait partie d’une série d’articles sur le développement Windows Phone. Il s’agit d’une traduction des articles se trouvant sur la MSDN.

Sommaire

Bien débuter et fondamentaux

• Bien démarrer (Hello World)
• Créer une interface utilisateur pour Windows Phone en XAML
• Utiliser des contrôles
• Types de contrôles
• Contrôles Panorama et Pivot
• Travailler avec du texte sur le Windows Phone
• Mise en page sur l’écran
• Orientations de l’écran
• Saisie tactile
• Navigation
• Exécuter votre application en arrière-plan (tombstoning)
• Notifications Push pour le développement Windows Phone
• Publier votre application sur le Marketplace

Visuels et média

• Images
• Animations
• Vidéo et Audio
• Graphiques
• Pinceaux

Travailler avec les données

• Obtenir des données dans vos applications Windows Phone
• Data binding
• Isolated storage
• Accéder à un service Web REST
• Consommer des données Windows Azure

Sondes et autres fonctionnalités spécifiques au téléphone

• Lanceurs et choosers
• Détecter des mouvements (accéléromètres)
• Développer avec le GPS Windows Phone (Services de localisation)
• Développer avec l’appareil photo du Windows Phone

Développer avec le GPS Windows Phone (Services de localisation)

Silverlight pour Windows Phone inclut un espace de nom qui fournit la gestion et la surveillance en temps réel du service de localisation du téléphone. Le service de localisation fournit l'information la plus précise possible sur l'actuelle position du téléphone en utilisant une combinaison de données Wi-Fi et du réseau cellulaire, ainsi que des données GPS (Global Positionning System). Le service de localisation récupère la latitude, longitude, altitude, vitesse de déplacement, de direction et expose ses données au travers de l'espace de nom System.Devices.Location.

Créer une application Windows Phone utilisant la localisation signifie que certaines fonctionnalités de votre application seront sujettes à la disponibilité des données de localisation. Parce que le service de localisation se base sur les signaux satellites et cellulaires, il est important d'écrire du code qui gère les scénarios suivants:

• L'utilisateur a coupé le GPS ou le récepteur cellulaire sur le téléphone.
• La force du signal est trop faible pour recevoir les données de localisation.
• Le service de localisation est encore en cours d'initialisation ou attend que les données de localisation arrivent jusqu'au téléphone.

Nous allons coder cette application d'une façon qui autorise l'utilisateur à gérer ces scénarios.

Cette QuickApp est une application qui reçoit des données du service de localisation de Windows Phone 7, et positionne les données sur une carte pendant qu'il donne une information visuelle des données. Cet article est divisé en chapitres:

• Créer une interface utilisateur pour la lecture du service de localisation
• Obtenir des données du service de localisation en temps réel
• Considérations finales

Téléchargez le code complet de cette application ici.

Procédure pas à pas

Pour voir un exemple de ce quickstart exécuté sur un réel téléphone, et pour construire cette application en suivant une vidéo plutôt que de continuer à lire cet article, vous pouvez visionner la vidéo suivante. La page pour cette vidéo sur Channel 9 a plusieurs options de téléchargement si vous voulez une version en haute définition ou si vous voulez une version lisible sur des périphériques mobiles.

Créer une interface utilisateur pour la lecture du service de localisation

Lancez Visual Studio et démarrez un projet de type "Silverlight for Windows Phone". Créez alors une interface utilisateur qui contient les éléments suivants:

• Six champs TextBlock avec des libellés compréhensifs pour la lecture de la longitude, de la latitude, de la vitesse et des données de statut.
• Un objet Map sur lequel nous placerons un Pushpin affichant la position actuelle du téléphone.

o Note: Vous aurez besoin d'une clé Bing Maps pour pouvoir utiliser le contrôle carte. Pour en obtenir une, suivez les instructions de l'article Obtenir une clé Bing Maps. Une fois que vous avez une clé, qui est simplement une chaine de caractères, entrez-la en tant que valeur pour la propriété CredentialsProvider dans le code XAML qui définit l'objet Map. Un exemple est fourni dans l'article Accédez au contrôle grâce à une clé Bing Maps.

• Deux Buttons avec un libellé explicite qui vont être utilisés pour démarrer et arrêter le service de localisation ainsi que démarrer le positionnement en temps réel du téléphone sur la carte.
• Des TextBlocks pour afficher les informations récupérées.

Une proposition du positionnement de ces éléments est fournie ci-dessous. Ici, la valeur par défaut des six TextBlocks est changée pour montrer le format et les paramètres utilisés par le service de localisation (par exemple, "Mètres par secondes" est la valeur par défaut pour la vitesse ainsi c'est clair).

Pour faire fonctionner le XAML ci-dessus, vous devez définir l'espace de nom "my:Map" qui est utilisé en ajoutant un attribut xmlns sur le tag phone:PhoneApplicationPage en haut du document XAML qui définit l'UI, tel que:

En dernier recours, si Visual Studio ne l'a pas fait pour vous lorsque vous avez ajouté les éléments, ajoutez une référence vers Microsoft.Phone.Controls.Maps. Silverlight pour Windows Phone utilise l'assembly Microsoft.Phone.Controls.Maps pour fournir une fonctionnalité de cartographie, qui doit être référencée par votre application avant que l'un de ses types, évènements ou méthodes ne puisse être utilisés par votre code.

Pour ajouter Microsoft.Phone.Controls.Maps à votre application:

1. Dans l'explorateur de Solution, cliquez à l'aide du bouton droit de la souris sur le nœud Références de votre projet et sélectionnez Ajouter référence.
2. Sélectionnez Microsoft.Phone.Controls.Maps depuis la liste et cliquez sur OK.

Note: Visual Studio devrait automatiquement ajouter l'attribut xmlns et la référence vers Microsoft.Phone.Controls.Maps dès que vous ajoutez le contrôle Map sur l'interface en la glissant depuis la barre d'outils sur le designer.

Obtenir des données du service de localisation en temps réel

Dans l'explorateur de solutions, ouvrez le fichier xaml.cs file, et ajoutez les trois lignes de code suivantes en haut de la page.

Cela permet à votre code C# d'accéder au contrôle Bing Maps, à l'API du service de localisation et au modèle de Threading, tout ce que nous utiliserons pour cette application.

L'utilisation du service de localisation nécessitera de la coordination au travers de quelques méthodes et c'est pourquoi nous allons ajouter quelques membres à la classe principale. Le plus notable sera l'objet GeoCoordinateWatcher, qui reçoit constamment les informations du service de localisation dès qu'il est démarré par la méthode TryStart(), que nous allons étudier dans un moment. Nous allons appeler notre watcher. Dès que notre guetteur (watcher) a été démarré, il va essayer de récupérer des informations depuis le service de localisation et exposer ces informations via ses différentes propriétés, ainsi que déclencher l'évènement PositionChanged lorsque l'information de position est mise à jour (c’est-à-dire lorsque le périphérique change de lieu).

Ce membre doit être au niveau de la classe car plusieurs méthodes vont être impliquées dans la lecture des données service de localisation pour gérer les différents évènements que le service va déclencher.

En complément, nous surveillerons si l'utilisateur a activé le tracking sur la carte, et il s'agira encore un membre de classe. Finalement, nous utiliserons le même objet Pushpin tout au long de l'application car nous n'en avons besoin que d'un seul, et nous mettrons à jour sa position continuellement dans différentes méthodes, et sera donc instancié au niveau de la classe. Les trois membres ressemblent à ceci dans le code:

Comme indiqué, il y aura plusieurs méthodes qui utiliseront notre watcher. Pour être exact, il y en aura trois:

1. Une méthode qui gère l'évènement PositionChanged du watcher et analyse les nouvelles données. Nous appellerons cette méthode watcher_PositionChanged.
2. Une méthode qui gère l'évènement StatusChanged, qui se déclenche lorsque le service de localisation change d'état (inactif, initialisation, réception de données, etc.). Nous appellerons cette méthode watcher_StatusChanged.
3. Une méthode qui gèrera le démarrage du watcher par lui-même dans son propre thread. Bien que cette méthode ne fasse qu'une ligne de code, nous voulons compartimenter ce code pour qu'il puisse être lancé dans son propre thread et ne bloque pas l'application pendant que le service de localisation s'initialise. Nous appellerons cette méthode startLocServInBackground.

Nous pourrions vouloir faire cela dès que l'application démarre donc mettons-les dans le constructeur, la méthode MainPage().

Deux lignes supplémentaires sont nécessaires pour instancier le watcher et mettre à jour l'interface à propos de l'initialisation du service de localisation, laissant la méthode MainPage() ressembler à ceci:

Il est maintenant temps d'implémenter les gestionnaires d'évènements. Commençons avec watcher_StatusChanged. watcher donnera son statut à la méthode watcher_StatusChanged en utilisant un objet GeoPositionStatusChangedEventArgs passé en argument. Cet objet a une propriété enum appelée GeoPositionStatus qui fournit des noms compréhensibles pour les différents états du service de localisation. Tout ce que nous voulons faire dans notre application est de notifier l'utilisateur lorsque le statut a changé et nous pouvons accomplir cela avec un seul switch qui gère les quatre valeurs possibles GeoPositionStatus:

Maintenant que nous pouvons voir ce qui va se passer lorsque le service de localisation sera activé et que l'évènement StatusChanged est déclenché, implémentons la méthode qui s'occupe de l'initialisation et que l'on appellera startLocServInBackground. Cette méthode consistera en une seule ligne qui appelle la méthode TryStart de notre watcher, en spécifiant un timeout de 60 secondes pour l'initialisation. Parce que la méthode TryStart est synchrone, cela pourrait bloquer l'application sur une longue période si nous ne l'avions pas la lancer en arrière-plan, d'où l'utilisation d'un nouveau thread dans l'appel de startLocServInBackground dans la méthode MainPage. Le thread que nous avons démarré dans MainPage sera automatiquement arête avec la période de timeout de la method TryStart ou lorsque le watcher est initialisé avec succès et l’évènement watcher_StatusChanged est déjà implémenté pour gérer tout ce qui passe après l’initialisation :

Avant que nous n'implémentions watcher_PositionChanged, câblons deux boutons qui vont affecter le comportement de l'application lorsque le téléphone change de position. Nous appellerons ces deux boutons "Track Me On Map" et "Stop LocServ," et dans le XAML, vous verrez que nous avons spécifié des gestionnaires pour l'évènement Click pour chacun de ces boutons, nommés respectivement trackMe_Click et startStop_Click.

Ces deux méthodes sont liées à l'activation et la désactivation du service de localisation, la valeur booléenne trackingOn ainsi que watcher_PositionChanged met à jour ou non l'objet carte pour afficher la position actuelle du téléphone. De plus, un petit travail d'interface est fait pour modifier l'affichage du bouton et fournir un message de statut.

Un appel intéressant à l'objet Map est fait dans la méthode trackMe_Click. Si l'utilisateur spécifie qu'il veut voir sa position actuelle sur la carte, le niveau de zoom sur la carte passe de 1.0 (zoom arrière pour montrer la planète entière) à 16.0 (zoom au niveau des rues).

L'activation du service de localisation se fait encore en arrière-plan en utilisant startLocServInBackground. Les deux méthodes ressemblent à ceci:

Enfin, il y a la méthode watcher_PositionChanged qui gère l'évènement PositionChanged,. Cette méthode reçoit des informations à propos de la position actuellement dans l'objet GeoPositionChangedEventArgs, qui est passé en argument. Cet objet contient les informations à propos du périphérique, sa longitude, sa latitude, sa vitesse (en mètres par seconde), sa direction (une valeur flottante entre 0 et 360) et même l'altitude (en mètres au dessus du niveau de la mer). Nous allons afficher toutes ces données dans l'écran que nous avons créé plus tôt.

De plus, si l'utilisateur a cliqué le bouton "Track Me On Map", alors la variable trackingOn est définie à "true," et que la carte est zoomée au niveau de la rue, ainsi, dans la méthode watcher_PositionChanged nous vérifions la valeur trackingOn' et centrons la carte sur notre position actuelle si sa valeur est true. La méthode finale ressemble à ceci:

Cette application est maintenant complète et vous avez un exemple de programme qui est structuré pour répondre à l'initialisation synchrone du service de localisation, pour garder trace du statut courant du service (qui est sujet à la qualité des signaux GPS et cellulaire) et aussi pour positionner une punaise sur une carte Bing qui affiche à la demande les rues ou la vue satellite.

Considérations finales

• Nous utilisons le paramétrage high-accuracy dans cette application ce qui consommé rapidement la batterie du telephone. Essayez d’utiliser GeoPositionAccuracy.Default autant que possible, comme par exemple lorsque votre application recherche dans les environs.
• Le paramétrage MovementThreshold est un élément clé de la consommation de la batterie, parce qu'en général, les données de position sont conséquentes et l’application ne devrait pas répondre à chaque fluctuation des données. Si l’évènement PositionChanged est déclenché trop fréquemment, la batterie et le temps de processeur seront consommés avec gâchis.
• Parce que le service de localisation utilise une combinaison de données Wi-Fi, cellulaires et GPS, la position devient de plus en plus précise après que le service ait été démarré et au fur et à mesure qu'il reçoit des données. Les informations de réseau Wi-Fi et cellulaire sont généralement reçues en quelques secondes pendant que les données GPS peuvent prendre plusieurs minutes.
• L'objet GeoCoordinateWatcher déclenche des évènements dans le thread UI. Cela signifie que vous voudrez réaliser le moins de travail possible dans les fonctions de gestionnaires des évènements PositionChanged et StatusChanged, ou n'importe quel autre évènement GeoCoordinateWatcher. Si un traitement important a besoin d'être fait lorsque ces évènements sont déclenchés, ayez des fonctions de traitement agissant dans des threads d'arrière-plan pour éviter que l'interface ne se fige.

Voir aussi

• Source Code For This QuickApp
• System.Device.Location Namespace (Reference Docs)
• Bing Maps Silverlight Control (Reference Docs)
• Location for Windows Phone (How To Docs)

Cliquez ici pour revenir au sommaire de la liste d’articles

Cet article fait partie d’une série d’articles sur le développement Windows Phone. Il s’agit d’une traduction des articles se trouvant sur la MSDN.

Sommaire

Bien débuter et fondamentaux

• Bien démarrer (Hello World)
• Créer une interface utilisateur pour Windows Phone en XAML
• Utiliser des contrôles
• Types de contrôles
• Contrôles Panorama et Pivot
• Travailler avec du texte sur le Windows Phone
• Mise en page sur l’écran
• Orientations de l’écran
• Saisie tactile
• Navigation
• Exécuter votre application en arrière-plan (tombstoning)
• Notifications Push pour le développement Windows Phone
• Publier votre application sur le Marketplace

Visuels et média

• Images
• Animations
• Vidéo et Audio
• Graphiques
• Pinceaux

Travailler avec les données

• Obtenir des données dans vos applications Windows Phone
• Data binding
• Isolated storage
• Accéder à un service Web REST
• Consommer des données Windows Azure

Sondes et autres fonctionnalités spécifiques au téléphone

• Lanceurs et choosers
• Détecter des mouvements (accéléromètres)
• Développer avec le GPS Windows Phone (Services de localisation)
• Développer avec l’appareil photo du Windows Phone

Consommer un service Windows Azure Data avec OData

Le protocole Open Data (OData) est basé sur une entité et un modèle de relation qui vous permet d'accéder à des données REST. OData autorise l'utilisation protocole standard HTTP pour exécuter des requêtes, et même créer, mettre à jour et supprimer des données depuis un service de données. En utilisant la bibliothèque de client OData pour Windows Phone, votre application peut consommer des données d'un service Windows Azure ou n'importe quel autre service qui supporte le protocole OData. La bibliothèque cliente génère des requêtes HTTP vers un service OData et transforme les données dans le flux de réponse en objets sur le client.

Remarque

Le client OData pour Windows Phone 7 est disponible en tant que bibliothèque séparée, que vous pouvez télécharger et installer depuis la page Open Data Protocol—client libraries.

Ce tutoriel contient les sections suivantes:

• Survol des services OData pour Windows Phone
• Lier des données aux contrôles
• Pagination et Navigation
• Maintenir l'état d'application
• Générer les classes de données du client

Les exemples de ce tutoriel utilisent Silverlight dans un navigateur pour simuler le comportement sur Windows Phone. Le résultat peut être sensiblement différent sur un périphérique Windows Phone.

Survol des services OData pour Windows Phone

Les applications pour périphériques mobiles se basent énormément sur des sources de données distantes, et la plateforme Windows Azure fournit une excellente source de données pour vos applications Windows Phone. OData est l'un des principaux mécanismes d'accès aux données de la plateforme Windows Azure. Plusieurs composants de la plateforme Windows Azure fournissent des flux OData, incluant Windows Azure Table Storage, Microsoft SQL Azure, et Windows Azure Marketplace DataMarket. Une liste des flux OData est disponible sur site Web du protocole Open Data.

Vous pouvez aussi utiliser des services de données WCF pour exposer vos propres données en tant que flux OData qui peuvent être consommées par des applications qui s'exécutent sur une variété de plateformes, incluant Windows Phone. Pour plus d'informations, lisez WCF Data Services.

Comme exemple, Netflix expose leur catalogue de films en tant que flux OData hébergé dans le Cloud. Nous consommons ce flux OData public dans l'exemple suivant:

Cliquez la tuile OData sur le téléphone pour démarrer l'exemple OData. Sur le téléphone, lorsque vous tapez le bouton Next Page, la page suivante est chargée depuis le service de données. Lorsque vous cliquez sur un élément de la liste, les informations détaillées de l'élément sélectionné sont affichées. Dans cet exemple, le bouton Back du téléphone, agit comme il le fait sur le téléphone en vous faisant revenir à la page précédente. Vous pouvez télécharger le projet complet dans la galerie de code Silverlight for Windows Phone.

Lier des données aux contrôles

Dans la bibliothèque cliente Odata pour Windows Phone 7, la classe DataServiceCollection représente une collection dynamique de données liées, qui fournit des notifications lorsque des éléments sont ajoutés ou supprimés de la collection. Une requête basée sur une URI détermine quelles données la collection va contenir. Cette URI est spécifiée en tant que paramètre dans la méthode LoadAsync de la classe DataServiceCollection. Lorsqu'elle est exécutée, cette méthode retourne un flux OData qui est matérialisé par des objets de données dans la collection liée. Les objets matérialisés sont gérés par la classe DataServiceCollection qui s'assure que les résultats sont envoyés sur le bon thread et ainsi vous n'avez pas besoin d'un objet Dispatcher. Pour plus d'informations sur l'utilisation de bibliothèque OData, lisez l'article Open Data Protocol (OData) Overview for Windows Phone.

Parce que les applications Windows Phone requièrent une navigation entre différentes pages, vous devriez utiliser un design pattern Model-View-ViewModel (MVVM) pour vos applications de données. Dans ce pattern, le modèle est généré par des outils basés sur les metadata retournées par le service de données, la vue est formée par tous les contrôlés liés de la page, et le ViewModel est un composant partagé qui s'occupe d'accéder au service de données et expose les données qui sont liées à la vue. En utilisant cette approche, vous pouvez exposer le DataServiceContext en tant que propriété de la classe ViewModel, à côté des propriétés qui retournent des instances de DataServiceCollection ou n'importe quelles autres valeurs dynamiques qui sont liées aux contrôles dans la vue. Le viewModel doit aussi exposer toutes les propriétés qui doivent être enregistrées lorsque l'application est désactivée, ce que nous discuterons dans une section plus loin. Le diagramme objet suivant représente la classe MainViewModel de notre exemple:

La classe MainViewModel elle-même est exposée en tant que propriété statique de la classe d'application racine (app), comme montrée dans le code suivant:

Le ViewModel est définit sur le DataContext de la page qui nous permet de lier le contrôle Listbox à la DataServiceCollection retournée par la propriété Titles de la classe MainViewModel. Vous pouvez voir dans l'exemple suivant que la Listbox et quelques autres éléments sont liés aux propriétés du MainViewModel:

Lorsque la page MainPage.xaml se charge, la propriété IsDataLoaded property de la vue est vérifiée. Lorsque les données ne sont pas encore chargées, la méthode LoadData est appelée pour définir le binding, et demande la liste de titre du service de données.

Lorsque la méthode LoadAsync est appelée, la bibliothèque client envoie une requête asynchrone au service OData qui retourne un flux Atom des entrées Titles. Lorsque la réponse est reçue, l'évènement LoadCompleted est déclenché et les entrées dans le flux sont matérialisées par le client dans des objets dans la collection de Titles, qui est liée au contrôle ListBox.

OData définit un mécanisme pour accéder aux données binaires séparément de l'entité à laquelle elles appartiennent. De cette façon, un service de données peut exposer de nombreuses données binaires en tant que ressources média qui appartiennent à une entrée de lien média. Dans le catalogue Netflix, l'entité Title est une entrée de lien média avec une ressource média liée, qui est la couverture du titre. La méthode GetReadStreamUri du viewmodel appelle la méthode GetReadStreamUri sur le DataServiceContext pour retourner l'URI de la ressource média.

Dans cet exemple, la propriété StreamUri appelle la méthode GetReadStreamUri pour retourner l'URI de ressource qui est une image de couverture. Lorsque nous lions la propriété StreamURI à l'attribut Source d'un contrôle Image, l'URI retournée est utilisée pour télécharger et afficher la couverture pour chaque titre.

Recommandation

Pour une entrée de lien média, nous recommandons que vous obteniez l'URI de la ressource en appelant la méthode GetReadStreamUri() plutôt qu'une autre propriété de l'entité. Bien que l'URI de la ressource média marche bien dans ce cas pour créer une image sur le client, d'autres méthodes du DataServiceContext peuvent être utilisées pour accéder et changer les ressources média en tant que stream binaire.

Paging et Navigation

Dans cet exemple, l'URI de requête est construite en utilisant les paramètres de pagination définis dans l'application. Dans OData, il existe deux sortes de paging. Un client peut utiliser les options de requête $top et $skip pour limiter le nombre d'entrées dans la réponse dans une page logique plutôt que l'ensemble des données. Le service de données lui-même peut aussi limiter le nombre d'entrées retournées par une réponse donnée, lorsque la réponse contient un token (jeton) de continuation qui est utilisé pour obtenir la page suivante de données à partir du service de données.

Parce que le client n'est pas capable de déterminer si un service de données implémente un paging piloté par le serveur ou simplement la taille d'une page, vous devriez considérer à implémenter un paging côté client dans vos applications Windows Phone pour s'assurer qu'aucune requête ne retourne un trop gros ensemble de données, ce qui prendrait du temps et consommerait les ressources du téléphone. Vous devriez aussi être préparé à prendre en compte du paging côté serveur dans votre application.

L'exemple suivant montre la méthode GetQueryUri() qui retourne l'URI de requête, qui est créée en se basant sur les variables passées aux paramètres $top et $skip.

Dans cet exemple, la taille de page est fixe et le nombre d'entrée à sauter est calculé en fonction du nombre de la page courante. Lorsque nous chargeons la première page, nous incluons l'option de requête $inlinecount=allpages pour demander le compte total de toutes les entités Titles, qui est utilisée pour calculer le nombre de pages qui est affiché dans TitlesPage.xaml.

Lorsque la réponse est reçue, le client déclenche l'évènement LoadCompleted. Lorsqu'il est nécessaire de charger des pages supplémentaires à cause du paging côté serveur, la propriété Continuation de l'objet DataServiceCollection retourne un token(jeton) de continuation. La méthode suivante gère l'évènement LoadCompleted pour charger les pages:

Notez que nous lisons aussi et enregistrons la valeur TotalCount lorsque celle-ci est demandée dans la requête. Cette valeur est utilisée pour calculer et afficher le nombre total de pages. Parce qu'une version de TotalCount mise à jour change la valeur de la propriété PagesLoadedText, nous reportons aussi ce changement jusqu'au binding.

La page de données suivante est demandée lorsque l'utilisateur appuie sur le bouton Next Page. Vous pourriez créer un nouvel objet DataServiceCollection basé sur l'URI qui retourne la page suivant, l'exemple suivant utilise au contraire la navigation pour charger une page spécifique de données:

Cette navigation recharge principalement la page MainPage.xaml avec la page suivante.

En utilisant la navigation pour charger les pages suivantes, lorsque l'utilisateur clique sur le bouton Retour, le comportement par défaut est de recharger la page précédente. Sans la navigation, vous auriez besoin de surcharger la méthode OnBackKeyPress pour charger la page précédente.

Lorsque l'utilisateur clique sur un titre dans le contrôle ListBox, la méthode suivante navigue vers la page TitlesDetailPage.xaml pour le titre sélectionné :

Dans la page TitleDetailsPage.xaml, la valeur de l'index sélectionné est utilisée pour lier le bon Title depuis la collection de Titles, comme ceci :

Maintenir l'état d'application

Le système d'exploitation Windows Phone permet seulement à une seule application de s'exécuter à un moment donné. Lorsque l'utilisateur quitte une application, le système éteint cette application. Pour permettre à l'application d'être réactivée correctement, les données chargées, les informations d'état des objets et certaines propriétés du ViewModel doivent être stockées dans le dictionnaire d'état. Le client OData pour Windows Phone 7 introduit une classe DataServiceState qui est utilisée pour stocker le DataServiceContext et une collection d'objets DataServiceCollection. La méthode suivante SaveState dans le ViewModel retourne cet objet DataServiceState dans une collection clé-valeur d'éléments, ainsi que d'autres données du ViewModel qui doivent être persistées:

La méthode suivante gère l'évènement Deactivated et appelle la méthode SaveState pour stocker les données du viewmodel lorsque l'application est désactivée:

Lorsque l'application est réactivée, le ViewModel est récupéré depuis le dictionnaire d'état. La méthode suivante gère l'évènement Activated et restaure l'application dans son ancien état:

Dans la méthode RestoreState suivante, l'objet DataServiceState et les autres données enregistrées sont acquises depuis le dictionnaire d'état global et utilisées pour réinitialiser le viewmodel:

Générer les classes de données du client

Vous pouvez utiliser l'outil DataSvcUtil.exe pour générer les classes de données dans votre application qui représente le modèle de données d'un service OData. Cet outil, qui est inclut avec les bibliothèques OData sur CodePlex, se connecte au service de données et génère les classes de données et le containeur de données, qui hérite de la classe DataServiceContext. La commande suivante génère le modèle de données client basé sur le service OData Netflix:

Command

DataSvcUtil.exe /out:"Netflix.cs" /uri:"http://odata.netflix.com/v1/Catalog" /language:csharp /DataServiceCollection /version:2.0

En utilisant le paramètre /DataServiceCollection dans la commande, les classes DataServiceCollection sont générées pour chaque collection dans le modèle.

L'outil DataSvcUtil.exe génère le containeur de données avec le même nom que l'espace de nom du schéma. Pour simplifier les références, l'espace de nom des classes de données générées ont été modifiées manuellement.

Voir aussi

• Open Data Protocol Web site.
• Netflix public catalog as OData feeds.
• Implementing the Model-View-ViewModel Pattern in a Windows Phone Application.
• How to: Consume an OData Service for Windows Phone.

Cliquez ici pour revenir au sommaire de la liste d’articles

Cet article fait partie d’une série d’articles sur le développement Windows Phone. Il s’agit d’une traduction des articles se trouvant sur la MSDN.

Sommaire

Bien débuter et fondamentaux

• Bien démarrer (Hello World)
• Créer une interface utilisateur pour Windows Phone en XAML
• Utiliser des contrôles
• Types de contrôles
• Contrôles Panorama et Pivot
• Travailler avec du texte sur le Windows Phone
• Mise en page sur l’écran
• Orientations de l’écran
• Saisie tactile
• Navigation
• Exécuter votre application en arrière-plan (tombstoning)
• Notifications Push pour le développement Windows Phone
• Publier votre application sur le Marketplace

Visuels et média

• Images
• Animations
• Vidéo et Audio
• Graphiques
• Pinceaux

Travailler avec les données

• Obtenir des données dans vos applications Windows Phone
• Data binding
• Isolated storage
• Accéder à un service Web REST
• Consommer des données Windows Azure

Sondes et autres fonctionnalités spécifiques au téléphone

• Lanceurs et choosers
• Détecter des mouvements (accéléromètres)
• Développer avec le GPS Windows Phone (Services de localisation)
• Développer avec l’appareil photo du Windows Phone

Data Binding

La plupart des applications Windows Phone affichent des données dans les contrôles. Dans de nombreux cas, les données sont des objets business tels que des actions en bourse, des titres de news ou des images. En plus, vous voulez souvent autoriser l'utilisateur à sélectionner un élément depuis une liste puis afficher les détails relatifs à cet élément dans un autre contrôle comme par exemple une zone de texte.

Ce tutoriel montre comment lier un contrôle à un simple élément et comment lier un contrôle de liste à une collection d'éléments, De plus, vous verrez au sein de cet article comment personnaliser l'affichage des éléments, comment implémenter une vue détaillée basée sur une sélection et comment convertir les données avant de les afficher.

Ce tutoriel contient les sections suivantes:

• Lier un contrôle à un élément unique
• Lier un contrôle à une collection d'objets
• Afficher les éléments dans un contrôle en utilisant un data template
• Ajouter une vue détails
• Convertir des données pour les afficher dans des contrôles

Lier un contrôle à un élément unique

Une liaison de données (data binding) consiste en une source et une cible. La cible du binding est généralement une propriété d'un contrôle et doit être une DependencyProperty.

L'exemple suivant montre un contrôle lié à un élément unique. La cible est la propriété Text d'un contrôle Textbox. La source est une simple classe Recording.

Voici le résultat:

Pour afficher un enregistrement musical dans une zone de texte, la propriété Text du contrôle est définie sur un Binding en utilisant une extension de balisage (markup extension). Dans cet exemple, le mode de binding par défaut est BindingMode.OneWay, ce qui signifie que les données sont récupérées de la source, mais les changements ne sont pas propagés vers la source. Pour plus d'informations sur les markup extensions et leur syntaxe, lisez l'article MSDN Binding Markup Extension.

La classe Recording possède trois propriétés publiques et une surcharge de la méthode ToString(). Les propriétés sont Artist, Name, et ReleaseDate. La méthode ToString est importante car si aucun formatage n'est spécifié, la méthode ToString est appelée sur un objet lié pour des raisons d'affichage. La propriété Binding.Source n'est pas définie directement, au contraire, la propriété FrameworkElement.DataContext de la TextBox est paramétrée sur un nouvel objet Recording.

Lier un contrôle à une collection d'objets

L'exemple suivant démontre la syntaxe que vous utilisez pour lier des données à un contrôle mais n'est pas très réaliste. Un scénario plus commun est de lier une collection d'objets métier. La classe générique ObservableCollection est un bon choix pour le data binding car elle implémente les interfaces INotifyPropertyChanged et INotifyCollectionChanged. Ces interfaces fournissent les notifications de changement aux contrôles liés lorsque qu'un élément de la liste ou une propriété de la liste elle-même change. Si vous voulez que vos contrôles liés se mettent à jour lorsque les propriétés des objets de la collection changent, alors ces objets doivent également implémenter INotifyPropertyChanged.

L'exemple suivant lie une collection d’enregistrements musicaux à une ComboBox. Cliquez sur la flèche de la combobox pour voir la liste des éléments liés.

Pour afficher les enregistrements musicaux dans la ComboBox, la propriété ItemsControl.ItemsSource est définie sur un Binding, et la propriété FrameworkElement.DataContext du contrôle ComboBox est définie sur une collection d'objets Recording. Un ComboBoxItem est créé pour chaque élément de la collection. La méthode ToString est automatiquement appelée sur chaque objet Recording à afficher dans l'item de la combobox.

Afficher les éléments dans un contrôle en utilisant un data template

Vous pouvez afficher les éléments dans une liste en utilisant la méthode ToString() de chaque élément. Néanmoins, le scénario le plus courant est de fournir un affichage personnalisé grâce à l'utilisation d'un DataTemplate. Un DataTemplate vous permet de personnaliser la façon dont les éléments sont affichés dans le contrôle. Typiquement, vous définissez le data template en utilisant la propriété ContentControl.ContentTemplate d'un contrôle de contenu ou la propriété ItemsControl.ItemTemplate d'un contrôle à éléments.

L'exemple suivant montre la même liste d’enregistrements liés à une combobox en utilisant un data template. Une combobox est un ItemsControl, ce qui signifie que vous établissez un data template pour chaque élément en définissant sa propriété ItemTemplate sur un data template. Pour essayer cet exemple, cliquez sur la flèche du bas pour voir la liste des enregistrements. Notez comment l'enregistrement apparait différemment de l'exemple suivant. L'artiste et le nom du CD sont affichés dans un format personnalisé.

Dans le XAML, vous pouvez voir la définition du data template. Le data template contient un StackPanel avec quatre contrôles TextBlock. Le StackPanel a une orientation horizontale pour que les quatre blocs de texte apparaissent côte à côte. Deux des contrôles TextBlock sont liés aux propriétés Artist et Name de l'objet Recording. Les deux autres contrôles TextBlock affichent du texte statique. Pour chaque élément lié, le binding fournit le chemin vers la propriété sur l'objet Recording. Comme dans l'exemple précédent, ce binding se base sur le fait que le data context soit lié à la liste des objets Recordings.

Ce XAML utilise la syntaxe par propriété d'élément. Pour plus d'informations sur cette syntaxe, lisez le tutoriel XAML QuickStart.

Ajouter une vue détails

Pour afficher les détails d'un élément lorsqu'il est sélectionné dans une collection, vous devez créer une UI appropriée et lier l'UI aux données que vous voulez afficher. De plus, vous devez utiliser une CollectionViewSource en tant que contexte de données pour permettre à la vue détails de lier l'élément courant.

L'exemple suivant montre la même liste d'enregistrements mais cette fois la liste est la source de données d'une instance de CollectionViewSource. Le contexte de données de l'élément racine du layout est défini sur la CollectionViewSource et la combobox ainsi que la vue détails héritent du contexte de données de l'élément racine. Cela permet à la combobox d'afficher la liste d'éléments pendant que la vue détails affiche les informations de l'élément courant.

Dans cet exemple, un StackPanel est ajouté au user control qui contient la combobox existante. Un Rectangle sert de ligne de division sous la ComboBox. A côté se trouve un StackPanel qui contient quatre blocs pour afficher les détails de l'enregistrement. La propriété TextBlock.Text de chaque bloc de texte est liée à une propriété de l'objet Recording.

Convertir des données pour les afficher dans des contrôles

Si vous voulez formater et afficher un type non-string dans un contrôle, tel qu'un textbox, vous pouvez utiliser un convertisseur. Par exemple, vous pourriez afficher un label et une date formatée plutôt que la date. (Note : vous pouvez utiliser la propriété BindingBase.StringFormat si vous souhaitez uniquement modifier le format de la date.)

L'exemple suivant montre l'implémentation d'un convertisseur pour la date de sortie dans la liste des enregistrements. Pour essayer cet exemple, cliquez sur la flèche du combobox et sélectionnez un élément différent. Notez que l'affichage de la date dans la liste déroulante et dans la vue détaillée est affiché dans un format personnalisé.

Un convertisseur (converter) est une classe qui implémente l'interface IValueConverter. IValueConverter possède deux méthodes : Convert et ConvertBack. Pour un binding unidirectionnel (one-way) de la source vers la cible, vous n'avez besoin que d'implémenter la méthode Convert. Le convertisseur dans cet exemple est très générique. Vous pouvez passer la chaine de formatage comme paramètre et le convertisseur utilisera la méthode Format pour effectuer la conversion. Si aucune chaine de formatage n'est passée alors le convertisseur appelle simplement la méthode ToString() sur l'objet.

Une fois que vous implémentez le convertisseur, vous créez une instance de la classe du convertisseur et dites au binding d'utiliser cette instance. Dans cet exemple, ceci est effectué en XAML. Une instance du convertisseur est créée en tant que ressource statique et est assignée à une clé. La clé est utilisée lorsque la propriété Converter est définie par le binding.

Pour plus d'informations sur l'utilisation des convertisseurs, lisez la documentation IValueConverter sur MSDN.

Voir aussi

• Data Binding
• XAML Overview
• Controls
• Controls and Dialog Boxes
• Object Positioning and Layout

Cliquez ici pour revenir au sommaire de la liste d’articles

Cet article fait partie d’une série d’articles sur le développement Windows Phone. Il s’agit d’une traduction des articles se trouvant sur la MSDN.

Sommaire

Bien débuter et fondamentaux

• Bien démarrer (Hello World)
• Créer une interface utilisateur pour Windows Phone en XAML
• Utiliser des contrôles
• Types de contrôles
• Contrôles Panorama et Pivot
• Travailler avec du texte sur le Windows Phone
• Mise en page sur l’écran
• Orientations de l’écran
• Saisie tactile
• Navigation
• Exécuter votre application en arrière-plan (tombstoning)
• Notifications Push pour le développement Windows Phone
• Publier votre application sur le Marketplace

Visuels et média

• Images
• Animations
• Vidéo et Audio
• Graphiques
• Pinceaux

Travailler avec les données

• Obtenir des données dans vos applications Windows Phone
• Data binding
• Isolated storage
• Accéder à un service Web REST
• Consommer des données Windows Azure

Sondes et autres fonctionnalités spécifiques au téléphone

• Lanceurs et choosers
• Détecter des mouvements (accéléromètres)
• Développer avec le GPS Windows Phone (Services de localisation)
• Développer avec l’appareil photo du Windows Phone

Data Binding

La plupart des applications Windows Phone affichent des données dans les contrôles. Dans de nombreux cas, les données sont des objets business tels que des actions en bourse, des titres de news ou des images. En plus, vous voulez souvent autoriser l'utilisateur à sélectionner un élément depuis une liste puis afficher les détails relatifs à cet élément dans un autre contrôle comme par exemple une zone de texte.

Ce tutoriel montre comment lier un contrôle à un simple élément et comment lier un contrôle de liste à une collection d'éléments, De plus, vous verrez au sein de cet article comment personnaliser l'affichage des éléments, comment implémenter une vue détaillée basée sur une sélection et comment convertir les données avant de les afficher.

Ce tutoriel contient les sections suivantes:

• Lier un contrôle à un élément unique
• Lier un contrôle à une collection d'objets
• Afficher les éléments dans un contrôle en utilisant un data template
• Ajouter une vue détails
• Convertir des données pour les afficher dans des contrôles

Graphiques

Dans Windows Phone 7, il existe plusieurs options pour créer des formes et les dessiner à l’écran. Ce tutoriel introduit les formes telles que les ellipses, les rectangles, les polygones et les chemins. Il se concentre sur la création de graphique en utilisant du XAML.

Remarque

Si vous faites beaucoup de graphiques, vous voudrez probablement utiliser un outil WYSIWYG tel que Expression Blend pour Windows Phone. Un outil WYSIWYG génère juste le XAML, et c’est pourquoi comprendre le fonctionnement interne du XAML est intéressant.

Ce tutoriel contient les sections suivantes:

• Introduction aux graphiques
• Ellipses
• Rectangles et contours
• Polygones
• Polylines
• Paths
• Le thread graphique

Introduction aux graphiques

Il existe deux ensembles de classes qui définissent une région d’espace : Shape et Geometry. La principale différence entre ces classes est qu’un Shape a un pinceau (brush) associé et peut être affiché à l’écran, tandis qu’un objet Geometry définit simplement une région d’espace et n’est pas affiché. Vous pouvez voir un Shape comme un UIElement avec ses limites définies par un Geometry. Ce tutoriel ne parlera que des classes Shape.

Les différentes classes Shape sont Line, Ellipse, Rectangle, Polygon, Polyline, et Path. Path est intéressant dans le sens où il permet de définir une forme de votre choix.

Pour qu’un objet Shape soit affiché à l’écran, un objet Brush doit lui être associé. La propriété Fill du Shape est définie sur l’objet Brush désiré. Les différents types de pinceaux de Silverlight pour Windows Phone sont: SolidColorBrush, LinearGradientBrush, RadialGradientBrush, et ImageBrush.
Pour plus d’informations sur les classes Shape et Geometry, lisez les sujets suivants sur MSDN:

• Shapes and Drawing
• Geometries
• Path Markup Syntax

Ellipses

Pour créer une Ellipse basique, spécifiez simplement les propriétés Width, Height, et un Brush pour la propriété Fill.

L’exemple suivant créé une Ellipse avec une largeur (Width) de 300 pixels, une hauteur (Height) de 300 pixels, et utilise un objet SBlue de type SolidColorBrush pour sa propriété Fill.

Rectangles et contours

Silverlight vous autorise à arrondir les coins d’un Rectangle. Pour créer des coins arrondis, specifies une valeur pour les propriétés RadiusX et RadiusY. Ces propriétés spécifient les axes X et Y d’une ellipse qui définit la courbe des coins. La valeur maximum de la propriété RadiusX est la valeur de Width divisée par deux et la valeur maximum de la propriété RadiusY est celle de Height divisée par deux.

Toutes les classes Shape ont des propriétés Stroke et StrokeThickness. Stroke spécifie le pinceau (Brush) qui est utilisé pour peindre la bordure de la forme. StrokeThickness spécifie l'épaisseur de cette bordure.

Remarque

Un objet Line affiche seulement un objet Stroke, et non l’objet Fill, car il n'a pas d'espace intérieur. Pour afficher une ligne (Line), assurez-vous que les propriétés Stroke et StrokeThickness sont spécifiées.

Dans l'exemple suivant, on créé un Rectangle avec une largeur Width de 100 et une hauteur Height de 50. Il utilise un pinceau SolidColorBrush pour le remplissage Fill et un pinceau noir pour le contour Stroke. La propriété StrokeThickness est définie sur 3 pixels et les propriétés RadiusX et RadiusY sur 10, ce qui donne au Rectangle des coins arrondis.
L'image suivante montre un Rectangle avec des coins arrondis affichés sur un Windows Phone.

Polygones

Un Polygon est une forme avec une limitation définie par un nombre arbitraire de points. La limitation est créée en connectant une ligne entre un point et le suivant, le dernier point étant relié au tout premier. La propriété Points définie la collection de points qui forment cette limitation. En XAML, vous définissez les points avec une liste séparée par des points. En code, vous utilisez un objet PointCollection, collection à laquelle vous ajoutez les points un par un.

L'exemple suivant créé un Polygon avec quatre points définis sur (10,200), (60,140), (130,140), et (180,200). Il utilise un pinceau bleu (SolidColorBrush) pour son remplissage (Fill). Aucun Stroke n'est défini et il est donc possible d'arranger les points pour que rien ne soit affiché. Si un Stroke est défini, au moins une ligne ou un point aussi fin que le Stroke est défini. Utilisez les sliders dans l'exemple pour expérimenter avec les coordonnées des différents points. Notez également que si vous cochez la case Stroke le dernier point est connecté au premier.

Polylines

Un objet Polyline est similaire à un Polygon dont les limites de la forme sont définies par une série de point. La principale différence entre un Polyline et un Polygon est que le dernier point d'un Polyline n'est pas connecté au premier point. La propriété Fill d'un Polyline peint toujours l'intérieur de la forme même si les extrémités des limites (ou Stroke) ne se touchent pas.

Comme avec un Polygon, la propriété Points définie la collection de points qui forment les limitations. En XAML, vous définissez les points avec une liste séparée par des virgules. En code, vous utilisez un objet PointCollection dans lequel vous ajoutez chaque Point pour former la collection.

L'exemple suivant créé un Polyline avec quatre points définis sur (10,200), (60,140), (130,140), et (180,200). La propriété Fill n'est pas définie mais un Stroke l'est. Notez que le dernier et le premier point ne sont pas connectés comme ils le sont pour un Polygon. Utilisez les slides dans cet exemple pour expérimenter avec les coordonnées des différents points. Comparez les différences entre un Polyline et Polygon lorsque les cases Fill et Stroke sont cochées

Paths

Un objet Path est la forme (Shape) la plus versatile parce qu’elle vous permet de définir une géométrie arbitraire. Pourtant, avec cette liberté vient également une complexité accrue. Cette section vous montre comment créer un Path basic en XAML. Pour voir cet objet en profondeur, lisez les articles MSDN Path Markup Syntax et Shapes and Drawing.

La géométrie d’un chemin est définie avec la propriété Data. La propriété Data peut être définie sur un objet Geometry ou en XAML. Pour définir un chemin en XAML, vous utilisez la syntaxe de "path markup".

L'exemple suivant créé un Path qui est basé sur une courbe de Bezier et un segment. L'attribut Data commence avec la commande Move, indiqué par un M, qui établit un point de départ pour le path. La lettre majuscule M indique une position absolue pour le nouveau point courant. La lettre majuscule M indique une position absolue du point courant. Un “m” minuscule indique une position relative. Le premier segment est une courbe de Bézier cubique qui commence à (100,200) et finit à (400,175), et qui est dessinée en utilisant les points de contrôle (100,25) et (400,350). Ce segment est indiqué par la commande C dans les attributs de Data. Une fois encore, la lettre majuscule C indique un chemin en position absolue, la lettre minuscule indique un chemin relatif.

Le second segment commence avec une commande (H) de ligne horizontale, qui signifie une ligne dessinée à partir de la fin du précédent segment (400,175) vers un nouveau point (280,175). Parce qu'il s'agit d'une commande de ligne horizontale, la valeur spécifiée est une coordonnée X (ordonnée).

Remarque

Les paramètres de données des path sont sensibles à la casse.

L'image suivante montre le Path, affiché dans un Windows Phone.

Le thread graphique

Une des différences entre Silverlight pour Windows Phone et Silverlight pour navigateur Web est que les graphiques du téléphone (et quelques animations) s'exécutent dans un thread différent. Pour la plupart des scénarii, vous n'aurez pas besoin de vous en soucier car le système le fait pour vous. Mais si votre application possède un grand nombre de graphiques, il existe des considérations de design et de performance qu'il vous faudra prendre en compte.

Pour plus d'informations à propos du thread de composition, lisez la MSDN Graphics in Silverlight for Windows Phone.

Pour plus d’informations sur les performances lisez l'article Performance Considerations in Applications for Windows Phone.

Voir aussi

• Shapes and Drawing
• Geometries
• Path Markup Syntax

Cliquez ici pour revenir au sommaire de la liste d’articles

Cet article fait partie d’une série d’articles sur le développement Windows Phone. Il s’agit d’une traduction des articles se trouvant sur la MSDN.

Sommaire

Bien débuter et fondamentaux

• Bien démarrer (Hello World)
• Créer une interface utilisateur pour Windows Phone en XAML
• Utiliser des contrôles
• Types de contrôles
• Contrôles Panorama et Pivot
• Travailler avec du texte sur le Windows Phone
• Mise en page sur l’écran
• Orientations de l’écran
• Saisie tactile
• Navigation
• Exécuter votre application en arrière-plan (tombstoning)
• Notifications Push pour le développement Windows Phone
• Publier votre application sur le Marketplace

Visuels et média

• Images
• Animations
• Vidéo et Audio
• Graphiques
• Pinceaux

Travailler avec les données

• Obtenir des données dans vos applications Windows Phone
• Data binding
• Isolated storage
• Accéder à un service Web REST
• Consommer des données Windows Azure

Sondes et autres fonctionnalités spécifiques au téléphone

• Lanceurs et choosers
• Détecter des mouvements (accéléromètres)
• Développer avec le GPS Windows Phone (Services de localisation)
• Développer avec l’appareil photo du Windows Phone

Data Binding

La plupart des applications Windows Phone affichent des données dans les contrôles. Dans de nombreux cas, les données sont des objets business tels que des actions en bourse, des titres de news ou des images. En plus, vous voulez souvent autoriser l'utilisateur à sélectionner un élément depuis une liste puis afficher les détails relatifs à cet élément dans un autre contrôle comme par exemple une zone de texte.

Ce tutoriel montre comment lier un contrôle à un simple élément et comment lier un contrôle de liste à une collection d'éléments, De plus, vous verrez au sein de cet article comment personnaliser l'affichage des éléments, comment implémenter une vue détaillée basée sur une sélection et comment convertir les données avant de les afficher.

Ce tutoriel contient les sections suivantes:

• Lier un contrôle à un élément unique
• Lier un contrôle à une collection d'objets
• Afficher les éléments dans un contrôle en utilisant un data template
• Ajouter une vue détails
• Convertir des données pour les afficher dans des contrôles

Images

Dans Silverlight pour Windows Phone 7, vous avez plusieurs options pour afficher des images telles que des photos ou des diagrammes. Ce tutoriel décrit comment intégrer des images dans vos applications Windows Phone.

Ce tutoriel contient les sections suivantes:

• Image et ImageBrush
• Etirer une image
• Rogner une image
• Appliquer un masque d’opacité
• Créer des WriteableBitmaps

Image et ImageBrush

Pour afficher une image, vous pouvez utiliser au choix un objet Image ou un objet ImageBrush. L’exemple suivant montre comment afficher une image nommée licorige.jpg en utilisant un objet Image.

La capture suivante montre le résultat dans l’émulateur.

Dans cet exemple, la propriété Source spécifie l’emplacement de l’image que vous voulez afficher. Vous pouvez spécifier la Source avec un chemin absolu (par exemple, http://contoso.com/myPicture.jpg) ou en spécifiant l’URL d’un fichier qui est inclut dans le fichier XAP. Pour ajouter une image à votre application, effectuez les opérations suivantes dans Visual Studio:

1. Dans le menu Projet, sélectionnez Ajouter un élément existant.
2. Sélectionnez le fichier image et cliquez sur Ajouter.
3. Dans l’explorateur de solution, sélectionnez l’image qui vient d’être ajoutée.
4. Dans la fenêtre des propriétés, changez la propriété Build Action sur Content.

Ainsi, lorsque l’application est compilée, le fichier image est inclut dans le XAP.

Remarque

Silverlight pour Windows Phone ne supporte pas tous les formats d’images. La classe BitmapImage peut être utilisée pour référence des images dans les formats JPEG et PNG. Pour plus d’informations sur les sources d’images ou les formats qui peuvent être utilisés pour un objet Image, regardez BitmapImage.

L’objet ImageBrush vous autorise à utiliser une image pour peindre une zone qui prend un objet Brush. Par exemple, ImageBrush peut être utilisé comme valeur pour la propriété Background d'un Panel. Pour plus d'informations sur les pinceaux, lisez l'article suivant Pinceaux.

Voici un exemple qui montre comment l'image licorice est peinte au sein d'un texte

Voici le résultat dans l'émulateur.

Etirer une Image

Si vous ne définissez pas les valeurs Width ou Height d'une Image, alors elle sera affichée avec les dimensions de l'image spécifiée par la propriété Source. Le fait de définir les propriétés Width et Height créé une zone rectangulaire dans laquelle se trouvera l'image. Vous pouvez spécifier comment l'image remplira cette zone en utilisant la propriété Stretch qui accepte les valeurs suivantes:

• None: l'image ne s'étend pas pour remplir les dimensions de sortie.
• Uniform: l'image est déformée pour remplir les dimensions de la zone. Mais le ratio d'affichage est préservé. C'est la valeur par défaut.
• UniformToFill: L'image est agrandie pour remplir complètement la zone mais préserve son ratio. (une partie de l'image peut alors ne pas être visible).
• Fill: L'image est déformée pour remplir la zone. Le ratio peut alors ne pas être respecté et l'image s'en retrouve potentiellement avec un ratio totalement différent que celui de son image source.

L'illustration suivante montre les différents paramétrages possibles de la propriété Stretch.

Rogner une Image

Vous pouvez utiliser la propriété Clip pour détourer une zone d’une Image. Vous définissez la propriété Clip sur un objet Geometry, ce qui vous permet de découper une variété de formes géométriques dans votre Image (par exemple, une ellipse, ligne ou un chemin complexe). Pour plus d’informations sur l’utilisation des géométries, lisez la présentation des Géométries sur MSDN.

L’exemple suivant montre comment utiliser un EllipseGeometry comme région de découpage pour une Image. Dans cet exemple, un objet Image est défini avec la propriété Source définie avec un fichier image. Un objet EllipseGeometry avec une valeur RadiusX de 125, une valeur RadiusY de 100, et une valeur Center de 225,175 est définie pour la propriété Clip de l’Image. Seule la partie de l’image qui est dans la zone de l’ellipse sera affichée.

Voici le résultat dans l’émulateur.

Appliquer un masque d’opacité

Vous pouvez appliquer un OpacityMask sur une Image pour créer une variété de techniques de masques d’opacité comme par exemple des effets de vignettage.

L’exemple suivant montre comment appliquer un dégradé radial sur une Image avec des fondus sur les bords (effet de vignette).

Voici le résultat dans l’émulateur.

Remarque

Vous pouvez utiliser une variété d’objets Brush pour un masque d’opacité. Pour plus d’informations sur les pinceaux dans Silverlight pour Windows Phone, lisez l’article Brushes QuickStart.

Créer des WriteableBitmaps

Un objet WriteableBitmap fournit une BitmapSource qui peut être modifiée. Cela vous permet de modifier les données à la volée et de mettre à jour l'image.

Vous pouvez passer une BitmapSource, les dimensions d'une nouvelle bitmap ou un UIElement au constructeur du WriteableBitmap. Passer un UIElement va créer une image bitmap de l'élément visuel. Par exemple, si vous voulez une image de tout l'arbre visuel, vous pouvez passer l'élément UIElement racine au constructeur.

La propriété Pixels du WriteableBitmap est un tableau qui représente la texture 2D du bitmap. Vous pouvez altérer l'image en modifiant les valeurs des pixels dans ce tableau.

Remarque

Le format utilisé par l'objet WriteableBitmap de Silverlight est ARGB32. Ainsi, les pixels dans le tableau de pixels d'un WriteableBitmap sont stockés en tant que couleurs pré-multipliées. Chaque canal de couleur est pré-multiplié par la valeur alpha.

Remarque

Les objets MediaElement n'apparaitront pas dans les captures WriteableBitmap. C'est parce que les MediaElements sont affichés entièrement de façon hardware dans Silverlight pour Windows Phone.

L'exemple suivant montre comment créer une image WriteableBitmap depuis un objet Image et comment modifier le WriteableBitmap. Pour créer l'objet WriteableBitmap, la propriété Source de l' Image est castée en BitmapSource et est passée en paramètre au constructeur de WriteableBitmap. Lorsque le bouton "Modify Pixels" est cliqué, le gestionnaire d'évènement itère sur le tableau de Pixels du bitmap et définit chacun d'entre eux sur noir. L'objet Image est alors modifié par ce bitmap et est réaffiché.

Pour essayer cet exemple, cliquez sur Modify Pixels pour voir comment l'image est distordue.

Remarque

Cet exemple live utilise Silverlight pour simuler le comportement du Windows Phone. Le comportement peut néanmoins être légèrement différent dans l'émulateur Windows Phone ou d’un vrai Windows Phone.

Voir aussi

• Graphiques
• Deep Zoom Overview Imaging

Cliquez ici pour revenir au sommaire de la liste d’articles

Cet article fait partie d’une série d’articles sur le développement Windows Phone. Il s’agit d’une traduction des articles se trouvant sur la MSDN.

Sommaire

Bien débuter et fondamentaux

• Bien démarrer (Hello World)
• Créer une interface utilisateur pour Windows Phone en XAML
• Utiliser des contrôles
• Types de contrôles
• Contrôles Panorama et Pivot
• Travailler avec du texte sur le Windows Phone
• Mise en page sur l’écran
• Orientations de l’écran
• Saisie tactile
• Navigation
• Exécuter votre application en arrière-plan (tombstoning)
• Notifications Push pour le développement Windows Phone
• Publier votre application sur le Marketplace

Visuels et média

• Images
• Animations
• Vidéo et Audio
• Graphiques
• Pinceaux

Travailler avec les données

• Obtenir des données dans vos applications Windows Phone
• Data binding
• Isolated storage
• Accéder à un service Web REST
• Consommer des données Windows Azure

Sondes et autres fonctionnalités spécifiques au téléphone

• Lanceurs et choosers
• Détecter des mouvements (accéléromètres)
• Développer avec le GPS Windows Phone (Services de localisation)
• Développer avec l’appareil photo du Windows Phone

Data Binding

La plupart des applications Windows Phone affichent des données dans les contrôles. Dans de nombreux cas, les données sont des objets business tels que des actions en bourse, des titres de news ou des images. En plus, vous voulez souvent autoriser l'utilisateur à sélectionner un élément depuis une liste puis afficher les détails relatifs à cet élément dans un autre contrôle comme par exemple une zone de texte.

Ce tutoriel montre comment lier un contrôle à un simple élément et comment lier un contrôle de liste à une collection d'éléments, De plus, vous verrez au sein de cet article comment personnaliser l'affichage des éléments, comment implémenter une vue détaillée basée sur une sélection et comment convertir les données avant de les afficher.

Ce tutoriel contient les sections suivantes:

• Lier un contrôle à un élément unique
• Lier un contrôle à une collection d'objets
• Afficher les éléments dans un contrôle en utilisant un data template
• Ajouter une vue détails
• Convertir des données pour les afficher dans des contrôles

Sondes et autres fonctionnalités spécifiques au téléphone

• Lanceurs et choosers
• Détecter des mouvements (accéléromètres)
• Développer avec le GPS Windows Phone (Services de localisation)
• Développer avec l’appareil photo du Windows Phone

Exécuter votre application en arrière-plan (Tombstoning)

Le système d'exploitation de Windows Phone autorise une seule application à s'exécuter à la fois. Lorsque l'utilisateur quitte l'application, le système arrête l'application. Pour offrir une expérience transparente à l'utilisateur, le système fournit un support pour restaurer l'application dans un état présentable lorsqu'elle est réactivée. Ce tutoriel décrit le processus de désactivation, le cycle d'exécution de l'application, et comment restaurer un état.

Ce tutoriel contient les sections suivantes:

• Aperçu de la désactivation
• Cycle de vie de l'application
• Etat d'application
• Etat de page
• Bonnes pratiques

Aperçu de la désactivation

Le système d'exploitation n'autorise pas d'application-tiers à s'exécuter en arrière-plan; c'est pourquoi, seulement une application peut fonctionner à la fois. Les raisons pour ne pas autoriser d'autres applications à fonctionner en arrière-plan sont de préserver la batterie du téléphone et d'assurer une réactivité rapide de l'interface.

Lorsque l'utilisateur quitte l'application, le système désactive l'application. Cette désactivation/hibernation est appelée le tombstoning. C'est le processus dans lequel le système d'exploitation désactive le process de l'application. Une application peut être désactivée dans les cas suivants:

• Un coup de fil est reçu. La réactivation s'exécute lorsque l'appel s'arrête.
• Le téléphone se met en veille. La réactivation s'exécute lorsque l'utilisateur relance le téléphone.
• L'utilisateur appuie sur le bouton Démarrer ou le bouton Recherche, ou répond à une notification. La réactivation s'exécute lorsque l'utilisateur revient à l'application en cliquant une ou plusieurs fois sur le bouton Retour.
• L'application invoque une tâche externe. La réactivation s'exécute lorsque l'utilisateur a complété la tâche.

Lorsque l'application désactivée est réactivée, elle doit afficher le même état que juste avant sa désactivation pour fournir une expérience transparente à l'utilisateur. Idéalement, l'utilisateur ne devrait pas savoir qu'il s'agit d'un nouveau process lorsqu'il réactive l'application. Par exemple, supposez que vous ouvrez une application avec une grande page et que vous avez un peu défilé la page pour lire le texte, avant de passer à une autre page. Lorsque vous revenez sur la première page, ce n'est pas trop gênant si vous avez perdu votre position et êtes revenu en haut de la page. Par contre, si vous venez de passer plusieurs minutes à remplir un formulaire, vous n'avez pas envie de perdre toute votre saisie si une autre page vous dit que vous avez fait une petite erreur.

Pour achever cela, lorsque l'application est désactivée, le système maintien des informations à propos de l'application en mémoire et utilise ces informations pour restaurer votre application dans un état présentable lorsque celle-ci est réactivée.

Windows Phone fournit des méthodes et évènements pour enregistrer et restaurer les états des applications et des pages. Ces méthodes et évènements seront décrits plus loin dans cet article.

Cycle de vie de l'application

Depuis que les applications Windows Phone peuvent être hibernées, elles ont un cycle vie unique que vous devez comprendre. Le système d'exploitation fournit quatre évènements qui indiquent l'état de votre application dans son cycle de vie. Vous pouvez utiliser ces évènements pour effectuer des actions appropriées dans votre application. Ces évènements sont Launching, Closing, Deactivated, et Activated. L'illustration suivante montre à quels moments ils sont déclenchés.

Lancement

Lorsqu'une application est exécutée depuis l'écran de démarrage, on dit qu'elle est lancée (launched). Lorsqu'un utilisateur lance une application, une nouvelle instance de l'application est créée. Lorsque l'application est démarrée un évènement Launching est déclenché. Le code qui suit montre l'évènement Launching qui est présent dans le fichier App.xaml.cs.

Vous pouvez utiliser l'évènement Launching pour sauvegarder de façon incrémentale la configuration et persistées les données pour réduire le nombre de données qui ont besoins d'être sauvegardées lorsque l'état de l'application change. C'est optionnel pour les applications avec peu de données à persister.

Closing

En appuyant sur le bouton Retour du téléphone, le modèle de navigation permet aux utilisateurs de "revenir en arrière", ou de naviguer en arrière à travers les différentes pages de l'application, et même à travers plusieurs applications. Pourtant, une fois que l'utilisateur atteint la première page d'une application, l'appui sur le bouton Retour déclenche l'évènement Closing et termine votre application. Vous pouvez utiliser cet évènement pour enregistrer les données persistantes dans l'Isolated Storage. Le code suivant montre l'évènement Closing présent dans le fichier App.xaml.cs.

Deativated

Une application pourrait être désactivée (non fermée) soit à la suite d’une autre application prenant le contrôle du premier plan, comme un appel entrant, soit à la suite de l'appui du bouton Démarrer par l'utilisateur. Dans ces cas-là, l'évènement Deactivated est déclenché. Le code suivant est un exemple de l'évènement Deactivated dans le fichier App.xaml.cs.

Contrairement à une application qui est fermée (activée), une application désactivée peut être hibernée. Cela signifie qu'elle n'est plus en cours d'exécution mais que le système garde une trace de l'application et stocke des données sur l'état de cette application. Il est possible que l'utilisateur retourne sur une application hibernée. Ainsi, vous devriez enregistrer les informations d'état de votre application en utilisant le dictionnaire exposé à travers la propriété PhoneApplicationService.State dans le gestionnaire d'évènement Deactivated. Les données enregistrées dans ce dictionnaire sont des données d'état transitoire, c'est-à-dire des données qui vous aident à rétablir l'état de l'application avant qu'elle ne soit désactivée. Parce qu'il n'y aucune garantie qu'une application hibernée soit un jour relancée, vous devriez aussi enregistrer une partie de cet état dans l'Isolated Storage par la même occasion. Toutes les actions effectuées dans le gestionnaire d'événement Deactivated doivent être réalisées en moins de 10 secondes ou le système pourrait couper brutalement l'application. Ainsi, si votre application a beaucoup de données à sauvegarder, tentez de les enregistrer de façon incrémentielle.

Il est aussi possible pour une application d'être désactivée sans être hibernée. Par exemple, si l'utilisateur clique sur le bouton Démarrer puis sur le bouton Retour dans un laps de temps très court. Pour cette raison, il est important de ne rien faire de destructif dans le gestionnaire d'évènement Deactivated. Votre application devrait être capable de continuer après avoir complété l'évènement Deactivated sans que l'évènement Activated ne soit appelé.

Activated

Après qu'une application ait été désactivée et mise en hibernation, l'utilisateur peut retourner à l'application en cliquant sur le bouton Retour jusqu'à retourner sur l’application. Lorsque l’utilisateur retourne sur une application hibernée, celle-ci est réactivée et l’évènement Activated est déclenché. Vous pouvez utiliser cet évènement pour lire les valeurs depuis PhoneApplicationService.State pour récupérer l’état de l’application tel que l’utilisateur l’avait laissé. Le code suivant montre l'évènement Activated dans le fichier App.xaml.cs

Etat d'application

Application state est l'état de l'application qui n'est spécifique à aucune page particulière. Si votre application utilise des données globales comme des informations de login ou la configuration de l'application comme les thèmes, il est probable qu'ils seront utilisés par plusieurs pages de votre application. Ces données sont considérées comme partie de l'état de l'application. Lorsque votre application est réactivée après avoir été hibernée, les données sont perdues à moins que vous sauvegardiez spécifiquement les données. En général vous utilisez les évènements Launching, Closing, Deactivated et Activated pour initialiser et maintenir un état d'application. Lorsque votre application est mémorisée, le système d'exploitation sauvegarde le contenu du dictionnaire qui est exposé par la propriété PhoneApplicationService.State. Vous pouvez enregistrer l'état de votre application lors de l'évènement Deactivated et le récupérer lors de l'évènement PhoneApplicationService.State. Plus d'informations sont disponibles dans l'article How to: Preserve and Restore Application State for Windows Phone.

Si votre application a des données persistantes, vous pouvez stocker ces données dans l'Isolated Storage plutôt que d’utiliser un dictionnaire d'état. L'Isolated Storage est un espace de stockage bac à sable sur le disque de votre téléphone. Il est analogue au système de fichier de votre ordinateur de bureau. Les données enregistrées dans l'Isolated Storage peuvent prendre plusieurs secondes à charger et vous devez donc utiliser cela uniquement pour les données qui requièrent un stockage dans la durée et pour les objets non sérialisables. De plus, vous devriez considérer avec attention où vous placez votre code pour l'Isolated Storage afin de minimiser l'impact sur des latences possibles dans votre application. Par exemple, si vous avez beaucoup de données à enregistrer, vous devriez éviter de toutes les sauvegarder d'un coup. En général, vous devriez sauvegarder les données dans l'Isolated Storage dès qu'il devient accessible ou dès que possible. Pour plus d'informations, lisez le tutoriel sur l'Isolated Storage.

Etat de page

L'état de page est l'état visuel d'une page de votre application. Lorsque l'utilisateur clique sur le bouton Retour pour revenir à une application hibernée, le système d'exploitation Windows Phone va automatiquement afficher la dernière page que l'utilisateur a visualisé. Pourtant, vous êtes responsable d’assurer que l'état de la page est sauvegardé et restauré pour qu'elle ressemble à ce qu'elle était lorsque l'utilisateur l'a quitté. L'état de page inclut différentes choses telles que le contenu d'une zone de texte et la position de défilement d'un scrollviewer. Cette section vous montrera comment vous pouvez enregistrer et restaurer l'état visuel d'une page pour fournir une expérience transparente à l'utilisateur.

Pour enregistrer et restaurer l'état visuel d'une page, vous devez utiliser le constructeur, la méthode OnNavigatedTo et la méthode OnNavigatedFrom. Le constructeur de page est appelé lors de la première navigation sur cette page. OnNavigatedTo est appelée à chaque fois que l'utilisateur arrive sur la page et que la page est disponible pour utilisation. OnNavigatedFrom est appelée chaque fois que l'utilisateur quitte la page mais avant que la page ait commencé à être déchargée.

Pour sauvegarder et restaurer l'état d'une page, vous devez effectuer normalement les étapes suivantes.

• Ajoutez un membre booléen dans la page (nommé newPageInstance dans le code de l’exemple qui suit) et mettez-lui la valeur false. Cette variable sera utilisée pour déterminer si l'UI a besoin d'être restaurée.
• Dans le constructeur de la page, mettez la variable de page à true. Ce constructeur sera appelé lorsque la page est créée pour la première fois ou si la page est recréée après que l'application ait hiberné. Le constructeur ne sera pas appelé si l'utilisateur revient d'une autre page vers celle-là parce que la page est déjà en mémoire.
• Surchargez et implémentez la méthode OnNavigatedTo. Dans cette méthode, récupérez les données d'état de la page depuis la propriété PhoneApplicationPage.State.
• Surchargez et implémentez la méthode OnNavigatedFrom. Dans cette méthode, enregistrez l'état de la page dans la propriété PhoneApplicationPage.State .

L'exemple suivant a deux pages nommées home page et seconde page. Lorsque vous cliquez sur le bouton Go to the Second Page de la page d'accueil, l'application navigue jusqu'à la seconde page. La seconde page possède un formulaire avec une zone de texte, deux boutons radio et une case à cocher. Si vous entrez des données dans le formulaire et appuyez sur le bouton Démarrer pour quitter l'application, l'application hibernera. Si vous revenez au formulaire en cliquant sur le bouton Retour, vous pouvez voir que les données saisies avant de quitter l'application sont restaurées.

L'illustration suivante montre le comportement si vous n'incluez pas le code pour restaurer l'état de la page.

Ajoutez le code suivant dans la seconde page et restaurez l'état de la page.

Pour plus d'informations sur l'état de page, lisez How to: Preserve and Restore Page State for Windows Phone.

Bonnes pratiques

Voici quelques bonnes pratiques que vous pouvez suivre lors de votre développement d'applications Windows Phone:

• Lorsque votre application est lancée, depuis une tuile ou depuis la liste des applications installées, l'utilisateur doit accéder à la racine (home) de votre application. Il doit être clair pour l'utilisateur qu'ils utilisent une nouvelle instance de votre application.
• Lorsque votre application est activée depuis un état hiberné, l'utilisateur doit avoir l'impression que l'application est exactement identique au moment où celle-ci a été désactivée. Cela doit être transparent pour l'utilisateur que l'application ait été arrêtée puis redémarrée.
• Après que l'application soit hibernée, l'utilisateur peut ne pas revenir à l'application immédiatement. Pour cette raison, vous devriez sauvegarder un état persistant à la fois dans l'évènement Deactivated et dans l'évènement Closing. Pour éviter de dupliquer le code, vous pourriez vouloir créer une seule méthode en charge de la sauvegarde de l'état et d'appeler cette méthode depuis les deux gestionnaires d'évènement.
• L’application doit compléter toutes les actions dans le gestionnaire d'évènement Deactivated en moins de 10 secondes. Si l'application prend plus de 10 secondes pour hiberner alors le système la coupera brutalement et l'application ne sera plus accessible via le bouton Retour. Il est donc recommandé que vous visiez un temps d'hibernation le plus court possible. Si vous avez beaucoup de données à sauvegarder, vous pouvez le faire de façon incrémentale dans l'Isolated Storage durant l'exécution.

Pour plus d'informations, lisez Execution Model Best Practices for Windows Phone.

Voir aussi

• Execution Model for Windows Phone

Cliquez ici pour revenir au sommaire de la liste d’articles