Moderne Apps

Artikel
03/10/2015

Der Lebenszyklus einer Windows Store-App

Rachel Appel Durch Windows 8 verändert sich, wie und wann Anwendungen ausgeführt werden. Lernen Sie die Nuancen des neuen Anwendungslebenszyklus kennen, damit Sie Apps erstellen können, die jederzeit erwartungsgemäß reagieren. Apps, die den Microsoft-Richtlinien zur Lebenszyklusverwaltung entsprechen, bieten ein besseres Benutzererlebnis. Dies trifft insbesondere bei kleinen Geräten zu, bei denen Arbeitsspeicher und Akku geschont werden.

Anwendungsentwurf

Windows Store-Apps liegen zwei wichtige Entwurfskonzepte zugrunde: Die Apps können im Vollbildmodus, im angedockten oder gefüllten Modus ausgeführt werden, und die Apps müssen sehr reaktionsfähig sein, damit die Benutzer sich ohne viele Ablenkungen auf den aktuellen Inhalt konzentrieren können. Diese zwei Grundsätze gewährleisten, dass die aktuell ausgeführte App alle verfügbaren Ressourcen – vom Betriebssystem und vom Benutzer – erhält, während bei Desktop-Apps für Windows 8 oder Apps früherer Windows-Versionen diese Ressourcen gemeinsam genutzt wurden.

Alle Windows Store-Apps verfügen über vier Status: wird nicht ausgeführt, wird ausgeführt, angehalten und beendet. Wenn Sie eine App starten, wird sie ausgeführt. Je nach Benutzer- oder Systemaktivität kann die App später zwischen den Status „wird ausgeführt“ und „angehalten“ wechseln. Wenn der Benutzer zum Beispiel von App A zu App B wechselt, hält Windows App A nach einer kurzen Verzögerung an und verschiebt sie in den Hintergrund. App A bleibt angehalten (bis der Benutzer zu ihr zurückkehrt oder sie von Windows beendet wird), während App B aktiviert und in den ausgeführten Status verschoben wird (möglicherweise aus dem angehaltenen Status, falls sie bereits im Arbeitsspeicher war). Wenn der Benutzer zu App A zurückkehrt, wird die App einfach von Windows reaktiviert. Für das Betriebssystem und die App gilt, dass die App die ganze Zeit ausgeführt wurde. Dann ist natürlich App B an der Reihe, angehalten zu werden.

Weist eine App den angehaltenen Status auf, wird ihr Code nicht ausgeführt, und die App bleibt so, wie sie ist, im Arbeitsspeicher. Im Grunde wird die App zwischengespeichert und ist sofort einsatzbereit, wenn der Benutzer zurückwechselt. Das ist allerdings nicht alles. Wenn Sie die richtigen Verfahren befolgen, können Sie Hintergrundaufgaben ausführen, und Windows kann Apps beenden, wenn der Arbeitsspeicher dies erfordert. In Abbildung 1 wird gezeigt, wie Apps zwischen den Ausführungsstatus wechseln. Weitere Informationen dazu finden Sie unter bit.ly/TuXN9F.

How Windows Store Apps Move Between Execution States
Abbildung 1: Wechseln von Windows Store-Apps zwischen den Ausführungsstatus

Wie Abbildung 1 nahelegt, kann eine App häufig zwischen dem ausgeführtem und dem angehaltenem Status wechseln. Die Statusübergänge im Lebenszyklus der App verdeutlichen den Unterschied zwischen Windows Store-Apps und traditionellen Desktop-Apps.

