Lebenszyklusverwaltung und dynamische Apps

Entwicklerblog für Windows 8-Apps

Ein Einblick in die Entwicklung von Apps im Metro-Stil – präsentiert vom Windows 8-Entwicklerteam

Lebenszyklusverwaltung und dynamische Apps

  • Comments 1

Das Lebenszyklusmodell für Apps unter Windows 8 hat den Vorteil, dass Benutzer sich nicht mehr darum kümmern müssen, welche Apps ausgeführt werden. Darüber hinaus vereinfacht dieses Modell Entwicklern, herausragende Apps bereitzustellen, die Akkulaufzeit und Leistung des Gerätes nicht beeinträchtigen, wenn die Apps im Hintergrund ausgeführt werden. Mithilfe der neuen Lebenszyklusereignisse sind Apps stets bereit, obwohl sie nur ausgeführt werden, solange Sie auf dem Bildschirm angezeigt werden.

Die Akkulaufzeit von Laptops, Tablets und Telefonen verkürzt sich oftmals, da Benutzer dazu neigen, Apps auch dann weiter auszuführen, wenn sie diese nicht verwenden. Dies erfolgt aus Bequemlichkeit und um schnell zwischen Apps wechseln zu können.

Bei der Entwicklung des Lebenszyklusmodells für Apps im Metro-Stil unter Windows 8 ging es daher darum, Apps reaktionsfähig zu halten, die Akkulaufzeit zu erhalten und durchgehend herausragende Leistung sicherzustellen. Bei Apps im Metro-Stil dreht sich alles um die immersive Vollbilddarstellung. Aus diesem Grund ist das neue Lebenszyklusmodell unter Windows 8 ganz auf die Apps im Vordergrund ausgerichtet und stellt sicher, dass der jeweils verwendeten App die volle Leistung des Geräts zur Verfügung steht. In diesem Beitrag werde ich die Status des Lebenszyklusmodells vorstellen und erläutern, wie Sie herausragende Apps erstellen.

Lebenszyklus von Apps im Metro-Stil

Apps im Metro-Stil befinden stets in einem von vier Lebenszyklusstatus: not running, running , suspended oder terminated. Beim Wechsel von einem Status zu einem anderen empfängt eine App Lebenszyklusereignisse, mit denen sichergestellt wird, dass zu keinem Zeitpunkt Leistungseinbußen auftreten.

Dieses Diagramm zeigt den Wechsel einer App im Metro-Stil von einem Status zu einem anderen:

3 durch Pfeile, die den Lebenszyklus darstellen, verbundene Felder. Wird nicht ausgeführt > Wird aktiviert > Wird ausgeführt > Wird angehalten > Angehalten > Wird beendet > Nicht ausgeführt.

Alle Apps im Metro-Stil wechseln zwischen diesen Status, wenn Benutzer Apps starten, zwischen ihnen wechseln oder Apps schließen. Apps werden häufig vom Status running in den Status suspended übergehen, wenn Benutzer zwischen Apps wechseln. Daher müssen Apps die Lebenszyklusereignisse verarbeiten.

Während Ihre App von einem Status in den anderen übergeht, empfängt sie die folgenden Ereignisse:

Ereignis Von Zu

„activated“

„not running“

„running“

„suspending“ oder „checkpoint“ (WinJS)

„running“

„suspended“

„resuming“

„suspended“

„running“

Anhalten von Apps

In der Regel werden Apps im Metro-Stil nicht weiter ausgeführt, wenn der Benutzer zu einer anderen App wechselt. Windows beendet Apps, die nicht im Vordergrund ausgeführt werden. Der Status angehaltener Apps wird im Speicher beibehalten. Die Apps kann so nicht ausgeführt werden, jedoch kann Windows die App unmittelbar fortsetzen, wenn der Benutzer zu ihr zurückkehrt. Auf diese Weise stellt Windows sicher, dass der App im Vordergrund mehr Systemressourcen zur Verfügung stehen und verhindert, dass Apps im Hintergrund Akkuleistung benötigen.

