Windows Dev Center

Gestion de la suspension, de la reprise et de l’activation dans Hilo (applications du Windows Store en C++ et XAML)

De : Développement d’une application du Windows Store en C++ et XAML de bout en bout : Hilo

Logo de Patterns & Practices

Page précédente | Page suivante

Hilo fournit des exemples qui montrent comment une une application en C++ et XAML est mise en suspens et reprise. Vous pouvez vous inspirer de ces exemples pour écrire une application qui gère entièrement son cycle de vie d’exécution. La suspension peut se produire à tout moment et quand elle intervient, les données de votre application doivent être enregistrées pour assurer une reprise correcte de l’application.

Téléchargement

Télécharger l’exemple Hilo
Télécharger le manuel (PDF)

Après avoir téléchargé le code, consultez Prise en main de Hilo pour obtenir des instructions.

Vous découvrirez :

  • comment l’historique d’activation de l’application affecte son comportement ;
  • comment implémenter une prise en charge de la suspension et de la reprise en C++ et XAML.

S’applique à :

  • Windows Runtime pour Windows 8 ;
  • extensions de composants Visual C++ (C++/CX) ;
  • XAML

Conseils pour implémenter la suspension et la reprise

Votre application doit être conçue de façon à se mettre correctement en suspens quand l’utilisateur la quitte ou qu’un état de faible alimentation se présente. De la même façon, l’application doit être en mesure de reprendre correctement quand l’utilisateur y retourne ou que Windows quitte l’état de faible alimentation. Voici quelques points à retenir.

  • Enregistrez les données de l’application lors de la mise en suspens de l’application.
  • Rétablissez l’état de l’application qui était le sien quand l’utilisateur l’a quittée au lieu de la redémarrer entièrement.
  • Faites en sorte que les affichages et les modèles de vue puissent enregistrer et restaurer l’état approprié. Par exemple, si l’utilisateur a tapé du texte dans une zone de texte sans en être sorti pour que le texte soit validé, vous pouvez souhaiter enregistrer le texte partiellement entré sous forme d’état d’affichage. Dans Hilo, seuls les modèles de vue ont besoin d’enregistrer l’état.
  • Libérez les ressources exclusives lors de la mise en suspens de l’application.
  • Lors de la reprise de l’application, mettez à jour l’interface utilisateur si le contenu a été modifié.
  • Lorsque l’application reprend après avoir été arrêtée, utilisez les données enregistrées de l’application pour restaurer son état.

Voir Recommandations pour la suspension et la reprise d’une application (applications du Windows Store).

[Haut]

Présentation des différents états d’exécution

Les événements qui se produisent quand vous activez une application dépendent de l’historique d’exécution de l’application. Il existe cinq cas de figure possibles. Ces cas de figure correspondent aux valeurs de l’énumération Windows::ActivationModel::Activation::ApplicationExecutionState.

  • NotRunning
  • Terminated
  • ClosedByUser
  • Suspended
  • Running

Voici un diagramme qui montre comment Windows détermine l’état d’exécution de l’application. Dans le diagramme, les rectangles bleus indiquent que l’application n’est pas chargée dans la mémoire système. Les rectangles blancs indiquent que l’application est en mémoire. Les lignes courbes pointillées représentent les modifications qui se produisent sans que votre application en cours d’exécution n’en soit notifiée. Les lignes courbes pleines représentent les actions qui s’accompagnent d’une notification à destination de l’application.

État d’exécution d’une application

L’état d’exécution dépend de l’historique de l’application. Par exemple, quand l’utilisateur lance l’application pour la première fois après l’avoir installée ou après avoir redémarré Windows, l’état d’exécution précédent est NotRunning et l’état après activation est Running. Les arguments de l’événement d’activation incluent une propriété PreviousExecutionState qui vous indique l’état dans lequel se trouvait votre application avant d’être activée.

Si l’utilisateur bascule vers une autre application ou si le système passe en mode d’opération de faible alimentation, Windows notifie l’application qu’elle va être mise en suspens. À cet instant, vous devez enregistrer l’état de navigation et toutes les données utilisateur qui représentent la session de l’utilisateur. Vous devez aussi libérer des ressources système exclusives telles que les fichiers ouverts et les connexions réseau.

