Gestion du cycle de vie pour que vos applications soient « toujours réactives »

Blog des développeurs d'applications Windows 8

Indications sur la conception d'applications de style Metro pour Windows 8, par l'équipe d'ingénierie de Windows 8

Gestion du cycle de vie pour que vos applications soient « toujours réactives »

  • Comments 0

Grâce au modèle du cycle de vie des applications dans Windows 8, les utilisateurs n'ont plus besoin de gérer les applications qui s'exécutent. Ce modèle permet également aux développeurs d'élaborer une expérience utilisateur extraordinaire qui n'a aucun impact sur les performances ou sur l'autonomie de l'appareil lorsque l'application s'exécute en arrière-plan. À l'aide des nouveaux événements de cycle de vie, votre application est toujours réactive, même si elle ne s'exécute jamais hors écran.

De nos jours, l'autonomie des batteries est souvent insuffisante sur les ordinateurs portables, les tablettes et les téléphones. Cela s'explique par le fait que nous avons tous tendance à laisser les applications s'exécuter, même lorsque nous ne les utilisons pas. Nous agissons ainsi pour des raisons pratiques et pour passer rapidement d'une application à une autre.

Nous avions cela à l'esprit lorsque nous avons développé le modèle du cycle de vie des applications de style Metro dans Windows 8. Nos objectifs étaient d'assurer une réactivité permanente des applications, de préserver l'autonomie de la batterie et de fournir des performances excellentes et homogènes. Les applications de style Metro sont synonymes d'expériences immersives et plein écran. Ainsi, le nouveau modèle du cycle de vie dans Windows 8 se concentre sur les applications qui sont au premier plan. Cela permet de s'assurer que l'utilisateur s'implique activement et qu'il bénéficie de toute la puissance de l'appareil. Dans ce billet, je détaille pas à pas les nouveaux états du modèle du cycle de vie et les mesures à prendre pour optimiser votre application.

Cycle de vie des applications de style Metro

Votre application de style Metro peut se trouver dans l'un des 4 états du cycle de vie à n'importe quel moment : Pas en cours d'exécution, En cours d'exécution, Suspendu ou Arrêté. Lorsque votre application passe d'un état à un autre, elle reçoit des événements de cycle de vie qui vous aident à offrir des performances élevées et homogènes à vos utilisateurs.

Ce schéma montre comment une application de style Metro passe d'un état à un autre :

3 cases reliées par des flèches de manière circulaire. Pas en cours d'exécution > Activation > En cours d'exécution > Suspension > Suspendu > Arrêt > Pas en cours d'exécution.

Toutes les applications de style Metro traversent ces états lorsque les utilisateurs lancent des applications, passent d'une application à une autre et les ferment. Il est probable que votre application traversera fréquemment les états En cours d'exécution et Pas en cours d'exécution lorsque les utilisateurs passeront d'une application à une autre. Par conséquent, votre application doit gérer les événements de cycle de vie.

Lorsque votre applications passe d'un état du cycle de vie à un autre, elle reçoit ces événements de cycle de vie :

Événement De À

Activated

Pas en cours d'exécution

En cours d'exécution

Suspending ou Checkpoint (WinJS)

En cours d'exécution

Suspendu

Resuming

Suspendu

En cours d'exécution

Suspendre

En règle générale, les applications de style Metro cessent de s'exécuter lorsque l'utilisateur passe à une autre application. Windows suspend votre application lorsqu'elle n'est plus au premier plan. Lorsque votre application est suspendue, elle est gelée en mémoire. Elle ne peut pas s'exécuter dans cet état, mais Windows peut instantanément la réactiver lorsque l'utilisateur retourne dans cette application. Ainsi, Windows permet à l'application qui se trouve au premier plan de mieux utiliser les ressources système et s'assure que les applications qui se trouvent en arrière-plan ne peuvent pas affecter l'autonomie de la batterie.

Lorsque votre application sort du premier plan, Windows attend quelques secondes pour permettre un retour rapide à l'application, puis il tente de la suspendre. Votre application doit être inscrite pour les événements Suspending ou Checkpoint (JavaScript), qu'elle reçoit lorsque Windows souhaite la suspendre. Ce moment est important pour votre application. Saisissez cette chance pour enregistrer les données d'application qui doivent demeurer dans le stockage persistant. Habituellement, votre application est réactivée telle quelle et vous n'avez pas besoin de vos données conservées, car elles sont toujours en mémoire. En revanche, vous devez stocker ces données au cas où Windows arrête votre application pour libérer des ressources système. Enregistrez une quantité suffisante de données d'application pour que les utilisateurs puissent retrouver l'endroit où ils se trouvaient lorsque l'application a été suspendue. De cette façon, vos clients perçoivent votre application comme étant toujours réactive et en cours d'exécution.

