Behandeln von Anhalten, Fortsetzen und Aktivierung

Behandeln der Vorgänge zum Anhalten, Fortsetzen und Aktivieren in Hilo (Windows Store-Apps mit C++ and XAML)

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation]

Aus : Umfassende Entwicklung einer Windows Store-App mit C++ und XAML: Hilo

Leitfaden-Logo

Vorherige Seite | Nächste Seite

Hilo beinhaltet einige Beispiele zum Anhalten und Fortsetzen einer App mit C++ und XAML. Sie können diese Beispiele verwenden, um eine App zu erstellen, die ihren gesamten Ausführungslebenszyklus verwaltet. Eine App kann jederzeit angehalten werden. In diesem Fall müssen die zugehörigen Daten gespeichert werden, damit die App zu einem späteren Zeitpunkt problemlos fortgesetzt werden kann.

Download

Herunterladen des Hilo-Beispiels
Buch herunterladen (PDF)

Anweisungen zu dem heruntergeladenen Code finden Sie unter Erste Schritte mit Hilo.

Im Einzelnen werden Sie Folgendes lernen:

  • Auswirkungen des Aktivierungsverlaufs auf das Verhalten der App.
  • Implementierung der Unterstützung für das Anhalten und Fortsetzen mit C++ und XAML.

Betrifft

  • Windows-Runtime für Windows 8
  • Visual C++-Komponentenerweiterungen (C++/CX)
  • XAML

Tipps zum Implementieren von Anhalten/Fortsetzen

Gestalten Sie Ihre App so, dass diese ordnungsgemäß angehalten werden kann, wenn der Benutzer die App verlässt oder der Stromsparmodus aktiviert wird. Achten Sie ferner darauf, dass die App ordnungsgemäß fortgesetzt werden kann, wenn der Benutzer die App wieder aufruft oder der Stromsparmodus von Windows deaktiviert wird. Beachten Sie dabei die nachstehenden Punkte:

  • Speichern Sie Anwendungsdaten, wenn die App angehalten wird.
  • Setzen Sie Ihre App in dem Zustand fort, in dem sie der Benutzer verlassen hat, anstatt die App neu zu starten.
  • Ermöglichen Sie Ansichten und Ansichtsmodellen, die jeweils relevanten Zustände zu speichern. Beispielsweise können Sie Text als Ansichtszustand speichern, wenn ein Benutzer diesen in ein Textfeld eingegeben, das Textfeld jedoch noch nicht verlassen hat. In Hilo ist das Speichern des Zustands nur für Ansichtsmodelle erforderlich.
  • Geben Sie außerdem exklusive Ressourcen frei, wenn die App angehalten wird.
  • Aktualisieren Sie bei Änderungen die Benutzeroberfläche, wenn die App fortgesetzt wird.
  • Wenn die App nach dem Beenden fortgesetzt wird, verwenden Sie die gespeicherten Anwendungsdaten, um sie wiederherzustellen.

Siehe Richtlinien für das Anhalten und Fortsetzen von Apps (Windows Store-Apps).

[Nach oben]

Grundlegendes zu möglichen Ausführungszuständen

Das beim Aktivieren einer App eintretende Ereignis ist abhängig vom Ausführungsverlauf der App. Dabei können fünf Fälle unterschieden werden. Diese Fällen entsprechen den Werten der Windows::ActivationModel::Activation::ApplicationExecutionState-Enumeration.

  • NotRunning
  • Terminated
  • ClosedByUser
  • Suspended
  • Running

In diesem Diagramm wird veranschaulicht, wie der Ausführungszustand einer App von Windows ermittelt wird. Die blauen Rechtecke im Diagramm zeigen an, dass die App nicht in den Systemspeicher geladen wurde. Die weißen Rechtecke zeigen an, dass sich die App im Speicher befindet. Bei den gestrichelten Bögen handelt es sich um Änderungen, die ohne Benachrichtigung der ausgeführten App auftreten. Die durchgehenden Bögen stellen Aktionen mit App-Benachrichtigung dar.