Wird eine App nicht mehr im Vordergrund ausgeführt, wartet Windows einige Sekunden, bevor die App angehalten wird, um ein schnelles Zurückkehren zur App zu ermöglichen. Sie müssen die App für die (JavaScript-)Ereignisse „suspending“ oder „checkpoint“ registrieren. Mithilfe dieser Ereignisse wird die App von Windows angehalten. Dieser Zeitraum ist für die Ausführung der App besonders wichtig. Nutzen Sie diesen, um die App-Daten zu speichern, die in einem beständigen Speicher gehalten werden müssen. In der Regel wird eine App im aktuellen Zustand fortgesetzt. Ein Zugriff auf die Daten im beständigen Speicher ist nicht erforderlich, da sich diese noch im Arbeitsspeicher befinden. Sie müssen diese Daten jedoch für den Fall speichern, dass Windows die App beendet, um Systemressourcen freizugeben. Speichern Sie alle App-Daten, die benötigt werden, damit der Benutzer die App an der Stelle fortsetzen kann, an der diese angehalten wurde. Auf diese Weise erleben Benutzer die App so, als ob diese dauerhaft ausgeführt würde.

Die App wird von Windows beendet, wenn nicht innerhalb von fünf Sekunden nach Empfang des „suspending“-Ereignisses Daten mithilfe des „suspending“-Ereignishandlers zurückgegeben werden. Es ist wichtig, im „Suspending“-Ereignishandler keine komplexen Vorgänge auszuführen. Speichern Sie die App-Daten und kehren sie schnell zurück.

In diesem Beitrag verwenden wir eine Börsen-App als Beispiel. Diese App kann das „suspending“-Ereignis verwenden, um die Aktie, die vom Benutzer zuletzt angezeigt wurde, sowie den Verlauf des Aktienkurses zu speichern. Anschließend kann die App – wenn sie beendet wurde – mit der zuletzt verwendeten Ansicht neu gestartet werden. Für die Börsen-App wird beispielsweise empfohlen, dies als weitere Gelegenheit zu nutzen, eine lokale Kachel-Benachrichtigung zu senden, mit der die App-Kachel aktualisiert wird, bevor die App von Windows angehalten wird.

Anhalten von Apps in JavaScript

Wenn Sie eine App im Metro-Stil mithilfe der Windows-Bibliothek für JavaScript (WinJS) schreiben, können Sie das checkpoint-Ereignis zum Anhalten der App verwenden.

var app = WinJS.Application;

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

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

app.addEventListener("checkpoint", checkpointHandler);

Dies ist lediglich ein Überblick. Weitere Informationen finden Sie im Entwicklungscenter unter Anhalten einer App (JavaScript und HTML).

Anhalten von Apps in XAML

Wenn Sie eine App im Metro-Stil mithilfe von XAML und C# schreiben, können Sie das suspending-Ereignis des Anwendungsobjekts zum Anhalten der App verwenden.

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

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

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

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

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

deferral.Complete();
}

Dies ist ebenfalls nur ein Überblick. Weitere Informationen zum Anhalten von Apps in XAML und C# finden Sie im Entwicklungscenter unter Anhalten einer App (VB/C#/C++ und XAML).

Fortsetzen von Apps

Apps werden in dem Status fortgesetzt, in dem diese sich befunden haben, als sie von Windows angehalten wurden. Im Einzelnen bedeutet das: Die Daten und Status der App werden beim Anhalten im Speicher behalten. Wenn die App fortgesetzt wird, ist alles so wie es war, bevor die App angehalten wurde. Gespeicherte Daten müssen beim Empfang des resuming-Ereignisses nicht explizit wiederhergestellt werden.

Sie möchten jedoch, dass sich eine App so verhält, als würde sie dauerhaft ausgeführt. Deshalb muss die App stets aktuelle Daten anzeigen können. Möglicherweise verbleibt eine App längere Zeit im angehaltenen Zustand, bevor sie fortgesetzt wird. Daten oder Netzwerkverbindungen müssen möglicherweise aktualisiert werden, wenn die App fortgesetzt wird. Wenn ein Benutzer eine App wieder im Vordergrund ausführt, empfängt die App ein resuming-Ereignis. Sie können den App-Inhalt aktualisieren und die Netzwerkverbindung wieder herstellen, wenn eine App dieses Ereignis empfängt.