Windows laisse 5 secondes à l’application pour gérer l’événement Suspending. Si, passé ce délai, le gestionnaire d’événements Suspending n’a pas terminé, Windows considère que l’application a cessé de répondre et l’arrête.

Si l’application répond à l’événementSuspending, son état est Suspended. Si l’utilisateur retourne dans l’application, Windows procède à sa reprise et lui permet de s’exécuter à nouveau.

Windows peut arrêter l’application (sans notification) après avoir été mise en suspens. Par exemple, si le système est à court de ressources, il peut décider de récupérer les ressources détenues par des applications mises en suspens. Si l’utilisateur lance votre application après avoir été arrêtée par Windows, l’état d’exécution précédent de l’application au moment de l’activation est Terminated.

Vous pouvez utiliser l’état d’activation précédent pour déterminer si votre application doit restaurer les données qu’elle avait enregistrées lors de sa dernière mise en suspens ou si vous devez charger les données par défaut de votre application. En général, si l’application se bloque ou si l’utilisateur la ferme, le redémarrage de l’application doit amener l’utilisateur à l’état de navigation initial par défaut de l’application. Lorsqu’une application détermine qu’elle est activée après avoir été arrêtée, elle doit charger les données d’application enregistrées lors de la mise en suspens pour retrouver l’état qui était le sien à ce moment-là. Pour en comprendre le fonctionnement, consultez dans cette page la procédure de codage pas à pas de la prise en charge de la suspension et de la reprise dans Hilo.

Remarque  Lorsque l’application est en suspens mais qu’elle n’a pas encore été arrêtée, vous pouvez reprendre l’application sans restaurer d’état. L’application sera toujours en mémoire. Dans ce cas, vous pouvez être amené à acquérir à nouveau des ressources et mettre à jour l’interface utilisateur pour faire apparaître les changements intervenus dans l’environnement pendant que l’application était en suspens. Par exemple, Hilo met à jour son affichage du dossier Images de l’utilisateur lorsqu’il sort de l’état de suspension.

Voir Énumération ApplicationExecutionState pour plus d’informations sur les précédents états d’exécution possibles. Consultez Cycle de vie des applications (applications du Windows Store) pour obtenir une description du processus de suspension/reprise. Vous pouvez aussi consulter Recommandations pour la suspension et la reprise d’une application (applications du Windows Store) pour obtenir des informations sur l’expérience utilisateur recommandée pour la suspension et la reprise.

[Haut]

Approches d’implémentation de la suspension et de la reprise en C++ et XAML

Pour les applications du Windows Store qui, comme Hilo, utilisent un modèle de projet Visual Studio, l’implémentation de la suspension et de la reprise fait intervenir quatre composants du système.

  • Windows Core. L’événement Activated de la classe Windows::ApplicationModel::Core::CoreApplicationView permet à une application de recevoir des notifications relatives à l’activation.
  • XAML. La classe Windows::UI::Xaml::Application fournit la méthode OnLaunched que la classe App de votre application doit remplacer pour exécuter l’initialisation de l’application et afficher son contenu initial. La classe Application du langage XAML appelle la méthode OnLaunched au moment où l’utilisateur démarre l’application. Lorsque vous créez un projet pour une application du Windows Store à partir d’un des modèles de projet Microsoft Visual Studio pour C++ et XAML, Visual Studio crée une classe App qui dérive de Windows::UI::Xaml::Application et remplace la méthode OnLaunched. Vous pouvez spécialiser le code créé par Visual Studio ou l’utiliser en l’état.
  • Classes de modèle Visual Studio. Lorsque vous créez un projet pour une application du Windows Store, Visual Studio crée pour vous plusieurs classes dans le dossier de solutions Common. Parmi elles figurent la classe SuspensionManager. Cette classe propose des méthodes qui, associées à la classe Windows::UI::Xaml::Application, facilitent l’enregistrement et la restauration de l’état d’application. La classe SuspensionManager interagit avec la classe Windows::UI::Xaml::Frame pour enregistrer et restaurer automatiquement la pile de navigation de l’application. La classe SuspensionManager interagit avec la classe de modèle LayoutAwarePage pour intégrer l’état d’enregistrement de page aux moments appropriés.
  • Classes de page de votre application. Hilo enregistre l’état de navigation avec chaque appel de leur méthode OnNavigatedFrom. Les pages de Hilo délèguent l’enregistrement de l’état à leurs classes de modèle de vue associées. Les modèles de vue de Hilo implémentent les méthodes LoadState et SaveState.