Ausführungszustand einer App

Der Ausführungszustand ist abhängig vom entsprechenden Verlauf der App. Wenn die App vom Benutzer beispielsweise zum ersten Mal nach der Installation oder nach einem Neustart von Windows ausgeführt wird, ist der vorherige Ausführungszustand NotRunning. Nach der Aktivierung ist der Ausführungszustand Running. Die Argumente für das Aktivierungsereignis enthalten eine PreviousExecutionState-Eigenschaft, die Ihnen mitteilt, welchen Zustand die App vor der Aktivierung aufwies.

Wenn der Benutzer zu einer anderen App wechselt oder das System in den Stromsparzustand wechselt, wird die App von Windows darüber benachrichtigt, dass sie angehalten wurde. Sie müssen dann den zugehörigen Navigationszustand und alle Benutzerdaten der entsprechenden Sitzung speichern. Darüber hinaus müssen exklusive Systemressourcen wie geöffnete Dateien und Netzwerkverbindungen freigegeben werden.

Windows gibt der App 5 Sekunden Zeit, das Suspending-Ereignis zu behandeln. Wenn der Suspending-Ereignishandler nicht in der verfügbaren Zeit abgeschlossen wird, geht Windows davon aus, dass die App nicht mehr reagiert und beendet diese.

Nachdem die App auf das Suspending-Ereignis reagiert hat, weist sie den Zustand Suspended auf. Wenn der Benutzer die App wieder aufruft, wird diese von Windows fortgesetzt.

Windows kann die App (ohne Benachrichtigung) beenden, nachdem sie angehalten wurde. Beispielsweise können Ressourcen, die von angehaltenen Apps beansprucht werden, zurückgefordert werden, wenn nur noch wenige Systemressourcen zur Verfügung stehen. Wenn die App vom Benutzer gestartet wird, nachdem sie von Windows beendet wurde, ist der vorherige Ausführungszustand der App bei der Aktivierung Terminated.

Mit dem vorherigen Ausführungszustand können Sie bestimmen, ob Ihre App die Daten wiederherstellen muss, die beim letzten Anhalten der App gespeichert wurden, oder ob Sie die Standarddaten der App laden müssen. Wenn die App abstürzt oder vom Benutzer geschlossen wird, sollte der Benutzer beim Neustarten der App wieder den anfänglichen Standardnavigationszustand sehen. Wenn eine App feststellt, dass sie nach dem Beenden aktiviert wird, sollte sie die beim Anhalten gespeicherten Anwendungsdaten laden, damit die App wie zum Zeitpunkt des Anhaltens angezeigt wird. Dies wird in der exemplarischen Vorgehensweise für den Code von Hilo zum Anhalten und Fortsetzen auf dieser Seite veranschaulicht.

Hinweis  Wenn die App angehalten, nicht jedoch beendet wurde, können Sie sie fortsetzen, ohne einen Zustand wiederherzustellen. Die App befindet sich noch im Arbeitsspeicher. Möglicherweise müssen Sie in einer entsprechenden Situation jedoch Ressourcen erneut abrufen und die Benutzeroberfläche aktualisieren, um zwischenzeitliche Änderungen an der App zu berücksichtigen. So wird in Hilo zum Beispiel die Ansicht der Bilder des Benutzers aktualisiert, wenn die App aus dem angehaltenen Zustand fortgesetzt wird.
 

Weitere Informationen über die möglichen vorherigen Ausführungszustände finden Sie unter ApplicationExecutionState-Enumeration. Eine Beschreibung des Vorgangs zum Anhalten/Fortsetzen finden Sie unter Anwendungslebenszyklus (Windows Store-Apps). Darüber hinaus finden Sie unter Richtlinien für das Anhalten und Fortsetzen von Apps (Windows Store-Apps) Informationen zu empfohlenen Vorgehensweisen für das Anhalten und Fortsetzen.

[Nach oben]

Implementierungsansätze für das Anhalten und Fortsetzen in C++ und XAML