Si votre application ne revient pas de son gestionnaire d'événements de suspension dans les 5 secondes suivant la réception de l'événement de suspension, Windows l'arrête. Il est important de ne pas réaliser d'opérations lourdes dans votre gestionnaire d'événements de suspension. Enregistrez vos données d'application et revenez rapidement.

Dans ce billet, nous utilisons une application boursière comme exemple. Cette application peut utiliser l'événement de suspension pour enregistrer la dernière action boursière que l'utilisateur consultait, ainsi que la période choisie dans un graphique boursier. Ensuite, si l'application est arrêtée, elle peut redémarrer à l'endroit exact que l'utilisateur consultait la dernière fois qu'il a vu l'application. Par exemple, il est recommandé pour une application boursière d'utiliser ce principe comme une autre opportunité d'envoyer une notification locale des vignettes, afin que la vignette de l'application soit actualisée avec les informations les plus récentes avant que Windows ne l'arrête.

Gestion de la suspension dans JavaScript

Si vous écrivez une application de style Metro à l'aide de la bibliothèque Windows pour JavaScript (WinJS), vous pouvez utiliser l'événement Checkpoint pour gérer la suspension.

var app = WinJS.Application;

function checkpointHandler() {
// The checkpoint event gives us the chance to save application data.
// In this case, we save the current stock info that the user is viewing.
app.sessionState.lastSeenStock = selectedStock;
app.sessionState.lastSeenRange = selectedRange;

// Send client side notifications
Tile.sendTileUpdate(selectedStock, stockInfo.change, stockInfo.lastSale,
stockInfo.lastSaleTime, stockInfo.open);
}

app.addEventListener("checkpoint", checkpointHandler);

Ceci n'est qu'un aperçu. Pour plus d'informations, consultez l'article consacré à la suspension d'une application (JavaScript et HTML), disponible dans le Centre de développement.

Gestion de la suspension dans XAML

Si vous écrivez une application de style Metro à l'aide de XAML et de C#, vous pouvez utiliser l'événement Suspending dans l'objet d'application pour gérer la suspension de l'application.

public App()
{
InitializeComponent();
this.Suspending += new SuspendingEventHandler(OnSuspending);
}

async protected void OnSuspending(object sender, SuspendingEventArgs args)
{
// The Suspending event gives us the chance to save application state
// In this case, we save the current stock info that the user is viewing

// Because writing to a file is asynchronous, we grab a deferral which ensures
// that suspending doesn’t complete until our file write is complete
SuspendingDeferral deferral = args.SuspendingOperation.GetDeferral();

// Here we create a SuspensionManager class which handles adding session data
// to a Dictionary and then serializing that data to a file
SuspensionManager.SessionState["lastSeenStock"] = stock;
SuspensionManager.SessionState["lastSeenRange"] = range;
await SuspensionManager.SaveAsync();

// Send client side notifications
Tile.SendTileUpdate(stock, stockInfo.Change, stockInfo.LastSale,
stockInfo.LastSaleTime, stockInfo.Open);

deferral.Complete();
}

Là encore, ceci n'est qu'un aperçu. Pour plus d'informations sur la suspension dans XAML et C#, consultez l'article consacré à la suspension d'une application (VB/C#/C++ et XAML), disponible dans le Centre de développement.

Reprise

Lors de la reprise de votre application, elle continue à partir de l'état dans lequel elle était lorsque Windows l'a suspendue. En particulier : les données et l'état de l'application sont conservés en mémoire pendant la suspension de l'application. Ainsi, lors de sa reprise, tout est exactement comme au moment où l'application a été suspendue. Vous n'avez pas besoin de restaurer des données enregistrées explicitement lors de la réception de l'événement Resuming.

Mais vous souhaitez que votre application soit toujours réactive. Pour ce faire, elle doit être connectée et afficher les données les plus actuelles. Il est possible que votre application reste dans un état suspendu pendant quelques temps avant sa reprise. Les données ou les connexions réseau peuvent devenir obsolètes et nécessiter une actualisation lors de la reprise de votre application. Lorsqu'un utilisateur ramène votre application au premier plan, elle reçoit un événement Resuming. Vous pouvez actualiser le contenu de l'application et reconnecter les ressources réseau lorsque votre application reçoit cet événement.