Visual Studio 2012 umfasst einen umfangreichen Satz Debugtools und Windows Simulator (bit.ly/QzBy5I), um Lebenszyklusoperationen für Apps zu verwalten. Das ist wichtig, da Sie auf Lebenszyklusereignisse der App richtig reagieren und Statusübergänge ordnungsgemäß verarbeiten müssen, um für die Endbenutzer eine schnelle Reaktionsfähigkeit bereitzustellen. Dies ist ein Kernprinzip des App-Entwurfs für Windows 8. Durch die entsprechende Reaktion auf Lebenszyklusereignisse der App können Sie eine konsistente Benutzerfreundlichkeit im gesamten Lebenszyklus der App gewährleisten. Das bedeutet insbesondere Speichern und Wiederherstellen des App-Status, wenn es erforderlich ist. Dazu kann gehören, an die Stelle zurückzukehren, an der der Benutzer die Anwendung verlassen hat (beispielsweise in einem Assistenten), die Werte eines vom Benutzer bearbeiteten Formulars erneut aufzufüllen oder zum zuletzt gelesenen Artikel zurückzukehren. Der Anwendungslebenszyklus wird von der Bewegung der Benutzer durch die App gesteuert. Daher muss die App in kürzester Zeit bereit sein, einen Prüfpunkt für ihren Status festzulegen, sobald sie das Ereignis zum Anhalten erhält.

App-Aktivierung

Der Prozess WWAHOST.EXE ist ein App-Host, der Windows Store-JavaScript-Apps ausführt. XAML-Apps in jeder beliebigen Sprache, zum Beispiel C#, Visual Basic oder C++, führen die entsprechende ausführbare Datei der App aus. In jedem Fall durchlaufen alle Apps die Aktivierung, die eine Reihe von Katalysatoren aufweist:

Der Benutzer startet eine App von einer Kachel.
Der Benutzer wechselt zu einer angehaltenen App.
Windows startet die App über einen Vertrag für „Suche“ oder „Ziel freigeben“.
Windows ruft eine Protokollzuordnung (URI-Schema) auf (bit.ly/QyzX04) oder startet eine App aufgrund einer Dateizuordnung.
Windows ruft eine Erweiterung auf, zum Beispiel einen „Auswahlvertrag zum Öffnen von Dateien“ oder eine „Inhaltsauswahl“.

Wie die Aktivierung vor sich geht, hängt davon ab, welcher Code auszuführen ist. Ein Start von einer Kachel, über einen Vertrag oder ein Protokoll führt dazu, dass eine Windows-Bibliothek für JavaScript(WinJS)-App ein aktiviertes Ereignis auslöst und eine XAML-App ein OnLaunched-Ereignis auslöst. Während dieser Ereignisse wird der vorherige Status der App geprüft, um entsprechende Aktionen auszuführen.

Wenn die App aus dem nicht ausgeführten Status in den Ausführungsstatus wechselt, müssen neue Daten geladen werden, da dieser Übergang anzeigt, dass die App über eine Kachel, einen Charm, ein Protokoll oder eine Erweiterung gestartet wurde. Wenn die App aus dem angehaltenen Status zurückkehrt, muss im Allgemeinen nichts passieren. Der Benutzer nimmt seine Tätigkeit dort wieder auf, wo er sie unterbrochen hatte. Wenn die App aus dem Beendet-Status in den Ausführungsstatus zurückwechselt, müssen die Daten erneut geladen werden. Außerdem ist eine Navigation in der App an die Stelle erforderlich, an der der Benutzer sich zuletzt befand (es sei denn, die letzte Verwendung ist Monate her). Der Code zum Verarbeiten der Aktivierung wird in Abbildung 2 in JavaScript und in Abbildung 3 in C# dargestellt. Wie der Code zeigt, können Sie sowohl auf den vorherigen Ausführungsstatus als auch darauf testen, wie Windows die App gestartet hat, da die Windows-API eine praktische Reihe von Enumerationen für beide Fälle bietet. Sobald Sie über diese Informationen verfügen, können Sie die Daten nach Bedarf neu füllen.

Das JavaScript-aktivierte Ereignis und das XAML-OnLaunched-Ereignis enthalten beide ein args-Argument, das Sie abfragen können, um den Status der App vor der Aktivierung zu bestimmen. In Abbildung 2 und 3 werden Beispiele für das aktivierte Ereignis gezeigt.

Abbildung 2: App-Aktivierungscode in JavaScript