In Windows Store-Apps wie Hilo, die eine Visual Studio-Projektvorlage verwenden, sind vier Komponenten bei der Implementierung von Vorgängen zum Anhalten/Fortsetzen involviert.

  • Windows-Haupteinstellungen. Mithilfe des Activated-Ereignisses der Windows::ApplicationModel::Core::CoreApplicationView-Klasse kann eine App Benachrichtigungen im Zusammenhang mit der Aktivierung empfangen.
  • XAML. Die Windows::UI::Xaml::Application-Klasse stellt die OnLaunched-Methode bereit. Diese Methode sollten von der App-Klasse Ihrer App überschrieben werden, um die Anwendung zu initialisieren und ihren anfänglichen Inhalt anzuzeigen. Die Application-XAML-Klasse ruft die OnLaunched-Methode auf, wenn die App vom Benutzer gestartet wird. Wenn Sie mit einer Microsoft Visual Studio-Projektvorlage für C++ und XAML ein neues Projekt für eine Windows Store-App erstellen, erstellt Visual Studio eine App-Klasse, die von Windows::UI::Xaml::Application abgeleitet wird und die OnLaunched-Methode überschreibt. Sie können den von Visual Studio erstellten Code unverändert übernehmen oder an Ihre Bedürfnisse anpassen.
  • Visual Studio-Vorlagenklassen. Wenn Sie ein neues Projekt für eine Windows Store-App erstellen, erstellt Visual Studio im Projektmappenordner "Common" verschiedene Klassen. Eine dieser Klassen ist die SuspensionManager-Klasse. Diese Klasse stellt Methoden bereit, die in Verbindung mit der Windows::UI::Xaml::Application-Klasse ein bequemes Speichern und Wiederherstellen von App-Zuständen ermöglicht. Die SuspensionManager-Klasse interagiert mit der Windows::UI::Xaml::Frame-Klasse, um den Navigationsstapel der App zu speichern und wiederherzustellen. Die SuspensionManager-Klasse interagiert mit der LayoutAwarePage- Vorlagenklasse, um das Speichern des Seitenzustands zu geeigneten Zeitpunkten zu ermöglichen.
  • Seitenklassen Ihrer App. Hilo speichert den Navigationszustand bei jedem Aufrufen der OnNavigatedFrom-Methode. Hilo-Seiten delegieren den Speicherzustand an die zugehörigen Ansichtsmodellklassen. Hilo-Ansichtsmodelle implementieren die LoadState- und die SaveState-Methode.
Hinweis  Hilo interagiert nicht direkt mit den Aktivierungsereignissen für die CoreApplicationView-Klasse. Diese Ereignisse werden hier angeführt, falls sie von Ihrer App für untergeordnete Benachrichtigungen benötigt werden.
 
Hinweis  Benutzer können eine App über verschiedene Verträge und Erweiterungen aktivieren. Die Application-Klasse ruft die OnLaunched-Methode nur bei einem normalen Startvorgang auf. Weitere Informationen über das Erkennen anderen Aktivierungsarten finden Sie in der Windows::UI::Xaml::Application-Klasse. In Hilo muss nur der normale Startvorgang verarbeitet werden.
 

Im weiteren Verlauf dieser Seite wird exemplarisch geschildert, wie das Anhalten und Fortsetzen von Hilo unter Verwendung dieser Systemebenen implementiert wird.

[Nach oben]

Exemplarische Vorgehensweise mit Code zum Anhalten

Dieses Diagramm veranschaulicht die Interaktion der Klassen, die den Vorgang zum Anhalten in Hilo implementieren.

Diagramm mit Anhaltevorgang

Beim Starten von Hilo wird ein Handler für das Suspending-Ereignis registriert, der von der Application-Basisklasse bereitgestellt wird.

App.xaml.cpp


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


Bevor die App angehalten wird, wird der App::OnSuspending-Ereignishandler von Windows aufgerufen. Hilo verwendet diesen Ereignishandler, um relevante App- und Benutzerdaten im beständigen Speicher zu speichern.

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();
    });
}