Dans l'application boursière que nous avons pris en exemple, la reprise permet d'actualiser toutes les données boursières mises en cache que l'application détenait avant d'être suspendue. Les anciennes données peuvent dater de plusieurs heures ou même de plusieurs jours. L'utilisateur ne percevra plus son application comme toujours réactive s'il voit ces anciennes données. Lors de la reprise, notre application boursière doit mettre à jour toutes ses données. Cela permet à l'utilisateur de consulter les derniers cours boursiers, graphiques et articles d'actualités à chaque fois que l'application est ramenée au premier plan.

Gestion de la reprise dans JavaScript

Dans JavaScript, vous pouvez utiliser l'événement Resuming de Windows Runtime dans l'espace de noms Windows.UI.WebUI.WebUIApplication. Il s'agit d'un événement de reprise spécialisé, destiné uniquement aux applications JavaScript.

function resumingHandler() {
//Update the selected stock with the latest news, stock info, and chart data
News.requestNews(stock);
Api.getStockInfoData(stock).then(function(data){displayStockInfo(data); });
Api.getHistoryData(range).then(function (chartData)
{CanvasChart.drawChart("chartCanvas", chartData, Chart.getChartOptions(false));});

// Send client side notifications
Tile.sendTileUpdate(stock, stockInfo.change, stockInfo.lastSale,
stockInfo.lastSaleTime, stockInfo.open);
}

Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", resumingHandler);

Pour plus d'informations, consultez l'article consacré à la reprise d'une application (JavaScript et HTML), disponible dans le Centre de développement.

Gestion de la reprise dans XAML

Si vous écrivez une application de style Metro à l'aide de XAML et de C#, vous pouvez utiliser l'événement Resuming dans l'objet d'application pour gérer la reprise de l'application.

public App()
{
InitializeComponent();
this.Resuming += new EventHandler<object>(App_Resuming);
}

async private void App_Resuming(object sender, object e)
{
//Update the selected stock with the latest news, stock info, and chart data
News.RequestNews(stock);

Data data = await Api.GetStockInfoDataAsync(stock);
Api.DisplayStockInfo(data);

Chart chartData = await Api.GetHistoryDataAsync(range);
CanvasChart.DrawChart("chartCanvas", chartData, Chart.GetChartOptions(false));

// Send client side notifications
Tile.SendTileUpdate(stock, stockInfo.Change, stockInfo.LastSale, stockInfo.LastSaleTime, stockInfo.Open);
}

Pour plus d'informations sur la reprise dans VB/C#/C++ et XAML, consultez l'article consacré à la reprise d'une application (VB/C#/C++ et XAML), disponible dans le Centre de développement.

Activation

L'activation concerne la façon dont votre application est lancée. Elle remplit de nombreuses fonctions dans une application de style Metro. Pour en savoir plus sur la façon dont vous pouvez activer des applications de style Metro pour gérer les contrats, consultez notre billet précédent Activation des contrats Windows 8 dans votre application. Nous y expliquons comment vous pouvez utiliser l'activation pour restaurer les données enregistrées précédemment au cas où Windows a arrêté votre application et où l'utilisateur l'a ensuite relancé.

Windows peut, pour différents motifs, arrêter votre application après l'avoir suspendue. Par exemple : l'utilisateur ferme manuellement votre application, ou se déconnecte, ou les ressources système deviennent insuffisantes (certaines applications, telles que les jeux, peuvent utiliser un grand nombre de ressources !). Si l'utilisateur lance votre application après que Windows l'a arrêtée, elle reçoit un événement Activated et l'utilisateur voit l'écran de démarrage de votre application jusqu'à ce qu'elle soit activée. Vous pouvez utiliser cet événement pour déterminer si votre application doit restaurer les données qu'elle a enregistrées lors de sa dernière suspension, ou si vous devez charger les données par défaut de votre application. Les arguments de l'événement Activated incluent une propriété PreviousExecutionState qui vous indique l'état dans lequel se trouvait votre application avant son activation. Cette propriété est l'une des valeurs de l'énumération Windows.ApplicationModel.Activation.ApplicationExecutionState.

Motif de l'arrêt Valeur PreviousExecutionState Mesure à prendre
Arrêtée par le système (en raison de contraintes au niveau des ressources, d'un arrêt du PC, d'un redémarrage, etc.)

Terminated

Restaurer les données de session

Fermée par l'utilisateur

ClosedByUser

Démarrer avec les valeurs par défaut

          Arrêtée de manière inattendue ou l'application n'a pas été exécutée depuis le début de la session de l'utilisateur

NotRunning

Démarrer avec les valeurs par défaut

La propriété PreviousExecutionState peut avoir la valeur En cours d'exécution ou Suspendu, mais dans ce cas, votre application n'a pas encore été arrêtée et par conséquent, vous n'avez pas à vous soucier de la restauration des données.