Remarque  Hilo n’interagit pas directement avec les événements de la classe CoreApplicationView liés à l’activation. Nous les mentionnons ici au cas où votre application aurait besoin d’accéder à ces notifications de niveau inférieur.
Remarque  Un utilisateur peut activer une application par le biais de divers contrats et extensions. La classe Application appelle uniquement la méthode OnLaunched dans le cas d’un lancement normal. Voir la classe Windows::UI::Xaml::Application pour savoir comment détecter d’autres types d’événements d’activation. Dans Hilo, nous n’avions besoin que de gérer le lancement normal.

La suite de cette page est une procédure pas à pas qui explique comment Hilo implémente la suspension et la reprise en utilisant ces couches du système.

[Haut]

Procédure de codage pas à pas de la suspension

Ce diagramme illustre l’interaction des classes qui implémentent l’opération de suspension dans Hilo.

Représentation graphique de la séquence de suspension

Au démarrage, Hilo inscrit un gestionnaire pour l’événement Suspending fourni par la classe de base Application.

App.xaml.cpp


Suspending += ref new SuspendingEventHandler(this, &App::OnSuspending);


Windows appelle le gestionnaire d’événements App::OnSuspending avant de mettre en suspens l’application. Hilo utilise le gestionnaire d’événements pour enregistrer des données utilisateur et d’application pertinentes sur un stockage persistant.

App.xaml.cpp


void App::OnSuspending(Object^ sender, SuspendingEventArgs^ e)
{
    (void) sender; // Unused parameter
    assert(IsMainThread());

    auto deferral = e->SuspendingOperation->GetDeferral();
    HiloPage::IsSuspending = true;
    SuspensionManager::SaveAsync().then([=](task<void> antecedent)
    {
        HiloPage::IsSuspending = false;
        antecedent.get();
        deferral->Complete();
    });
}


Le gestionnaire de l’événement Suspending de Hilo est asynchrone. Si un gestionnaire de l’événement Suspending est asynchrone, il doit notifier son appelant une fois son travail terminé. Pour ce faire, le gestionnaire appelle la méthode GetDeferral qui retourne un objet SuspendingDeferral et appelle la méthode Complete de cet objet à la fin de l’opération asynchrone.

La méthode SaveAsync de la classe SuspensionManager conserve les données de navigation et utilisateur de l’application sur disque. À l’issue de l’opération d’enregistrement, une tâche de continuation notifie l’objet de report que l’application est prête à être suspendue.

Remarque  Dans Hilo, nous avons défini la propriété statique HiloPage::IsSuspending pour établir le contexte quand l’application reçoit des rappels de la méthode SaveAsync. Nous devons savoir si la méthode OnNavigatedFrom est appelée dans le cadre d’un fonctionnement normal ou si elle l’est à l’occasion de l’enregistrement de l’état pour une suspension/reprise. Par exemple, quand l’utilisateur quitte une page, l’application a parfois besoin de déconnecter les gestionnaires d’événements de cette page. Or, nous ne voulons pas déconnecter les gestionnaires d’événements dans le cas d’une suspension.

La méthode SaveAsync de la classe SuspensionManager écrit l’état actuel de la session sur disque. La méthode SaveAsync appelle la méthode GetNavigationState de chaque objet Frame inscrit. Dans Hilo, il n’y a qu’un seul frame inscrit et il correspond à la page active. La méthode GetNavigationState appelle la méthode OnNavigatedFrom de l’objet de page associé du frame.