Der Handler des Suspending-Ereignisses von Hilo wird asynchron ausgeführt. Wenn der Handler eines Suspending-Ereignisses asynchron ausgeführt wird, muss der Aufruf über den Abschluss des Vorgangs informiert werden. Dazu ruft der Handler die GetDeferral-Methode auf. Diese gibt ein SuspendingDeferral-Objekt zurück und ruft nach Abschluss des asynchronen Vorgangs die Complete-Methode des Objekts auf.

Die SaveAsync-Methode der SuspensionManager-Klasse behält die Navigation und die Benutzerdaten der App auf dem Datenträger bei. Nach Abschluss des Speichervorgangs wird das Verzögerungsobjekt von einer Fortsetzungsaufgabe darüber benachrichtigt, dass die App angehalten werden kann.

Hinweis  In Hilo wurde die statische HiloPage::IsSuspending-Eigenschaft definiert, um den Kontext festzulegen, wenn die App Rückrufe von der SaveAsync-Methode empfängt. Wir müssen wissen, ob die OnNavigatedFrom-Methode bei einem normalen Vorgang oder beim Speichern des Zustands für einen Vorgang zum Anhalten oder Fortsetzen aufgerufen wird. Wenn der Benutzer beispielsweise eine Seite verlässt, muss die App u. U. die Verbindung von Ereignishandlern mit dieser Seite trennen. Beim Anhalten sollen jedoch keine Verbindungen getrennt werden.
 

Die SaveAsync-Methode der SuspensionManager-Klasse schreibt den aktuellen Sitzungszustand auf den Datenträger. Die SaveAsync-Methode ruft die GetNavigationState-Methode der registrierten Frame-Objekte auf. In Hilo gibt es nur einen registrierten Frame; dieser entspricht der aktuellen Seite. Die GetNavigationState-Methode ruft die OnNavigatedFrom-Methode des Seitenobjekts für den Frame auf.

In Hilo entspricht jede Seite einer Instanz der HiloPage-Klasse. Dies ist die OnNavigatedFrom-Methode der Klasse.

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);
}


Die OnNavigatedFrom-Methode der HiloPage-Klasse aktualisiert die Ansichtsmodelle und ruft die OnNavigatedFrom-Methode der zugehörigen Basisklasse (LayoutAwarePage) auf.

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);
}


Die OnNavigatedFrom-Methode der LayoutAwarePage-Klasse ruft ein Objekt vom Anhalte-Manager ab und legt es als Wert der frameState-Variablen fest. Dieses Objekt implementiert die Windows::Foundation::Collections::IMap<String^, Object^>-Schnittstelle. Es stellt den Zustand dar, soweit dieser bis dahin durch den SaveAsync-Vorgang erfasst wurde. Anschließend ruft der Code die SaveState-Methode der Seite auf, um das frameState-Objekt mit Informationen für die aktuelle Seite zu erweitern.

Hinweis  Die OnNavigatedFrom-Methode wird im Rahmen des Vorgangs zum Anhalten, jedoch auf für normale Navigationsvorgänge aufgerufen, während die App ausgeführt wird. Darüber hinaus verwendet Hilo die SaveState- und die LoadState-Methode, um die Rückkehr zu einem bekannten Zustand zu unterstützen. Angenommen, der Benutzer schneidet ein Bild zu und kehrt zur Bildbetrachtungsseite zurück. Durch das Wiederherstellen des Zustands bei der Navigation kann das richtige Bild auf der Bildbetrachtungsseite angezeigt werden.
 

Dies ist die SaveState-Methode.

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);
    }
}


In Hilo delegiert die Seite das Speichern des Zustands an das zugehörige Ansichtsmodell. Außerdem wird ein einzelnes Schlüssel/Wert-Paar für alle Seitendaten verwendet. Wenn die derzeit angezeigt Seite beispielsweise die Bildbetrachtungsseite ist, handelt es sich bei der betreffenden Methode um die SaveState-Methode der ImageViewModel-Klasse von 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);
    }
}