Bei unserer Beispiel-App ist das Fortsetzen der richtige Moment, um die gesamten zwischengespeicherten Börsendaten zu aktualisieren. Die vorherigen Daten sind möglicherweise Stunden oder sogar Tage alt. Für den Benutzer erscheint die App nur dann als ständig aktiv, wenn aktuelle Daten angezeigt werden. Also müssen beim Fortsetzen der Börsen-App alle entsprechenden Daten aktualisiert werden. Auf diese Weise sieht der Benutzer immer die neusten Aktienpreise, Diagramme und Nachrichten, wenn die App im Vordergrund ausgeführt wird.

Fortsetzen von Apps in JavaScript

In JavaScript können Sie das Windows-Runtime-Ereignis resuming im Windows.UI.WebUI.WebUIApplication -Namespace verwenden. Hierbei handelt es sich um ein besonderes „resuming“-Ereignis, das nur für JavaScript-Apps vorgesehen ist.

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

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

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

Weitere Informationen finden Sie im Entwicklungscenter unter Fortsetzen einer App (JavaScript und HTML).

Fortsetzen von Apps in XAML

Wenn Sie eine App im Metro-Stil mithilfe von XAML und C# schreiben, können Sie das resuming-Ereignis des Anwendungsobjekts zum Fortsetzen der App verwenden.

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

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

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

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

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

Weitere Informationen zum Fortsetzen von Apps in VB/C#/C++ und XAML finden Sie im Entwicklungscenter unter Fortsetzen einer App (VB/C#/C++ und XAML).

Aktivieren von Apps

Bei der Aktivierung geht es darum, wie Ihre App gestartet wird. Bei einer App im Metro-Stil dient dies zu unterschiedlichen Zwecken. Weitere ausführliche Informationen darüber, wie Sie die die Aktivierung von Apps im Metro-Stil zur Behandlung von Verträgen verwenden können, finden Sie in unserem früheren Beitrag Aktivierung von Windows 8-Verträgen in Apps. Hier konzentrieren wir uns darauf, wie Sie die Aktivierung verwenden können, um zuvor gespeicherte Daten wiederherzustellen, falls die App von Windows beendet wurde und der Benutzer sie erneut startet.

Eine angehaltene App kann aus einer Reihe von Gründen durch Windows beendet werden. Zum Beispiel: Der Benutzer schließt die App manuell, meldet sich ab oder es müssen Systemressourcen freigegeben werden (einige Apps wie beispielsweise Spiele können sehr ressourcenintensiv sein!). Wenn der Benutzer eine App startet, nachdem diese von Windows beendet wurde, empfängt diese ein activated-Ereignis und dem Benutzer wird der Begrüßungsbildschirm der App angezeigt, bis die App aktiviert ist. Sie können dieses Ereignis verwenden, um zu ermitteln, ob Daten, die die App beim letzen Anhalten gespeichert hat, wiederhergestellt werden müssen oder ob die Standarddaten der App geladen werden können. Die activated-Ereignisargumente enthalten eine PreviousExecutionState-Eigenschaft, die den Status der App vor der Aktivierung enthält. Diese Eigenschaft ist einer der Werte der Windows.ApplicationModel.Activation.ApplicationExecutionState-Enumeration.

Grund des Beendens „PreviousExecutionState“-Wert Erforderliche Maßnahme
Vom System beendet (aufgrund von Ressourceneinschränkungen, Herunterfahren, Neustart usw.)

Terminated

Sitzungsdaten wiederherstellen

Vom Benutzer geschlossen

ClosedByUser

Mit Standarddaten starten

          Unerwartet beendet oder App seit Sitzungsbeginn nicht ausgeführt

NotRunning

Mit Standarddaten starten

PreviousExecutionState kann auch die Werte Running oder Suspended enthalten. In diesen Fällen wurde Ihre App jedoch nicht zuvor beendet, und Sie müssen sich keine Gedanken um die Wiederherstellung von Daten machen.