Dans Hilo, chaque page est une instance de la classe HiloPage. Voici la méthode OnNavigatedFrom de cette classe :

HiloPage.cpp


void Hilo::HiloPage::OnNavigatedFrom(Windows::UI::Xaml::Navigation::NavigationEventArgs^ e)
{
    ViewModelBase^ viewModel = dynamic_cast<ViewModelBase^>(DataContext);
    if (!HiloPage::IsSuspending) 
    {        
        // Since we never receive destructs, this is the only place to unsubscribe.
        DetachNavigationHandlers(viewModel);
        viewModel->OnNavigatedFrom(e);
    }

   LayoutAwarePage::OnNavigatedFrom(e);
}


La méthode OnNavigatedFrom de la classe HiloPage met à jour les modèles de vue pour ensuite appeler la méthode OnNavigatedFrom de sa classe de base, LayoutAwarePage.

LayoutAwarePage.cpp


void LayoutAwarePage::OnNavigatedFrom(NavigationEventArgs^ e)
{
    auto frameState = SuspensionManager::SessionStateForFrame(Frame);
    auto pageState = ref new Map<String^, Object^>();
    SaveState(pageState);
    frameState->Insert(_pageKey, pageState);
}


La méthode OnNavigatedFrom de la classe LayoutAwarePage obtient un objet du gestionnaire de suspension et lui attribue la valeur de la variable frameState. Cet objet implémente l’interface Windows::Foundation::Collections::IMap<String^, Object^>. Il représente l’intégralité de l’état qui a été collecté jusque-là au cours de l’opération SaveAsync. Ensuite, le code appelle la méthode SaveState de la page pour enrichir l’objet frameState d’informations pour la page active.

Remarque  La méthode OnNavigatedFrom est appelée pendant l’opération de mise en suspens mais aussi pour la navigation ordinaire pendant que l’application s’exécute. Hilo utilise aussi les méthodes SaveState et LoadState pour prendre en charge le retour à un état connu. Par exemple, après que l’utilisateur a rogné une image et est revenu à la page d’affichage des images, la restauration de l’état de navigation permet l’affichage de la photo correcte dans la page d’affichage des images.

Voici la méthode SaveState :

HiloPage.cpp


void HiloPage::SaveState(IMap<String^, Object^>^ pageState)
{
    auto vm = dynamic_cast<ViewModelBase^>(DataContext);
    if (vm != nullptr)
    {
        auto vmStateMap = ref new Map<String^, Object^>();
        vm->SaveState(vmStateMap);

        pageState->Insert(viewModelStateKey, vmStateMap);
    }
}


Dans Hilo, la page délègue l’enregistrement de l’état à son modèle de vue associé et utilise une paire clé/valeur unique pour les données de la page entière. Par exemple, si la page actuellement affichée est la page d’affichage des images, la méthode applicable est la méthode SaveState de la classe ImageViewModel de Hilo.

ImageViewModel.cpp


void ImageViewModel::SaveState(IMap<String^, Object^>^ stateMap)
{
    if (m_currentPhotoImage != nullptr)
    {
        std::wstringstream stringSerialization;
        stringSerialization << m_monthDate.UniversalTime ;

        stateMap->Insert(FilePathMapKey, m_currentPhotoImage->Path);
        stateMap->Insert(FileDateMapKey, ref new String(stringSerialization.str().c_str()));
        stateMap->Insert(QueryMapKey, m_query);
    }
}


Ce code montre comment la classe de modèle de vue d’images enregistre trois informations : le chemin d’accès et le nom de l’image active, la date du groupe de mois actif et la requête qui a été utilisée. D’autres modèles de vue enregistrent des états en rapport avec leurs opérations.

Vous pouvez utiliser la technique de sérialisation de votre choix, mais le résultat final doit être converti en référence Platform::Object^. Vous pouvez choisir les clés de votre choix pour les paires clé/valeur. Veillez simplement à utiliser des clés uniques dans la page active et à utiliser ces mêmes clés au moment de restaurer les données ultérieurement.

[Haut]