Dieser Code zeigt, wie die Ansichtsmodellklasse des Bilds drei Informationselemente speichert: den Pfad und Namen des aktuellen Bildes, das Datum der aktuellen Monatsgruppe und die verwendete Abfrage. Andere Ansichtsmodelle speichern für ihre Vorgänge relevante Zustände.

Sie können eine beliebige Serialisierungsmethode verwenden. Das Endergebnis muss jedoch in einen Platform::Object^-Verweis konvertiert werden. Bei der Auswahl von Schlüsseln für die Schlüssel/Wert-Paare bestehen ebenfalls keine Einschränkungen. Vergewissern Sie sich jedoch, dass die in der aktuellen Seite verwendeten Schlüssel eindeutig sind. Außerdem sollten Sie bei einer späteren Wiederherstellung der Daten die gleichen Schlüssel verwenden.

[Nach oben]

Exemplarische Vorgehensweise mit Code zum Fortsetzen

Wenn eine App aus dem Status Suspended fortgesetzt wird, nimmt sie den Status Running an und wird an dem Punkt fortgesetzt, an dem sie zuvor angehalten wurde. Anwendungsdaten gehen nicht verloren, da diese zuvor im Speicher abgelegt wurden. Bei den meisten Apps sind daher keine besonderen Aktionen erforderlich, wenn Sie fortgesetzt werden.

Wenn eine App fortgesetzt wird, kann sie zuvor einige Stunden oder sogar einige Tage angehalten gewesen sein. Wenn Inhalte oder Netzwerkverbindungen der App inzwischen veraltet sind, sollten diese bei der Fortsetzung aktualisiert werden. Angehaltene Apps empfangen keine Netzwerk- oder Dateiereigniselemente, für deren Empfang sie registriert sind. Diese Ereignisse werden nicht in die Warteschlange gestellt, sondern einfach ignoriert. Aus diesem Grund sollte Ihre App den Netzwerk- oder Dateistatus überprüfen, wenn sie fortgesetzt wird. Außerdem kann es ratsam sein, dass die App einen ortsabhängigen Zustand wie die Kartenposition aktualisiert.

Wenn eine App einen Ereignishandler für das Resuming-Ereignis registriert hat, wird dieser beim Fortsetzen der App aus dem Status Suspended aufgerufen. Sie können die Inhalte mithilfe dieses Ereignishandlers aktualisieren. Hilo abonniert das Resuming-Ereignis, um die Ansicht der Bilder zu aktualisieren.

App.xaml.cpp


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


Die ist die App::OnResume-Memberfunktion.

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();
    }
}


Dieser Code weist das Dateirepositoryobjekt der App an, Datenänderungsereignisse für Ansichtsmodelle zu generieren, die auf Dateisystemänderungen reagieren müssen. Hilo versucht nicht, Datenänderungen zu erkennen, die aufgetreten sind, während die App angehalten wurde.

[Nach oben]

Exemplarische Vorgehensweise mit Code zur Aktivierung nach Beenden der App

Falls eine angehaltene App von Windows beendet wurde, ruft die Application-Basisklasse die OnLaunched-Methode auf, wenn die App erneut aktiviert wird. In diesem Diagramm wird die Interaktion von Klassen in Hilo veranschaulicht, die die App wiederherstellen, nachdem sie beendet wurde.

Diagramm mit Fortsetzungsvorgang

Die App-Klasse von Hilo überschreibt die OnLaunched-Methode der Windows::UI::Xaml::Application-Basisklasse. Wenn die OnLaunched-Methode der App-Klasse ausgeführt wird, handelt es sich bei dem zugehörigen Argument um ein LaunchActivatedEventArgs-Objekt. Dieses Objekt enthält eine ApplicationExecutionState-Enumeration, die Sie über den früheren Ausführungszustand der App informiert. Hier ist der 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);
}


Der Code überprüft das Argument und stellt fest, ob der frühere Zustand Terminated war. Wenn dies der Fall ist, ruft die Methode die RestoreAsync-Methode der SuspensionManager-Klasse auf, um die gespeicherten Einstellungen aus der Datei "_sessionState.dat" wiederherzustellen.