var app = WinJS.Application;
var activation = Windows.ApplicationModel.Activation;
var nav = WinJS.Navigation;
app.addEventListener("activated", function (args) {
  if (args.detail.kind === activation.ActivationKind.launch) {
    if (args.detail.previousExecutionState !==
      activation.ApplicationExecutionState.terminated) {
      // TODO: This application has been newly launched.
      // Initialize your application here.
    } else {
      // TODO: This application has been reactivated from suspension.
      // Restore application state here.
    }
    if (app.sessionState.history) {
        nav.history = app.sessionState.history;
    }
    args.setPromise(WinJS.UI.processAll().then(function () {
      if (nav.location) {
          nav.history.current.initialPlaceholder = true;
          return nav.navigate(nav.location, nav.state);
      } else {
        return nav.navigate(Application.navigator.home);
      }
    }));
  }
});

Abbildung 3: App-Aktivierungscode in C#

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 that
      // handles restoring session data from a file and
      // then gives access to that data through a Dictionary.
      await SuspensionManager.RestoreAsync();
// Retrieve the data for restore.                 
data = SuspensionManager.SessionState["savedData"];
    }
    // If not, use the app's default values
    else
            {
data = "Welcome";
    }
    Window.Current.Activate();
}

Während der Aktivierung ausgeführter Code muss innerhalb von 15 Sekunden ausgeführt werden, andernfalls beendet Windows die App. Das mag streng erscheinen, aber Apps, die die Benutzer so lange von Interaktionen mit der Benutzeroberfläche abhalten, sind nicht reaktionsfähig. UseIt.com hat Untersuchungen zu Benutzern und Antwortzeiten durchgeführt (bit.ly/NWSumy). Demnach verlassen die meisten Benutzer Websites, die länger als 10 Sekunden zum Laden benötigen. Die Benutzer reagieren tatsächlich bereits frustriert, wenn Seiten mehr als 1 oder 2 Sekunden zum Laden benötigen, und verlassen die Seite möglicherweise lange vor der 10-Sekunden-Marke. Diese Information über Benutzer ist besonders wichtig, wenn Sie Ihre App im Windows Store anbieten möchten, denn frustrierte Benutzer veröffentlichen negative Bewertungen zu Apps, ganz davon abgesehen, dass die App bei schlechter Leistung vielleicht keine Zertifizierung für den Store erhält. Weitere Informationen zum Übermitteln von Apps erhalten Sie unter bit.ly/OxuEfu. Welche Daten wann geladen werden, erfordert sorgfältige Überlegung. Die Bibliotheken der Windows-Runtime (WinRT) machen es glücklicherweise einfach, Daten schnell und progressiv zu laden, da sie ein erstklassiges asynchrones Programmiermodell bieten (bit.ly/NCx6gE).

Das Windows.ApplicationModel.Activation-Objekt ist ein Teil der Windows-API, auf die alle Windows Store-Apps unabhängig von der Sprache zugreifen können. Das Activation-Objekt enthält eine activationKind-Auflistung mit den folgenden Werten:

Launch: Der Benutzer hat die App gestartet oder auf eine sekundäre Kachel getippt.
Search: Der Benutzer möchte mit der App suchen.
ShareTarget: Die App wird als Ziel für Freigabevorgänge aktiviert.
File: Eine App hat eine Datei gestartet, deren Dateityp für die Verarbeitung durch diese App registriert ist.
Protocol: Eine App hat eine URL gestartet, deren Protokoll für die Verarbeitung durch diese App registriert ist.
FileOpenPicker: Der Benutzer möchte Dateien oder Ordner auswählen, die von der App bereitgestellt werden.
FileSavePicker: Der Benutzer möchte eine Datei speichern und hat die App als den Speicherort ausgewählt.
CachedFileUpdater: Der Benutzer möchte eine Datei speichern, für die die App die Inhaltsverwaltung bereitstellt.
ContactPicker: Der Benutzer möchte Kontakte auswählen.
Device: Die App verarbeitet die automatische Wiedergabe.
PrintTaskSettings: Die App verarbeitet Druckaufgaben.
CameraSettings: Die App nimmt Fotos oder Videos von einer angeschlossenen Kamera auf.