Procédure de codage pas à pas de la reprise

Lorsqu’une application quitte l’état Suspended, elle entre dans l’état Running et reprend là où elle s’est arrêtée. Les données ayant été stockées en mémoire, aucune donnée d’application n’est perdue. De ce fait, la plupart des applications n’ont rien de particulier à faire lors de la reprise.

Il est possible que l’application faisant l’objet d’une reprise soit restée en suspens pendant plusieurs heures, voire plusieurs jours. Dans ce cas, si l’application présente du contenu ou des connexions réseau caduques, il convient de les actualiser lors de la reprise. Lorsqu’une application est mise en suspens, elle ne reçoit pas les événements réseau ou de fichiers auxquels elle est inscrite. Ces événements ne sont pas mis en file d’attente ; ils sont simplement ignorés. Dans ce cas, votre application doit tester l’état du réseau ou des fichiers au moment de la reprise. L’application peut aussi actualiser l’état lié à l’emplacement tel que la position cartographique.

Si une application a inscrit un gestionnaire d’événements pour l’événement Resuming, ce gestionnaire d’événements est appelé lorsque l’application quitte l’état Suspended. Vous pouvez actualiser votre contenu à l’aide de ce gestionnaire d’événements. Hilo s’abonne à l’événement Resuming pour actualiser son affichage du dossier Images.

App.xaml.cpp


Resuming += ref new EventHandler<Platform::Object^>(this, &App::OnResume);


Voici la fonction membre App::OnResume :

App.xaml.cpp


void App::OnResume(Object^ sender, Platform::Object^ e)
{
    (void) sender; // Unused parameter
    (void) e;      // Unused parameter
    assert(IsMainThread());

    if (m_repository != nullptr)
    {
        // Hilo does not receive data change events when suspended. Create these events on resume.
        m_repository->NotifyAllObservers();
    }
}


Ce code indique à l’objet de référentiel de fichiers de l’application qu’il doit générer des événements de modification de données pour les modèles de vue qui doivent répondre aux modifications du système de fichiers. Hilo ne tente pas de détecter les modifications de données intervenues pendant sa suspension.

[Haut]

Procédure de codage pas à pas de l’activation après l’arrêt de l’application

Si Windows a arrêté une application en suspens, la classe de base Application appelle la méthode OnLaunched quand l’application redevient active. Ce diagramme montre l’interaction des classes dans Hilo qui restaurent l’application après avoir été arrêtée.

Diagramme de la séquence de reprise

La classe App de Hilo remplace la méthode OnLaunched de la classe de base Windows::UI::Xaml::Application. Lorsque la méthode OnLaunched de votre classe App s’exécute, son argument est un objet LaunchActivatedEventArgs. Cet objet contient une énumération ApplicationExecutionState qui vous indique l’état d’exécution précédent de l’application. Voici le code :

App.xaml.cpp