Die RestoreAsync-Methode liest die Informationen zum gespeicherten Zustand und ruft die SetNavigationState-Methode für alle registrierten Frames auf, die zuvor gespeichert wurden. Nähere Informationen zum Speichervorgang finden Sie auf dieser Seite unter Exemplarische Vorgehensweise mit Code zum Anhalten.

Die SetNavigationState-Methode der einzelnen Frames ruft die OnNavigatedTo-Methode der zugehörigen Seite auf. An dieser Stelle wird gezeigt, wie die OnNavigatedTo-Methode von der HiloPage-Klasse überschrieben wird.

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);
}


Die Hilo-Seite ruft die OnNavigatedTo-Methode des zugehörigen Ansichtsmodells auf. Wenn die derzeit angezeigt Seite beispielsweise die Bildbetrachtungsseite ist, handelt es sich bei der betreffenden Methode um die OnNavigatedTo-Methode der ImageViewModel-Klasse von Hilo. Dies ist der Code.

ImageViewModel.cpp


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


In diesem Beispiel extrahiert der Code die gespeicherten Navigationsinformationen aus dem Argument und aktualisiert das Ansichtsmodell.

Nachdem die Ausführung der OnNavigatedTo-Methode des Ansichtsmodells abgeschlossen ist, ruft das HiloPage-Objekt die OnNavigatedTo-Methode der zugehörigen Basisklasse (LayoutAwarePage.) auf.

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)));
    }
}


LayoutAwarePage ruft den zuvor gespeicherten Zustand für die Seite aus der SuspensionManager-Klasse ab. Anschließend wird die LoadState-Methode der Seite aufgerufen, um den gespeicherten Zustand der Seite zu deserialisieren und wiederherzustellen. Hier ist der Code für die LoadState-Methode aus der HiloPage- und aus der ImageViewModel-Klasse.

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);
    }
}


Mit diesem Code werden die zuvor gespeicherten Informationen für das Bildbetrachtungsmodell deserialisiert. Sie können diese Informationen mit dem Code vergleichen, mit dem die Daten ursprünglich gespeichert wurden. Der Code wird auf dieser Seite unter Exemplarische Vorgehensweise mit Code zum Anhalten dargestellt.

[Nach oben]

Weitere Möglichkeiten zum Beenden der App

App weisen keine Benutzeroberfläche zum Beenden auf. Benutzer können Apps jedoch beenden, indem sie ALT+F4 drücken, die App von der Startseite ziehen oder im Kontextmenü die Option Schließen auswählen. Apps, die mit einer dieser Methoden geschlossen wurden, wechseln für etwa 10 Sekunden in den NotRunning-Zustand und dann in den ClosedByUser-Zustand.

Apps sollten sich nicht selbst programmgesteuert im Rahmen ihrer normalen Ausführung schließen. Wenn Sie eine App programmgesteuert schließen, wird dies von Windows wie ein App-Absturz behandelt. Die App wechselt in den NotRunning-Zustand und behält diesen bei, bis sie vom Benutzer erneut aktiviert wird.

Apps müssen den Ablauf bei einem Systemabsturz einhalten, der darin besteht, einfach zur Startseite zurückzukehren.

In diesem Diagramm wird veranschaulicht, wie der Ausführungszustand einer App von Windows ermittelt wird. App-Abstürze und Benutzeraktionen zum Schließen werden von Windows ebenso wie der Anhalte- und Fortsetzungszustand berücksichtigt. Die blauen Rechtecke im Diagramm zeigen an, dass die App nicht in den Systemspeicher geladen wurde. Die weißen Rechtecke zeigen an, dass sich die App im Speicher befindet. Bei den gestrichelten Bögen handelt es sich um Änderungen, die ohne Benachrichtigung der ausgeführten App auftreten. Die durchgehenden Bögen stellen Aktionen mit App-Benachrichtigung dar.

Ausführungszustände von Anwendungen

[Nach oben]

 

 

Anzeigen:
© 2017 Microsoft