Ihre App kann mehrere Features unterstützen, zum Beispiel die Freigabe und Suche. Mit der activationKind-Auflistung können Sie sehen, was die Absicht des Benutzers beim Starten der App ist, und anschließend entsprechenden Code ausführen.

Verwalten von Anhalten, Beenden und Fortsetzen

Wenn ein Benutzer zu einer anderen App wechselt oder das Gerät in den Ruhezustand bzw. Standbymodus übergeht, hält Windows die Ausführung des App-Codes an, behält die App aber im Arbeitsspeicher. Der Grund für diese Unterbrechung ist, dass Windows bei Apps, die der Benutzer nicht aktiv nutzt, deren Auswirkungen auf Akku und Leistung minimiert. Wenn Windows die App aus der Unterbrechung oder einer kurzen Beendigung wieder aktiviert, soll es für den Benutzer so aussehen, als ob die App ohne Unterbrechung weiter ausgeführt worden wäre. Die ordnungsgemäße Verarbeitung von Lebenszyklusereignissen gewährleistet ein reaktionsfähiges Design.

Windows startet den Unterbrechungsprozess mit dem Auslösen von einem WinJS-oncheckpoint-Ereignis oder einem XAML-OnSuspending-Ereignis, in dem Sie Daten und Benutzerinformationen speichern können, bevor die App in den angehaltenen Modus wechselt. Jeder Code, den Sie in diesen Ereignissen ausführen, muss innerhalb von 10 Sekunden abgeschlossen sein, da Windows andernfalls die App vollständig stoppt. Genau wie beim Aktivierungsprozess gewährleistet diese Regel einen stabilen Gesamtzustand des Betriebssystems und ermöglicht schnelles Wechseln. Die Einbindung des oncheckpoint-Ereignisses erfordert eine einfache Funktionsdefinition:

app.oncheckpoint = function (args) {
  // Save app data in case of termination.
};

In XAML verwenden Sie ein Application.Suspending-Ereignis:

async void Suspending(Object sender,
  Windows.ApplicationModel.SuspendingEventArgs e) {
  // Save app data in case of termination.
}

Während der Unterbrechung müssen Sie die Position des Benutzers oder die Position beim Blättern in der App speichern, Dateihandles und Verbindungen freigeben sowie Datums- und Zeitangaben für die Daten bestimmen. Das können Sie mithilfe der integrierten WinJS.Application.sessionState- oder XAML-SuspensionManager-Objekte erreichen. Sie sollten die Benutzerinformationen und App-Daten immer im Unterbrechungsereignis speichern, da Windows die Apps vor ihrer Beendigung nicht benachrichtigt. Ein wichtiger Aspekt, denn die Beendigung kann bei einer Reihe von Fällen vorkommen, zum Beispiel wenn Windows Arbeitsspeicher freigeben muss oder das Gerät an (Akku-) Leistung verliert.

Codieren Sie daher vorausschauend, und gehen Sie davon aus, dass die App beendet wird. Das heißt, dass Sie die App-Daten jedes Mal in „sessionState“ speichern. Wenn Windows die App beendet, sind die Daten gespeichert und können zum erneuten Auffüllen dienen.

Zur Wiederaufnahme kommt es, wenn Windows eine angehaltene App wieder aktiviert. Meisten setzt Windows die App einfach fort, wenn der Benutzer zu ihr zurückwechselt oder sie erneut startet. Dazu müssen Sie keinen Code schreiben. Während der Unterbrechung befindet sich die App einfach unbehelligt im Arbeitsspeicher, ihre Inhalte bleiben unverändert, und Sie müssen nichts unternehmen.

Die meisten unterbrochenen Apps können ohne weiteres Zutun fortgesetzt werden. Aber Apps wie beispielsweise RSS-Feeds, Aktien oder soziale Netzwerke, die sich häufig verändernde Daten enthalten, eignen sich gut für das Wiederaufnahmeereignis. Da das Wiederaufnahmeereignis für diese wenigen spezifischen Szenarios infrage kommt, befindet es sich im Windows.UI.WebUI.WebUIApplication-Objekt und nicht im gängigeren WinJS.Application-Objekt neben den oncheckpoint- und onactivated-Ereignissen sowie anderen verwandten Lebenszyklusereignissen:

Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", function () {
  // Repopulate data from sessionState.
});