Wenn Ihre App aktiviert ist und der PreviousExecutionState der App Terminated war, müssen gespeicherte Sitzungsdaten wiederhergestellt werden, damit die App angezeigt wird wie zum Zeitpunkt des Beendens. Wenn der Benutzer die App manuell geschlossen hat, die App unerwartet beendet wurde oder in der aktuellen Sitzung noch nicht ausgeführt wurde, müssen die vorherigen Sitzungsdaten ignoriert werden. Die App muss in der Standardansicht gestartet werden.

Unsere Beispiel-App verwendet das activated-Ereignis, um die Aktien- und Diagramminformationen wiederherzustellen, die beim Anhalten gespeichert wurden. Auch die zwischengespeicherten Netzwerkdaten der App werden aktualisiert. Auf diese Weise wird dem Benutzer die Aktie angezeigt, die sich dieser vor dem Beenden der App angesehen hat. Die Aktienpreise, Diagramme und Nachrichten sind jedoch auf dem neusten Stand.

Aktivieren von Apps in JavaScript

Wenn Sie eine App im Metro-Stil mithilfe der Windows-Bibliothek für JavaScript (WinJS) schreiben, können Sie das activated-Ereignis zum Aktivieren der App verwenden.

Im activated-Ereignishandlercode, kann Ihre App das sessionState-Object überprüfen, um zu ermitteln, ob gespeicherte Daten geladen werden müssen oder ob die Standartstartseite angezeigt werden soll. SessionState ermittelt mithilfe von eventArgs.detail.previousExecutionState automatisch den letzten Zustand der App. Wenn sessionState Daten enthält, können Sitzungsdaten wiederhergestellt werden. Verwenden Sie andernfalls die Standarddaten der App.

var app = WinJS.Application;

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

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

app.addEventListener("activated", activatedHandler);
       

Weitere Informationen zur Aktivierung von Apps in JavaScript finden Sie im Entwicklungscenter unter Aktivieren einer App (JavaScript und HTML).

Aktivieren von Apps in XAML

Bei einer App im Metro-Stil in XAML und C# können Sie das OnLaunched-Ereignis überschreiben, um die Aktivierung so auszuführen, wie die Aktivierung über eine Kachel.

Im „OnLaunched“-Ereignishandlercode kann Ihre App in den Ereignisargumenten den PreviousExecutionState überprüfen. Stellen Sie die im Suspending-Ereignis gespeicherten Daten wieder her, wenn dieser Terminated lautet. Verwenden Sie andernfalls die Standarddaten der App.

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

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

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

Window.Current.Activate();
}

