Behandeln von Anhalten, Fortsetzen und Aktivierung in Hilo (Windows Store-Apps mit JavaScript und HTML)

Aus: Umfassende Entwicklung einer Windows Store-App mit JavaScript: Hilo

Leitfaden-Logo

Vorherige Seite | Nächste Seite

Hilo enthält Beispiele zum Anhalten und Aktivieren einer Windows Store-App mit JavaScript. Anhand dieser Beispiele können Sie eine App 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 zum heruntergeladenen Code finden Sie unter Erste Schritte mit Hilo.

Im Einzelnen werden Sie Folgendes lernen:

  • Sie erfahren, wie Windows den Ausführungszustand einer App ermittelt.
  • Sie erfahren, wie sich der Aktivierungsverlauf auf das Verhalten der App auswirkt.
  • Sie erfahren, wie Sie die Unterstützung für das Anhalten und Aktivieren mit JavaScript implementieren.

Betrifft

  • Windows-Runtime für Windows 8
  • Windows-Bibliothek für JavaScript
  • JavaScript

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 Windows den Stromsparmodus wieder deaktiviert. Beachten Sie insbesondere folgende Punkte:

  • Speichern Sie Anwendungsdaten, wenn die App angehalten wird.
  • Setzen Sie die App in dem Zustand fort, in dem sie der Benutzer verlassen hat.
  • Speichern Sie beim Verlassen einer Seite den Seitenzustand, damit die App möglichst schnell angehalten werden kann.
  • Ermöglichen Sie Ansichten und Presentern, die jeweils relevanten Zustände zu speichern und wiederherzustellen. Beispielsweise können Sie Text als Ansichtszustand speichern, wenn ein Benutzer diesen in ein Textfeld eingegeben, das Textfeld aber noch nicht verlassen hat. In Hilo ist das Speichern des Zustands nur für Presenter 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.
  • Verwenden Sie die gespeicherten Anwendungsdaten, um den Zustand einer App wiederherzustellen, die nach dem Beenden fortgesetzt wird.

Weitere Informationen finden Sie unter Richtlinien für das Anhalten und Fortsetzen von Apps (Windows Store-Apps).