Sie können den Wiederaufnahmehandler der Datei DEFAULT.JS hinzufügen, aus Gründen der Codeorganisation in der Nähe des Aktivierungscodes. Ihre App bleibt reaktionsfähig, wenn Sie während der Wiederaufnahme schnell nur die Mindestdatenmenge laden.

Hintergrundaufgaben und Echtzeitkommunikations-Apps

Obwohl der Benutzeroberflächencode nicht ausgeführt wird, während sich eine App im Unterbrechungsmodus befindet, kann die App Hintergrundaufgaben ausführen (bit.ly/QyRvsU), große Dateien übertragen oder auf E-Mails prüfen. Einige Echtzeitkommunikations-Apps, z. B. IM-Clients, müssen die Benutzer benachrichtigen können, wenn eine Nachricht eingeht. Dabei spielt der Ausführungsstatus der App keine Rolle.

Hintergrundaufgaben sind einfache Klassen, die mit bestimmten Einschränkungen regelmäßig ausgeführt werden, während die App technisch nicht ausgeführt wird. Sie werden in ihren eigenen Sandboxes oder App-Containern ausgeführt, während die App in einem nicht ausgeführten Status verbleibt. JavaScript-Hintergrundaufgaben werden in einem neuen Apartment mit einem Thread von WWAHOST.EXE ausgeführt; Nicht-JavaScript-Hintergrundaufgaben werden in einer prozessintegrierten .DLL ausgeführt, die in ihrem eigenen Threadapartment in der App geladen wird. Durch diese Trennung können Hintergrundaufgaben unabhängig von der Benutzeroberfläche einer App ausgeführt werden, die angehalten bleibt, bis der Benutzer zu ihr zurückkehrt.

Diese Apps können nicht nur Code im Hintergrund ausführen, sondern auch Informationen im Sperrbildschirm anzeigen. Der Sperrbildschirm enthält ein Hintergrundbild mit einfachen Informationen darauf, wie Zeit, Datum, Akkustatus und Netzwerkstatus. Zusätzlich dazu können Apps, speziell die im Hintergrund ausgeführten Apps, Informationen im Sperrbildschirm anzeigen. Der Sperrbildschirm muss leicht verständlich sein, daher können nur begrenzt Informationen dargestellt werden. Der Sperrbildschirm kann Signale von bis zu sieben Apps und den Kacheltext von einer einzelnen App anzeigen. Weitere Informationen dazu erhalten Sie in der Übersicht über den Sperrbildschirm unter bit.ly/RsE7pj.

Befolgen des Modells

Als Entwickler von Windows Store-Apps müssen Sie Aspekte wie Akkulaufzeit und ungenügenden Arbeitsspeicher berücksichtigen, da Ihre App auf einer Vielzahl von Geräten ausgeführt wird. Am wichtigsten ist die UX. Sie werden Ihre Ziele leichter erreichen, wenn Sie die zuvor beschriebenen Richtlinien zur Lebenszyklusverwaltung beherzigen. Neben den technischen Gründen für die Lebenszyklusverwaltung von Apps wird Ihre App außerdem bessere Bewertungen im Windows Store erhalten, wenn sie eine hohe Reaktionsfähigkeit und eine gute Leistung aufweist.

Rachel Appel arbeitet als Developer Evangelist bei Microsoft in New York City. Sie kann über ihre Website unter rachelappel.com oder per E-Mail unter rachel.appel@microsoft.com erreicht werden. Sie können auch Rachel Appels aktuelle Neuigkeiten auf Twitter unter twitter.com/rachelappel verfolgen.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Adam Barrus, Ben Betz, Arun Kishan, Michael Krause, Hari Pulapaka, John Sheehan und Ben Srour.