Weitere Informationen zur Aktivierung von Apps in XAML finden Sie im Entwicklungscenter unter Aktivieren einer App (VB/C#/C++ und XAML).

Tipps zum Erstellen von herausragenden Apps

Nachdem Sie nun alle Grundlagen kennengelernt haben, haben wir noch ein paar Tipps, mit denen Sie Apps erstellen können, die sich so verhalten, als würden sie dauerhaft ausgeführt.

Manchmal ist das Beste, neu anzufangen

Wenn ein Benutzer eine App längere Zeit nicht verwendet hat, ist es manchmal das Beste, die App auf die Standardansicht zurückzusetzen. Die Entscheidung über den Zeitraum liegt bei Ihnen. Wir raten zur Standardansicht, wenn die Inhalte der App veralten. Auf diese Weise erscheint die App benutzerfreundlicher.

Wenn Sie zum Beispiel eine Nachrichten-App erstellen, können Sie davon ausgehen, dass diese angehalten wird, wenn der Benutzer die App nicht verwendet. Die App wird fortgesetzt, wenn der Benutzer sie erneut aufruft. Überprüfen Sie im „resume“-Handler, wie alt der gegenwärtige Artikel ist, um zu ermitteln, ob dieser als veraltet betrachtet werden soll. Zeigen Sie die Standardstartseite an, wenn der Artikel zu alt ist.

Speichern der richtigen Daten zur richtigen Zeit

Speichern Sie wichtige Daten während dem Ausführen der App in regelmäßigen Abständen. Da der App nur bis zu 5 Sekunden bleiben, um den „suspending“-Ereignishandlercode auszuführen, sollten wichtige App-Daten zum Zeitpunkt des Anhaltens bereits in einem beständigen Speicher gesichert sein.

Sie müssen beim Schreiben Ihrer Apps zwei Arten von Daten verwalten: Sitzungsdaten und Benutzerdaten. Sitzungsdaten sind temporäre Daten, die der Benutzer benötigt, während die App ausgeführt wird. Beispielsweise ein Aktie, die sich der Benutzer gerade ansieht, die Seite, die der Benutzer auf einem eBook ließt oder die Position des Bildlaufs in einer längeren Liste. Benutzerdaten sind beständige Daten, die jederzeit verfügbar sein müssen. Beispielsweise ein angefangenes Dokument, das der Benutzer erstellt, ein Foto, das mit der App aufgenommen wurde oder der Fortschritt des Benutzers in einem Spiel.

Stellen Sie sicher, dass beide Arten von Daten zum Zeitpunkt des Anhaltens der App in einem beständigen Speicher gesichert sind.

Wiederherstellen von Sitzungsdaten

Benutzer erwarten von einer App im Metro-Stil, dass sie mit dem Status beim Beenden fortgesetzt wird. Aus der Perspektive des Entwicklers bedeutet dies, dass es oft angemessen ist, die zuvor gespeicherten Sitzungsdaten wiederherzustellen, wenn die App aus einem angehaltenen Status fortgesetzt oder aus dem nicht ausgeführten Status aktiviert wird.

Wenn Ihre App zum Beispiel über eine Warenkorb-Funktion verfügt und der Benutzer Waren in diesen gelegt hat, sollten diese Waren im Warenkorb behalten werden, wenn der Benutzer die App fortsetzt oder erneut aktiviert.

Stellen Sie sich nun eine App vor, die Nachrichtenartikel zeigt. Wenn der Benutzer einen bestimmen Artikel liest und dann zu einer anderen App wechselt, wird er erwarten, den soeben gelesenen Artikel erneut vorzufinden, wenn er zur App zurückkehrt.

Freigeben von exklusiven Resourcen im „suspending“-Ereignishandler

Wenn eine App während der Ausführung exklusive Ressourcen (wie Dateihandles oder Verweise auf externe Geräte) erhält, müssen diese Ressourcen beim Empfang eines suspending-Ereignisses freigegeben werden. Zusätzlich muss die App diese exklusiven Ressourcen erneut beanspruchen, wenn sie mit einem resuming-Ereignis fortgesetzt wird.

Schließen Sie Apps nicht!

Apps im Metro-Stil unter Windows 8 dürfen keinesfalls von der App selbst geschlossen werden oder App-UI enthalten, die es dem Benutzer ermöglicht, die App zu schließen. Das Anhalten und Beenden von Apps wird stellvertretend für den Benutzer von Windows übernommen, um Systemleistung und Akkulaufzeit zu gewährleisten. Um eine App zu schließen können Benutzer auf dem Bildschirm von oben nach unten streifen oder ALT+F4 drücken.

Zusammenfassung

Durch die Verwendung von drei Ereignissen – suspending, resuming und activated – verhält sich die App aus Sicht des Benutzers so, als würde sie dauerhaft ausgeführt. Dies verlängert zudem die Akkulaufzeit und verhindert den Abfall der Systemleistung, wenn die App nicht verwendet wird. In einer Welt mit immer flacheren, noch mobileren Geräten, sorgt der neue Lebenszyklus von Apps im Metro-Stil dafür, dass Apps auf jedem Gerät optimal ausgeführt werden.

– Adam Barrus, Programmmanager, Windows

Dieser Beitrag ist in Teamarbeit entstanden. Unser Dank gilt Jake Sabulsky, Ben Srour, Ben Betz, Marco Matos, Ryan Haveson, Ian LeGrow und John Montgomery für Ihre Beiträge.

  • Loading...
Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post