[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

Dieses Diagramm zeigt, wie Windows den Ausführungszustand einer App ermittelt. Die blauen Rechtecke im Diagramm geben an, dass die App nicht in den Systemspeicher geladen wurde. Die grauen Rechtecke geben an, dass sich die App im Arbeitsspeicher befindet. Bei den blauen Bögen handelt es sich um Änderungen, die ohne Benachrichtigung der ausgeführten App auftreten. Die schwarzen Bögen stellen Aktionen mit App-Benachrichtigung dar.

Ausführungszustand einer App

Der Ausführungszustand ist abhängig vom Verlauf der App. Wenn der Benutzer die App beispielsweise nach der Installation oder nach einem Neustart von Windows erstmals startet, lautet der vorherige Ausführungszustand der App notRunning. Nach der Aktivierung lautet der Ausführungszustand running. Bei der Aktivierung enthalten die Argumente für das Aktivierungsereignis eine PreviousExecutionState-Eigenschaft, die Aufschluss über den Zustand der App vor der Aktivierung gibt.

Wenn der Benutzer zu einer anderen App wechselt oder das System in den Stromsparzustand wechselt, teilt Windows der App mit, dass sie angehalten wurde. Daraufhin müssen der Navigationszustand und alle Benutzerdaten der entsprechenden Benutzersitzung gespeichert werden. Darüber hinaus müssen exklusive Systemressourcen wie geöffnete Dateien und Netzwerkverbindungen freigegeben werden.

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

Nachdem die App auf das oncheckpoint-Ereignis (oder suspending) 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 Geräteressourcen zur Verfügung stehen. Wenn der Benutzer die App startet, nachdem sie von Windows beendet wurde, lautet der vorherige Ausführungszustand der App bei der Aktivierung terminated.

Mit dem vorherigen Ausführungszustand können Sie ermitteln, ob Ihre App die Daten wiederherstellen muss, die beim letzten Anhalten der App gespeichert wurden, oder ob die Standarddaten der App geladen werden müssen. Wenn die App nicht mehr reagiert oder vom Benutzer geschlossen wird, muss sie dem Benutzer nach einem Neustart grundsätzlich wieder im anfänglichen Standardnavigationszustand angezeigt werden. Wenn eine App nach der Beendigung aktiviert wird, muss sie die beim Anhalten gespeicherten Anwendungsdaten laden, damit die App wie zum Zeitpunkt des Anhaltens angezeigt wird.

Hinweis  Wenn die App zwar angehalten, aber nicht beendet wurde, können Sie sie ohne Zustandswiederherstellung fortsetzen. Die App befindet sich noch im Arbeitsspeicher. Unter Umständen müssen Sie in einer entsprechenden Situation jedoch Ressourcen erneut abrufen und die Benutzeroberfläche aktualisieren, um zwischenzeitlichen Änderungen an der App Rechnung zu tragen. So aktualisiert Hilo beispielsweise die App-Kachel, wenn die App aus dem angehaltenen Zustand fortgesetzt wird.

Eine Beschreibung des Vorgangs zum Anhalten/Fortsetzen finden Sie unter Anwendungslebenszyklus (Windows Store-Apps). Weitere Informationen zu den möglichen vorherigen Ausführungszuständen finden Sie in der ApplicationExecutionState-Enumeration. In den Richtlinien für das Anhalten und Fortsetzen von Apps (Windows Store-Apps) finden Sie außerdem Informationen zu empfohlenen Vorgehensweisen für das Anhalten und Fortsetzen.

[Oben]

Exemplarische Vorgehensweise mit Code zum Anhalten

Beim Starten von Hilo registriert der Bootstrapper einen Handler für oncheckpoint (oder suspending). Windows ruft diesen Ereignishandler vor dem Anhalten der App auf. Hier sehen Sie den Code:

Hilo\default.js


app.addEventListener("checkpoint", function (args) {
    // The app is about to be suspended, so we save the current
    // navigation history.
    app.sessionState.history = nav.history;
}, false);


Hilo verwendet den Ereignishandler, um den Navigationsverlauf der App synchron im sessionState-Objekt zu speichern. Das sessionState-Objekt dient zum Speichern von Daten, die genutzt werden können, um den App-Zustand nach dem Fortsetzen aus dem angehaltenen Zustand wiederherzustellen. Alle im sessionState-Objekt gespeicherten Daten werden automatisch auf dem Datenträger serialisiert, wenn die App angehalten wird.

Hinweis  Da Windows der App fünf Sekunden Zeit gibt, um das suspending-Ereignis zu behandeln, müssen alle von diesem oncheckpoint-Handler behandelten asynchronen Ereignisse innerhalb dieses Zeitrahmens abgeschlossen sein.

Falls die App bei aktiver Detailseite, Seite für die Bilddrehung oder Seite für den Bildzuschnitt angehalten wird, wird das QueryObject-Element für diese Seite serialisiert, damit beim Fortsetzen der App das richtige Foto geladen werden kann. Dies ist der Code.

Hilo\Hilo\imageQueryBuilder.js


toJSON: function () {
    return this;
},


Die toJSON-Methode wird automatisch aufgerufen, wenn das QueryObject-Element serialisiert wird. Die Implementierung fügt der integrierten Logik zwar nichts hinzu, soll aber demonstrieren, wo die Serialisierung bei Bedarf angepasst werden kann.

[Oben]

Exemplarische Vorgehensweise mit Code zum Fortsetzen

Wenn eine App aus dem Zustand suspended fortgesetzt wird, wechselt sie in den Zustand running und wird an dem Punkt fortgesetzt, an dem sie zuvor angehalten wurde. Es gehen keine Anwendungsdaten verloren, da sie im Arbeitsspeicher gespeichert wurden.

Eine angehaltene App kann auch nach Stunden oder sogar Tagen fortgesetzt werden. Wenn Inhalte oder Netzwerkverbindungen der App aktualisiert werden müssen, sollten dies bei der Fortsetzung geschehen. Angehaltene Apps empfangen keine Netzwerk- oder Dateiereigniselemente, für deren Empfang sie registriert sind. Aus diesem Grund muss Ihre App den Netzwerk- oder Dateistatus überprüfen, wenn sie fortgesetzt wird.

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 Miniaturansichten auf der App-Kachel zu aktualisieren. Hier sehen Sie den Code:

Hilo\default.js


Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", function (args) {
    var tileUpdater = new Hilo.Tiles.TileUpdater();
    tileUpdater.update();
}, false);


