Developpement Windows Phone - partie 11
Exécuter votre application en arrière-plan (Tombstoning)
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
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.
C#
// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
}
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.
C#
// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
}
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.
C#
// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
}
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
C#
// Code to execute when the application is activated (brought to foreground)
// This code will not execute when the application is first launched
private void Application_Activated(object sender, ActivatedEventArgs e)
{
}
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.
C#
public partial class SecondPage : PhoneApplicationPage
{
bool newPageInstance = false;
public SecondPage()
{
InitializeComponent();
newPageInstance = true;
}
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
if (State.ContainsKey("textbox") && newPageInstance == true)
{
MyTB.Text = (string)State["textbox"];
MyRB1.IsChecked = (bool?)State["radiobutton1"];
MyRB2.IsChecked = (bool?)State["radiobutton2"];
MyCB.IsChecked = (bool?)State["checkbox"];
}
base.OnNavigatedTo(e);
}
protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
{
newPageInstance = false;
State["textbox"] = MyTB.Text;
State["radiobutton1"] = MyRB1.IsChecked;
State["radiobutton2"] = MyRB2.IsChecked;
State["checkbox"] = MyCB.IsChecked;
base.OnNavigatedFrom(e);
}
}
Visual Basic
Partial Public Class SecondPage
Inherits PhoneApplicationPage
Private newPageInstance As Boolean = False
Public Sub New()
InitializeComponent()
newPageInstance = True
End Sub
Protected Overrides Sub OnNavigatedTo(e As System.Windows.Navigation.NavigationEventArgs)
If State.ContainsKey("textbox") AndAlso newPageInstance = True Then
MyTB.Text = DirectCast(State("textbox"), String)
MyRB1.IsChecked = CType(State("radiobutton1"), System.Nullable(Of Boolean))
MyRB2.IsChecked = CType(State("radiobutton2"), System.Nullable(Of Boolean))
MyCB.IsChecked = CType(State("checkbox"), System.Nullable(Of Boolean))
End If
MyBase.OnNavigatedTo(e)
End Sub
Protected Overrides Sub OnNavigatedFrom(e As System.Windows.Navigation.NavigationEventArgs)
newPageInstance = False
State("textbox") = MyTB.Text
State("radiobutton1") = MyRB1.IsChecked
State("radiobutton2") = MyRB2.IsChecked
State("checkbox") = MyCB.IsChecked
MyBase.OnNavigatedFrom(e)
End Sub
End Class
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.