void App::OnLaunched(LaunchActivatedEventArgs^ args)
{
    assert(IsMainThread());
    auto rootFrame = dynamic_cast<Frame^>(Window::Current->Content);

    // Do not repeat app initialization when the Window already has content,
    // just ensure that the window is active
    if (rootFrame == nullptr)
    {
        // Create a Frame to act as the navigation context and associate it with
        // a SuspensionManager key. See http://go.microsoft.com/fwlink/?LinkId=267280 for more info 
        // on Hilo's implementation of suspend/resume.
        rootFrame = ref new Frame();
        SuspensionManager::RegisterFrame(rootFrame, "AppFrame");

        auto prerequisite = task<void>([](){});
        if (args->PreviousExecutionState == ApplicationExecutionState::Terminated)
        {
            // Restore the saved session state only when appropriate, scheduling the
            // final launch steps after the restore is complete
            prerequisite = SuspensionManager::RestoreAsync();
        }
        prerequisite.then([=](task<void> prerequisite)
        {
            try
            {
                prerequisite.get();
            }
            catch (Platform::Exception^)
            {
                //Something went wrong restoring state.
                //Assume there is no state and continue
            }

            if (rootFrame->Content == nullptr)
            {
                // When the navigation stack isn't restored navigate to the first page,
                // configuring the new page by passing required information as a navigation
                // parameter.  See http://go.microsoft.com/fwlink/?LinkId=267278 for a walkthrough of how 
                // Hilo creates pages and navigates to pages.
                if (!rootFrame->Navigate(TypeName(MainHubView::typeid)))
                {
                    throw ref new FailureException((ref new LocalResourceLoader())->GetString("ErrorFailedToCreateInitialPage"));
                }
            }

            // Place the frame in the current Window
            Window::Current->Content = rootFrame;
            // Ensure the current window is active
            Window::Current->Activate();

        }, task_continuation_context::use_current());
    }
    else
    {
        if (rootFrame->Content == nullptr)
        {
            // When the navigation stack isn't restored navigate to the first page,
            // configuring the new page by passing required information as a navigation
            // parameter. See http://go.microsoft.com/fwlink/?LinkId=267278 for a walkthrough of how 
            // Hilo creates pages and navigates to pages.
            if (!rootFrame->Navigate(TypeName(MainHubView::typeid)))
            {
                throw ref new FailureException((ref new LocalResourceLoader())->GetString("ErrorFailedToCreateInitialPage"));
            }
        }
        // Ensure the current window is active
        Window::Current->Activate();
    }

    // Schedule updates to the tile. See http://go.microsoft.com/fwlink/?LinkId=267275 for
    // info about how Hilo manages tiles.
    m_tileUpdateScheduler = std::make_shared<TileUpdateScheduler>();
    m_tileUpdateScheduler->ScheduleUpdateAsync(m_repository, m_exceptionPolicy);
}


Le code vérifie son argument pour déterminer si l’état précédent était Terminated. Si tel est le cas, la méthode appelle la méthode RestoreAsync de la classe SuspensionManager pour rétablir les paramètres enregistrés à partir du fichier _sessionState.dat.

La méthode RestoreAsync lit les informations d’état enregistré et appelle ensuite la méthode SetNavigationState pour chaque frame inscrit qui a été enregistré précédemment. Consultez Procédure de codage pas à pas de la suspension dans cette page pour savoir comment se déroule l’enregistrement.

La méthode SetNavigationState de chaque frame appelle la méthode OnNavigatedTo de sa page associée. Voici comment la classe HiloPage remplace la méthode OnNavigatedTo.

HiloPage.cpp


void HiloPage::OnNavigatedTo(NavigationEventArgs^ e)
{
    
    ViewModelBase^ viewModel = dynamic_cast<ViewModelBase^>(DataContext);
    this->AttachNavigationHandlers(viewModel);
    if (viewModel != nullptr)
    {
        viewModel->OnNavigatedTo(e);
    }

    LayoutAwarePage::OnNavigatedTo(e);
}


La page Hilo appelle la méthode OnNavigatedTo de son modèle de vue associé. Par exemple, si la page actuellement affichée est la page d’affichage des images, la méthode applicable est la méthode OnNavigatedTo de la classe ImageViewModel de Hilo. Voici la méthode :

ImageViewModel.cpp


void ImageViewModel::OnNavigatedTo(NavigationEventArgs^ e)
{
    auto data = dynamic_cast<String^>(e->Parameter);
    ImageNavigationData imageData(data);
    Initialize(imageData.GetFilePath(), imageData.GetMonthGroupDate(), imageData.GetDateQuery());
}


Dans cet exemple, le code extrait les informations de navigation enregistrées de l’argument et met à jour le modèle de vue.

Une fois que la méthode OnNavigatedTo du modèle de vue a abouti, l’objet HiloPage appelle la méthode OnNavigatedTo de sa classe de base, LayoutAwarePage.

LayoutAwarePage.cpp