Lorsque votre application est activée et que sa valeur PreviousExecutionState était Arrêté, vous devez restaurer les données enregistrées de votre session pour que l'application ait exactement la même apparence que lorsque l'utilisateur l'a vue pour la dernière fois. Si l'utilisateur a fermé manuellement l'application, si elle s'est arrêtée de manière inattendue ou si elle n'a pas encore été exécutée dans la session en cours, vous devez ignorer les données de la session précédente et démarrer l'application avec sa vue par défaut.

Notre application boursière d'exemple utilise l'événement Activated pour ramener les informations boursières et graphiques qu'elle a enregistrées lors de sa suspension. L'application actualise également ses données réseau mises en cache. Cela permet à l'utilisateur de consulter les mêmes actions boursières que celles qu'il consultait lorsqu'il a quitté l'application, mais les cours boursiers, les graphiques et les articles d'actualités sont tous actualisés.

Gestion de l'activation dans JavaScript

Si vous écrivez une application de style Metro à l'aide de la bibliothèque Windows pour JavaScript (WinJS), vous pouvez utiliser l'événement Activated pour gérer l'activation.

Dans le code du gestionnaire d'événements Activated, votre application peut vérifier l'objet sessionState pour déterminer si elle doit charger les données enregistrées ou si elle doit afficher la vue d'accueil par défaut. SessionState détermine automatiquement le dernier état de votre application en examinant eventArgs.detail.previousExecutionState. Si l'objet sessionState est renseigné, utilisez-le pour restaurer les données de votre session. Sinon, utilisez les données par défaut de votre application.

var app = WinJS.Application;

function activatedHandler(eventArgs) {
if (eventArgs.detail.kind == Windows.ApplicationModel.Activation.ActivationKind.launch) {
// Check whether the session state variables are valid.
// If so, retrieve the stock and range values saved in the checkpoint handler
if (app.sessionState) {
stock = app.sessionState.lastSeenStock;
range = app.sessionState.lastSeenRange;
}
// If not, use the app's default values
else{
stock = "DOW";
range = "1M";
}

// Initialize the WinJS controls asynchronously behind the app splash screen
// Start retrieving the latest stock data asynchronously after the controls are ready
eventObject.setPromise(WinJS.UI.processAll().then(function() {
Api.initializeUserStocks();
}));
}
}

app.addEventListener("activated", activatedHandler);
       

Pour plus d'informations sur la gestion de l'activation dans JavaScript, consultez l'article consacré à l'activation d'une application (JavaScript et HTML), disponible dans le Centre de développement.

Gestion de l'activation dans XAML

Dans une application de style Metro à l'aide de XAML et de C#, vous pouvez remplacer l'événement OnLaunched pour gérer une activation de base à partir d'une vignette.

Dans le code du gestionnaire d'événements OnLaunched, votre application peut vérifier la propriété PreviousExecutionState dans les arguments de l'événement. Si elle équivaut à Arrêté, restaurez les données que vous avez enregistrées dans l'événement Suspending. Si la valeur est différente, utilisez les données par défaut de l'application.

async protected override void OnLaunched(LaunchActivatedEventArgs args)
{
// Check whether the session data should be restored
if (args.PreviousExecutionState == ApplicationExecutionState.Terminated)
{
// Here we've created a SuspensionManager class which handles restoring session
// data from a file and then gives access to that data through a Dictionary
await SuspensionManager.RestoreAsync();

// Retrieve the stock and range values saved in the suspend handler
stock = SuspensionManager.SessionState["lastSeenStock"];
range = SuspensionManager.SessionState["lastSeenRange"];
}
// If not, use the app's default values
else
{
stock = "DOW";
range = "1M";
}

// Start retrieving the latest stock data
Api.InitializeUserStocks();

Window.Current.Activate();
}

Pour plus d'informations sur la gestion de l'activation dans XAML, consultez l'article consacré à l'activation d'une application (VB/C#/C++ et XAML), disponible dans le Centre de développement.

Conseils pour créer une formidable expérience en termes de durée de vie des applications

Maintenant que vous connaissez tous les principes de base, voici quelques conseils visant à vous aider à concevoir une formidable expérience en termes de durée de vie de votre application, afin qu'elle soit toujours réactive et actuelle pour vos utilisateurs.

Il est parfois préférable de tout reprendre