[Oben]

Exemplarische Vorgehensweise mit Code zur Aktivierung

Beim Starten einer App registriert der Bootstrapper einen Handler für das onactivated-Ereignis. Benutzer können eine App über verschiedene Verträge und Erweiterungen aktivieren, in Hilo muss allerdings nur der normale Start behandelt werden. Daher empfängt das onactivated-Ereignis ein Objekt vom Typ WebUILaunchActivatedEventArgs. Dieses Objekt enthält eine ApplicationExecutionState-Enumeration, die Aufschluss über den vorherigen Ausführungszustand der App gibt. Hier ist der Code.

Hilo\default.js


app.addEventListener("activated", function (args) {

    var currentState = args.detail;

    if (currentState.kind === activation.ActivationKind.launch) {

        if (currentState.previousExecutionState !== activation.ApplicationExecutionState.terminated) {

            // When the app is started, we want to update its tile
            // on the start screen. Since this API is not accessible 
            // inside of Blend, we only invoke it when we are not in
            // design mode.
            if (!Windows.ApplicationModel.DesignMode.designModeEnabled) {
                var tileUpdater = new Hilo.Tiles.TileUpdater();
                tileUpdater.update();
            }

            // Begin listening for changes in the `picturesLibrary`.
            // If files are added, deleted, or modified, update the 
            // current screen accordingly.
            Hilo.contentChangedListener
                .listen(Windows.Storage.KnownFolders.picturesLibrary);

        } else {
            // This app has been reactivated from suspension.
            // Restore app state here.
        }

        // If any history is found in the `sessionState`, we need to
        // restore it.
        if (app.sessionState.history) {
            nav.history = app.sessionState.history;
        }

        // After we process the UI (search the DOM for data-win-control),
        // we'll navigate to the current page. These are async operations
        // and they will return a promise.
        var processAndNavigate = WinJS.UI
            .processAll()
            .then(function () {

                if (nav.location) {
                    nav.history.current.initialPlaceholder = true;
                    return nav.navigate(nav.location, nav.state);
                } else {
                    return nav.navigate(Hilo.navigator.home);
                }
            });

        args.setPromise(processAndNavigate);
    }
}, false);


Der Code überprüft, ob die Anwendung gestartet wird. Falls ja, wird ihr previousExecutionState-Element überprüft, um zu ermitteln, ob der vorherige Zustand terminated lautete. Falls die App nicht beendet wurde, wird sie vom Handler so behandelt, als würde sie zum ersten Mal gestartet, und die Kacheln auf der Startseite werden aktualisiert. Anschließend wird ein Handler für das contentschanged-Ereignis registriert, damit die App benachrichtigt wird und entsprechend reagieren kann, wenn sich der Bilderordner des Benutzers ändert. Auch während die App angehalten ist, bleibt der Handler registriert, obwohl die App im angehaltenen Zustand keine contentschanged-Ereignisse empfängt. Wenn die App fortgesetzt wird, empfängt sie ein einzelnes Ereignis, mit dem alle Dateisystemänderungen aggregiert werden, die im angehaltenen Zustand der App aufgetreten sind.