void LayoutAwarePage::OnNavigatedTo(NavigationEventArgs^ e)
{
    // Returning to a cached page through navigation shouldn't trigger state loading
    if (_pageKey != nullptr) return;

    auto frameState = SuspensionManager::SessionStateForFrame(Frame);
    _pageKey = "Page-" + Frame->BackStackDepth;

    if (e->NavigationMode == NavigationMode::New)
    {
        // Clear existing state for forward navigation when adding a new page to the
        // navigation stack
        auto nextPageKey = _pageKey;
        int nextPageIndex = Frame->BackStackDepth;
        while (frameState->HasKey(nextPageKey))
        {
            frameState->Remove(nextPageKey);
            nextPageIndex++;
            nextPageKey = "Page-" + nextPageIndex;
        }

        // Pass the navigation parameter to the new page
        LoadState(e->Parameter, nullptr);
    }
    else
    {
        // Pass the navigation parameter and preserved page state to the page, using
        // the same strategy for loading suspended state and recreating pages discarded
        // from cache
        LoadState(e->Parameter, safe_cast<IMap<String^, Object^>^>(frameState->Lookup(_pageKey)));
    }
}


La classe LayoutAwarePage obtient l’état précédemment enregistré de la page auprès de la classe SuspensionManager. Elle appelle ensuite la méthode LoadState de la page pour désérialiser l’état enregistré de la page et le restaurer. Voici le code portant sur la méthode LoadState de la classe HiloPage et de la classe ImageViewModel.

HiloPage.cpp


void HiloPage::LoadState(Object^ navigationParameter, IMap<String^, Object^>^ pageState)
{
    auto vm = dynamic_cast<ViewModelBase^>(DataContext);
    if (vm != nullptr && pageState != nullptr)
    {
        IMap<String^, Object^>^ state = nullptr;
        state = dynamic_cast<IMap<String^, Object^>^>(pageState->Lookup(viewModelStateKey));

        vm->LoadState(state);
    }
}


ImageViewModel.cpp


void ImageViewModel::LoadState(IMap<String^, Object^>^ stateMap)
{
    if (stateMap != nullptr)
    {
        auto filePath = dynamic_cast<String^>(stateMap->Lookup(FilePathMapKey));

        auto fileDateString = dynamic_cast<String^>(stateMap->Lookup(FileDateMapKey));
        DateTime fileDate;
        fileDate.UniversalTime = _wtoi64(fileDateString->Data());

        auto query = dynamic_cast<String^>(stateMap->Lookup(QueryMapKey));

        Initialize(filePath, fileDate, query);
    }
}


Ce code désérialise les informations enregistrées précédemment pour le modèle de vue des images. Vous pouvez le comparer au code qui a initialement enregistré les données, qui figure plus haut dans la section Procédure de codage pas à pas de la suspension de cette page.

[Haut]

Autres méthodes pour quitter l’application

Les applications ne contiennent pas d’interface utilisateur permettant de fermer l’application, mais les utilisateurs peuvent choisir de fermer une application en appuyant sur Alt+F4, en faisant glisser l’application à partir de la page d’accueil ou en sélectionnant le menu contextuel Fermer. Une application qui a été fermée de l’une de ces façons passe à l’état NotRunning pendant environ 10 secondes avant de basculer dans l’état ClosedByUser.

Les applications ne doivent pas se fermer par programme dans le cadre d’une exécution normale. Lorsque vous fermez une application par programme, Windows considère qu’il s’agit d’un blocage d’application. L’application passe à l’état NotRunning et y reste jusqu’à ce que l’utilisateur la réactive.

Votre application doit suivre la procédure en cas de blocage du système, qui consiste simplement à revenir à la page de démarrage.

Voici un diagramme qui montre comment Windows détermine l’état d’exécution de l’application. Windows prend en compte les blocages d’application et les actions de fermeture utilisateur, ainsi que l’état de suspension ou de reprise. Dans le diagramme, les rectangles bleus indiquent que l’application n’est pas chargée dans la mémoire système. Les rectangles blancs indiquent que l’application est en mémoire. Les lignes courbes pointillées représentent les modifications qui se produisent sans que votre application en cours d’exécution n’en soit notifiée. Les lignes courbes pleines représentent les actions qui s’accompagnent d’une notification à destination de l’application.

États d’exécution d’une application

[Haut]

 

 

Afficher:
© 2015 Microsoft