Si l'utilisateur n'a pas regardé votre application depuis un certain temps, il est parfois préférable de réinitialiser l'application sur la vue par défaut. C'est à vous qu'il revient de décider à quel moment cela doit se produire, mais si le contenu de votre application risque de paraître ancien ou obsolète, nous vous recommandons de redéfinir votre application sur sa vue d'accueil. Cela rend votre application plus intelligente aux yeux des utilisateurs.

Par exemple, si vous créez une application de lecture d'actualités, il est probable qu'elle sera suspendue si l'utilisateur passe à une autre application. Plus tard, lorsque l'utilisateur revient à votre application, celle-ci reprend son fonctionnement. Dans votre gestionnaire de reprise, vérifiez l'âge de l'article en cours pour déterminer s'il est désormais obsolète. Si l'article est trop ancien, affichez votre vue d'accueil par défaut à la place de l'ancien article.

Enregistrez les bonnes données au bon moment

Enregistrez toujours les données importantes de façon incrémentielle tout au long de la vie de votre application. Comme votre application ne dispose que de cinq secondes au maximum pour exécuter le code du gestionnaire d'événements de suspension, vous devez vous assurer que les données importantes de l'application ont été enregistrées dans un stockage persistant au moment où elle est suspendue.

Lorsque vous écrivez votre application, vous devez gérer deux types de données : les données de session et les données utilisateur. Les données de session sont des données temporaires qui sont appropriées à l'utilisation actuelle de l'utilisateur dans votre application. Il peut s'agir par exemple de l'action consultée actuellement par l'utilisateur, de la page lue actuellement par l'utilisateur dans un eBook ou de la position de défilement dans une longue liste d'éléments. Les données utilisateur sont persistantes et doivent toujours être accessibles à l'utilisateur, quoi qu'il en soit. Il peut s'agir par exemple d'un document que l'utilisateur est en train de taper, d'une photo prise dans l'application ou de la progression de l'utilisateur dans votre jeu.

Assurez-vous qu'au moment où votre application est suspendue, elle a enregistré les deux types de données dans un stockage persistant.

Restauration des données de session

Dans l'esprit des utilisateurs, une application de style Metro devra en règle générale rester la même que lorsqu'ils l'ont utilisée pour la dernière fois. Du point de vue du développeur, lorsque votre application est reprise après une suspension ou activée alors qu'elle n'était pas en cours d'exécution, il convient souvent de restaurer les données de session précédemment enregistrées.

Par exemple, si votre application comprend une fonction de panier d'achat et que l'utilisateur a ajouté des articles dans son panier, puis qu'il passe à une autre application, il serait logique de conserver ces articles dans le panier jusqu'à ce que l'utilisateur reprenne ou réactive l'application.

Un autre exemple : imaginez une application qui présente des articles d'actualités. Si l'utilisateur consultait un article en particulier, puis qu'il est passé à une autre application, il s'attend à revoir l'article qu'il consultait lorsqu'il revient à votre application.

Libérez les ressources exclusives dans votre gestionnaire d'événements Suspending

Si votre application a acquis des ressources exclusives lors de son exécution (par exemple des descripteurs de fichiers ou des références à des périphériques externes), elle doit libérer ces ressources lorsqu'elle reçoit l'événement Suspending. Votre application doit en outre récupérer ces ressources exclusives lorsqu'elle reçoit l'événement Resuming si elle a besoin qu'elles continuent.

Ne fermez pas votre application !

Les applications de style Metro dans Windows 8 ne doivent jamais se fermer ou présenter une interface utilisateur permettant à l'utilisateur de fermer votre application. La suspension ou l'arrêt des applications est géré par Windows au nom de l'utilisateur afin de maintenir les performances du système et l'autonomie de la batterie. Si les utilisateurs souhaitent fermer votre application, il le peuvent en faisant glisser leur doigt du haut vers le bas de l'écran ou en appuyant sur ALT+F4.

Pour conclure

Grâce aux 3 événements (Suspending, Resuming et Activated), votre application paraîtra toujours réactive aux yeux de vos utilisateurs. Mais en même temps, elle n'utilisera jamais la batterie de façon inutile ni ne réduira les performances du système lorsqu'elle ne les utilisera pas. Dans un monde davantage porté sur les appareils mobiles et de petite taille, le nouveau cycle de vie des applications de style Metro permet à votre application de s'exprimer pleinement sur n'importe quel appareil.

--Adam Barrus, chef de projet, Windows

Ce billet a été rédigé en équipe. Remerciements à Jake Sabulsky, Ben Srour, Ben Betz, Marco Matos, Ryan Haveson, Ian LeGrow et John Montgomery pour leur participation.

  • Loading...
Leave a Comment
  • Please add 6 and 5 and type the answer here:
  • Post