Dann wird unabhängig davon, ob der vorherige Zustand terminated lautete, der im sessionState-Objekt enthaltene Navigationsverlauf wiederhergestellt (sofern vorhanden). Anschließend verarbeitet die processAll-Funktion die Seite und aktiviert alle WinJS-Steuerelemente, die im Seitenmarkup deklariert sind. Falls ein Navigationsverlauf vorhanden ist, navigiert die App zu der Seite, die beim Anhalten der App angezeigt wurde. Andernfalls navigiert sie zur Hubseite.

Falls der vorherige Zustand der App terminated lautete und beim Anhalten der App die Detailseite, die Seite für die Bilddrehung oder die Seite für den Bildzuschnitt aktiv war, wird das QueryObject-Element für die Seite deserialisiert. So kann das Foto, das beim Anhalten der App angezeigt wurde, erneut geladen werden.

Hilo\Hilo\imageQueryBuilder.js


deserialize: function (serializedQuery) {
    // Even though we pass in the entire query object, we really only care
    // about the settings. They allow us to reconstruct the correct query.
    var settings = serializedQuery.settings;

    if (typeof settings.monthAndYear === "string") {
        settings.monthAndYear = new Date(settings.monthAndYear);
    }

    return new QueryObject(settings);
}


Die deserialize-Funktion verwendet ein Abfrageobjekt und nutzt die Einstellungen des Abfrageobjekts zum Rekonstruieren der Abfrage. Die checkOptions-Funktion in der Datei "pageControlHelper.js", die beim Laden der einzelnen Seiten aufgerufen wird, ist für das Aufrufen der deserialize-Funktion zuständig. Hier ist der Code.

Hilo\Hilo\controls\pageControlHelper.js


function checkOptions(options, deserialize) {
    if (!options) { return; }

    deserialize = deserialize || Hilo.ImageQueryBuilder.deserialize;

    if (options.query) {
        var original = options.query;
        var query = deserialize(original);

        // Copy any properties that were not produced 
        // from the deserialization.
        Object.keys(original).forEach(function (property) {
            if (!query[property]) {
                query[property] = original[property];
            }
        });

        options.query = query;
    }
}


Die checkOptions-Funktion wird aus "page.js" aufgerufen, wobei nur der options-Parameter übergeben wird. Sofern also die options-Variable Daten enthält, wird die deserialize-Variable in der ImageQueryBuilder-Klasse auf die deserialize-Funktion festgelegt. Anschließend wird die deserialize-Funktion aufgerufen, um das Abfrageobjekt zu rekonstruieren, sofern die options-Variable eine Abfrage mit JSON-Serialisierung enthält und die Abfrage gerade nicht ausgeführt wird. Abschließend werden alle nicht deserialisierten Eigenschaften in das Abfrageobjekt kopiert.

[Oben]

Weitere Möglichkeiten zum Schließen der App

Apps besitzen kein UI-Element zum Beenden. Benutzer können Apps jedoch beenden, indem sie ALT+F4 drücken, die App an den unteren Bildschirmrand ziehen oder im Kontextmenü für die App die Option Schließen auswählen, wenn sich die App auf der Randleiste befindet. Apps, die mit einer dieser Methoden geschlossen wurden, wechseln für etwa 10 Sekunden in den notRunning-Zustand und anschließend 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.

Dieses Diagramm zeigt, wie Windows den Ausführungszustand einer App ermittelt. App-Abstürze und Benutzeraktionen zum Schließen werden von Windows ebenso berücksichtigt wie der Anhalte- und Fortsetzungszustand. Die blauen Rechtecke im Diagramm geben an, dass die App nicht in den Systemspeicher geladen wurde. Die grauen Rechtecke geben an, dass sich die App im Arbeitsspeicher befindet. Bei den blauen Linien handelt es sich um Änderungen, die ohne Benachrichtigung der ausgeführten App auftreten. Die schwarzen Linien stehen für Aktionen mit App-Benachrichtigung.

App-Ausführungszustände

[Oben]

 

 

Anzeigen:
© 2014 Microsoft