So wird’s gemacht: Festlegen von Optionen für Hintergrundkonnektivität (HTML)

Artikel
12/12/2015

[ 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]

In diesem Thema werden die Features für Hintergrund-Netzwerkkonnektivität beschrieben, die für eine in JavaScript und HTML geschriebene Windows-Runtime-App verfügbar sind, und es wird erläutert, wie die Optionen für die Hintergrundkonnektivität konfiguriert werden.

Wissenswertes

Technologien

IXMLHTTPRequest2

Ermöglicht den Zugriff auf Webressourcen mit einer Erweiterung für das XMLHttpRequest-Objekt.
System.Net.Http

Ermöglicht das Herstellen einer Verbindung mit Webdiensten über einen modernen Webclient.

Voraussetzungen

Die folgenden Informationen gelten für alle verbundenen oder netzwerkfähigen Windows-Runtime-Apps, die Netzwerkverbindungen erfordern, um dauerhaft verbunden zu sein. Dieses Thema bezieht sich auf in JavaScript und HTML geschriebene Apps für Windows 8.1, Windows Phone 8.1 und Windows Server 2012 R2. Weitere Informationen zu Hintergrundaufgaben für JavaScript-Apps finden Sie unter Unterstützen von Apps durch Hintergrundaufgaben.

Weitere Informationen zu verbundenen oder netzwerkfähigen Windows Store-Apps in C++/XAML und Apps in C#, VB.NET oder verwaltetem C++, die .NET Framework 4.5 nutzen, unter Windows 8.1 und Windows Server 2012 R2 finden Sie unter So wird's gemacht: Aufrechterhalten der Verbindung im Hintergrund.

Lebenszyklusmodell für Windows Store-Apps

Ab Windows 8 wird ein neues Lebenszyklusmodell für Windows-Runtime-Apps eingeführt. Dieses unterscheidet sich von dem Modell, das für Desktop-Apps unter Windows 8 und Apps in früheren Windows-Versionen verwendet wurde. Standardmäßig wird eine Windows-Runtime-App vollständig angehalten, wenn sie in den Hintergrund versetzt wird. In einigen Fällen werden Apps allerdings nicht angehalten (z. B. beim aktiven Drucken, Zugreifen auf einen Audiostream oder Übertragen von Daten im Hintergrund mit Windows.Networking.BackgroundTransfer). In einigen dieser Fälle (beispielsweise Windows.Networking.BackgroundTransfer) kann die App dennoch angehalten werden. Windows setzt dann die Netzwerkübertragung in einem separaten Prozess fort.

Dieses neue Modell für Windows-Runtime-Apps verbessert die Reaktionsfähigkeit der im Vordergrund ausgeführten App. Gleichzeitig verringert sich insgesamt der Energieverbrauch des Systems. Dank des geringeren Energieverbrauchs können akkubetriebene Systeme länger verwendet werden, bis sie wieder aufgeladen werden müssen. Darüber hinaus bietet das neue Modell einen Mechanismus für Apps, die im Hintergrund ausgeführt werden müssen (z. B. VoIP (Voice over IP), Chatprogramme und E-Mails). Auf diese Weise verfügen Endbenutzer über eine durchgängig verbundene Umgebung. Eine App, die auf die unterbrechungsfreie Verbindung mit einem Remoteserver angewiesen ist, kann also auch dann noch funktionieren, wenn die App angehalten wurde. Diese Anforderungen müssen gegeneinander abgewogen werden: Zum einen soll für eine Echtzeit-App eine stetige Verbindung aufrechterhalten werden, zum anderen ist es wünschenswert, den Energieverbrauch zu verringern und die Reaktionsfähigkeit der App zu verbessern.

In Windows 8 stehen mehrere neue Features zur Verfügung, die Echtzeit-Netzwerkszenarien für Windows-Runtime-Apps in JavaScript ermöglichen, die auf eine durchgängige Verbindung angewiesen sind:

Hintergrundaufgaben
Systemtrigger für SessionConnected
Zeitauslöser
Windows-Pushbenachrichtungsdienste (Windows Push Notification Services, WNS)
Unformatierte Pushbenachrichtigungen

Diese Features bieten Unterstützung für dauerhaft verbundene Apps, die unformatierte Pushbenachrichtigungen empfangen müssen, wenn eine Windows-Runtime-App angehalten wurde. Diese Apps werden auch als immer erreichbare Apps bezeichnet. Dieses Thema konzentriert sich auf die Frage, wie Entwickler WNS sowie unformatierte Pushbenachrichtigungen nutzen können, um eine Echtzeit-App zu erstellen, die kontinuierlich verbunden ist. Um diese Features zu verwenden, muss es sich um eine Sperrbildschirm-App handeln.

In einer Netzwerk-App können außerdem andere Features für Hintergrundaufgaben verwendet werden. Folgende weitere Trigger sind u. a. für Windows-Runtime-Apps verfügbar:

Wartungstrigger (regelmäßig eintretende Zeitereignisse für die Wartung)
Systemtrigger für Benutzer und Sitzungen (Benutzersitzung verbunden/getrennt, Benutzer anwesend/abwesend und Änderung der Online-ID)
Systemtrigger für den Netzwerkstatus (Änderung des Netzwerkstatus, Internet verfügbar/nicht verfügbar)
Systemtrigger für den Sperrbildschirm (App hinzufügen/entfernen)

Ein Zeitauslöser könnte verwendet werden, wenn eine App keine Echtzeitverbindung benötigt, sondern lediglich in bestimmten Abständen kurzfristig ausgeführt wird. Die Verwendung eines Systemtriggers bietet sich an, wenn die App über Ereignisse informiert sein muss (zum Beispiel die Verfügbarkeit der Internetverbindung oder die Anwesenheit von Benutzern). Verschiedene Trigger können in einer App kombiniert werden, um eine Reihe von Szenarien zu unterstützen. Weitere Informationen finden Sie unter Unterstützen von Apps durch Hintergrundaufgaben.

Bei den meisten Windows-Runtime-Apps ist es nicht nötig, die in diesem Thema beschriebenen unformatierten Pushbenachrichtigungen zu verwenden. Eine App kann Benutzern den Eindruck vermitteln, dass sie durchgängig im Hintergrund ausgeführt wird. Zu diesem Zweck wird eine Live-Kachel oder eine Live-Kachel mit Pushbenachrichtigungen (im Gegensatz zu unformatierten Pushbenachrichtigungen) von WNS verwendet. Für die Verwendung einer Live-Kachel ist es nicht nötig, dass es sich bei der App um eine Sperrbildschirm-App handelt (die später in diesem Thema beschrieben wird). Ebenso muss sie auch nicht im Hintergrund ausgeführt werden. Um eine Live-Kachel mit unformatierten Pushbenachrichtigungen verwenden zu können, muss sich Ihre App jedoch auf dem Sperrbildschirm befinden.

Anforderungen für stetige Verbindungen

Damit eine App immer verbunden und erreichbar ist, sind meist zwei Elemente erforderlich:

Ein lange ausgeführter Prozess, um sicherzustellen, dass alle eingehenden Netzwerkbenachrichtigungen empfangen werden und von der App schnell verarbeitet werden können.
Eine lange ausgeführte Netzwerkverbindung mit einem Remoteendpunkt, der Daten nach Bedarf senden und empfangen kann.

In früheren Windows-Versionen werden Apps, die den Fokus verlieren (in den Hintergrund versetzt werden), weiterhin ausgeführt. Diese Apps können im Hintergrund langfristig aktive Verbindungen aufrechterhalten, da so Daten und Keepalive-Meldungen gesendet und empfangen werden können. Bei der Ausführung von Apps im Hintergrund kann sich der damit verbundene Ressourcenverbrauch auf die Reaktionsfähigkeit anderer Apps und auf die Akkulaufzeit auswirken.

Windows-Runtime-Apps und der Sperrbildschirm

Das neue Softwaremodell von Windows 8 hält Windows-Runtime-Apps an, wenn sie in den Hintergrund verschoben werden. Wenn eine App angehalten wurde, können vom System empfangene Pakete nicht sofort an die App übermittelt werden, und eingehende Netzwerkpakete werden u. U. verworfen. Wenn die App angehalten ist, werden keine neuen Pakete gesendet. Diese Bedingungen können dazu führen, dass vorhandene Netzwerkverbindungen geschlossen werden.

Damit eine ständige Verbindung möglich ist, muss es sich bei der App um eine Sperrbildschirm-App handeln. Eine Sperrbildschirm-App ist eine spezielle App, die Benachrichtigungen auf dem Sperrbildschirm anzeigen und Code im Hintergrund ausführen kann, wenn die App nicht im Vordergrund ist. Nur Apps, die mindestens eine Hintergrundaufgabe verwenden, können Sperrbildschirm-Apps sein.

Sperrbildschirm-Apps verfügen über einige spezifische Merkmale:

Sie können unformatierte Pushbenachrichtigungen von WNS empfangen, die bei Empfang der Benachrichtigung Code ausführen können.
Sie können Code ausführen, wenn ein Zeitauslöser ausgelöst wird.
Sie können Code ausführen, wenn eine Benutzersitzung gestartet wird.

Apps, die an den Sperrbildschirm angeheftet sind und im Hintergrund laufen, können dem Benutzer Informationen präsentieren. Hierfür wird ein Signalsymbol auf dem Sperrbildschirm aktualisiert und angezeigt, sobald neue Informationen verfügbar sind. Diese Apps können auch Benachrichtigungen auf dem Bildschirm anzeigen, wenn eine Meldung empfangen wird. Wenn der Benutzer auf die Benachrichtigung tippt oder klickt, wird er aufgefordert, das Gerät zu entsperren. Nachdem das Gerät entsperrt wurde, wird die App, die mit der Benachrichtigung zusammenhängt, mit Kontextinformationen gestartet.

Sperrbildschirm-Apps weisen einige bedeutsame Einschränkungen auf. Ein Benutzer kann immer nur jeweils sieben Sperrbildschirm-Apps verwenden. Ein Benutzer kann jederzeit eine App zum Sperrbildschirm hinzufügen oder eine App entfernen.

Sperrbildschirm-Apps eignen sich hervorragend, um die Benutzer über Ereignisse zu informieren, die während ihrer Abwesenheit vom Gerät eingetreten sind. Sie sind auch nützlich, um Bildschirmbenachrichtigungen für Ereignisse anzuzeigen, für die eine sofortige Benutzeraktion nötig ist, zum Beispiel bei eingehenden Anrufen oder Sofortnachrichten oder dringenden E-Mails.

In den meisten Fällen sind Sperrbildschirm-Apps nicht erforderlich. Wenn eine App im Hintergrund angehalten wurde, kann sie Pushbenachrichtigungen (nicht unformatierte Pushbenachrichtigungen) von WNS verwenden, um eine Live-Kachel zu aktualisieren. So wird den Benutzern der Eindruck vermittelt, dass die App ausgeführt wird, aktiv ist und neue Inhalte bereitstellt. Außerdem können Apps WNS verwenden, um dem Benutzer jederzeit eine Popupbenachrichtigung einzublenden oder um die Zahl im Signal auf der App-Kachel zu aktualisieren.

Die die Anzahl der verfügbaren Plätze für Sperrbildschirm-Apps begrenzt ist, sollten Sie Ihre App so entwerfen, dass sie auch ohne die Berechtigungen für Sperrbildschirm-Apps funktioniert. Der Benutzer muss ausdrücklich zulassen, dass eine App zum Sperrbildschirm hinzugefügt wird. Ihre App sollte immer funktionieren, wenn sie im Vordergrund sichtbar ist. Die Eigenschaft als Sperrbildschirm-Apps ermöglicht es der App lediglich, einige ihrer Aufgaben auch im Hintergrund auszuführen.

Es gibt ein Feature, das es einer in JavaScript und HTML geschriebenen App ermöglicht, eingehende Netzwerkpakete zu empfangen, wenn sich die App im Hintergrund befindet.

Unformatierte Pushbenachrichtigungen, die vom System empfangen werden und bewirken, dass eine Hintergrundaufgabe in der App ausgeführt wird. Wenn Sie dieses Feature verwenden, empfängt die App die Rohdaten vom Windows-Pushbenachrichtigungsdienst (WNS). Die Inhalte dieser Daten müssen von der App verstanden werden. Die App muss sich bei WNS registrieren, um unformatierte Pushbenachrichtigungen zu erhalten.

Weiter unten werden einige Mechanismen erläutert, mit denen Echtzeitszenarios für Apps ermöglicht werden können, die sich auf dem Sperrbildschirm befinden. Jeder Mechanismus hat Vor- und Nachteile. Die Mechanismen schließen sich nicht gegenseitig aus und können in einigen Apps kombiniert werden.

Verwenden von WNS in Windows Store-Apps

WNS ist ein Cloud-Dienst, der von Microsoft für Windows 8 gehostet wird. Er kann von Windows-Runtime-Apps genutzt werden, um Benachrichtigungen zu empfangen, die Code ausführen, eine Live-Kachel aktualisieren oder eine Bildschirmbenachrichtigung auslösen können. Damit WNS verwendet werden kann, muss der lokale Computer mit dem Internet verbunden sein, sodass die Kommunikation mit dem WNS-Dienst möglich ist. Weitere Informationen finden Sie unter Übersicht über Pushbenachrichtigungen.

Eine im Vordergrund ausgeführte Windows-Runtime-App kann WNS verwenden, um Live-Kacheln zu aktualisieren, Benachrichtigungen für den Benutzer auszulösen oder Signale zu aktualisieren. Für die Verwendung von WNS muss sich die App nicht auf dem Sperrbildschirm befinden. Sie sollten erwägen, WNS in Ihrer App zu verwenden, wenn als Reaktion auf eine Pushbenachrichtigung Code ausgeführt werden soll.

Für Apps, die sich nicht auf dem Sperrbildschirm befinden müssen (also die meisten Apps), kann WNS verwendet werden, um eine Live-Kachel zu aktualisieren.

Wenn Sie die Windows-Runtime-App an den Sperrbildschirm anheften und WNS im Hintergrund verwenden, kann die App in Echtzeit unformatierte Pushbenachrichtigungen von WNS empfangen. Diese Benachrichtigungen können dann auf dem Sperrbildschirm als Signalaktualisierung oder als Benachrichtigung angezeigt werden. Wenn eine Pushbenachrichtigung an eine Sperrbildschirm-App übermittelt wird, kann die App als Reaktion auf diese Benachrichtigung Code ausführen. Die Verwendung von WNS kann energieeffizienter sein als die Verwendung von Netzwerktriggern, die unter Windows 8.1 und Windows Server 2012 R2 für Apps in C++/XAML und Apps in C#, VB.NET oder verwaltetem C++, die .NET Framework 4.5 nutzen, verfügbar sind.

WNS bietet eine Reihe von Vorteilen:

WNS ist der energieeffizienteste Mechanismus, um Echtzeitbenachrichtigungen an Sperrbildschirm-Apps zu übermitteln.
WNS vereinfacht das Entwicklermodell für Ihre App. In den meisten Szenarios müssen Entwickler keine Hintergrundaufgaben schreiben, da das Betriebssystem die Kacheln oder Popups darstellt. Wenn – in einigen wenigen Szenarios – eine App eine Hintergrundaufgabe ausführen muss, muss sie die unformatierte Pushbenachrichtigung und die auszuführende Hintergrundaufgabe registrieren.
Es ist nicht nötig, eine dauerhafte Socketverbindung zwischen der Client-App und einem Remoteserver aufrechtzuerhalten, da Windows die Verbindung mit WNS bereitstellt. Somit entfällt die zusätzliche Last, Keep-Alive-Meldungen zu senden.
Eine einzelne WNS-Verbindung zwischen dem Client und dem Clouddienst kann alle Apps auf dem lokalen Computer versorgen. Dies kann für eine verbesserte Akkulaufzeit beim Client sorgen.
Die serverseitigen Betriebskosten für den Dienst lassen sich möglicherweise reduzieren, da keine Vielzahl geparkter TCP-Socketverbindungen zwischen Client und Remotedienst aufrechterhalten werden muss.
Ihre App muss nicht dauerhaft im Speicher gehalten werden, denn auch wenn sie beendet wird, ist es möglich, dass nach Empfang einer unformatierten Pushbenachrichtigung WNS die Kachel aktualisiert, ein Popup einblendet oder die Ausführung einer Hintergrundaufgabe auslöst.
Hintergrundaufgaben, die unformatierte Pushbenachrichtigungen verwenden, können unter Windows 8.1 und Windows Server 2012 R2 in JavaScript-Apps, Apps in C++/XAML und Apps in C#, VB.NET oder verwaltetem C++, die .NET Framework 4.5 nutzen, verwendet werden.

Das von ControlChannelTrigger verwendete Netzwerktriggerfeature ist in JavaScript nicht verfügbar.

Hinweis ControlChannelTrigger wird unter Windows Phone nicht unterstützt

Hintergrundaufgaben, die Netzwerktrigger verwenden, können unter Windows 8 und Windows Server 2012 nur in Apps in C++/XAML und Apps in C#, VB.NET oder verwaltetem C++, die .NET Framework 4.5 nutzen, verwendet werden. Weitere Informationen finden Sie unter So wird's gemacht: Aufrechterhalten der Verbindung im Hintergrund.

Für WNS gelten einige Einschränkungen, die sich auf manche Apps auswirken können. WNS ist nicht auf lokalen Computern verfügbar, die mit einem Heim- oder Arbeitsnetzwerk verbunden sind, das den Zugriff auf das öffentliche Internet blockiert. Es ist auch möglich, dass WNS von einigen Netzwerkfirewalls blockiert wird, obwohl der Internetzugriff verfügbar ist. Bei der Verwendung von WNS gibt es weitere Nachteile, die berücksichtigt werden sollten. Dazu zählt vor allem, dass Benachrichtigungen nach dem Prinzip der besten Leistung übermittelt werden, und es keine Garantie für eine Übermittlung gibt. Die maximale Größe der Nutzlast in einer unformatierten Pushbenachrichtigung beträgt 5 KB.

Angesichts der Vorteile empfehlen wir Entwicklern, die VoIP-, Instant Messaging- oder E-Mail-Apps erstellen, die Verwendung von WNS-Benachrichtigungen für Sperrbildschirm-Apps in Erwägung zu ziehen. Falls diese die individuellen Anforderungen aber nicht erfüllen, sollten Alternativen in Betracht gezogen werden.

Es ist nicht nötig, eine Sperrbildschirm-App zu erstellen, wenn Sie WNS lediglich verwenden möchten, um eine Live-Kachel zu aktualisieren oder ein Popup auszulösen. Bei der Verwendung von WNS ist nur dann eine Sperrbildschirm-App erforderlich, wenn eine unformatierte Pushbenachrichtigung benötigt wird, um eine Hintergrundaufgabe auszulösen.

Verwenden von Zeitauslösern oder Systemereignisauslösern in Windows-Runtime-Apps

Sperrbildschirm-Apps können so konfiguriert werden, dass mithilfe eines Zeitauslösers Code in einem Mindestintervall von 15 Minuten ausgeführt wird. Ein Beispiel ist die Abfrage neuer E-Mail-Nachrichten. Dies könnte erfolgen, wenn die App mit einem POP3- oder IMAP-E-Mail-Server verbunden wird.

Sperrbildschirm-Apps können auch einen Systemereignisauslöser verwenden, um Code auszuführen, wenn sich der Benutzer beim lokalen Computer anmeldet (Systemtrigger für den Sitzungsstart). Ein Beispiel hierfür ist die Anmeldung des Benutzers bei einem Instant Messaging-Dienst, wenn eine Benutzersitzung gestartet wird, sodass Sofortnachrichten empfangen werden können.

Dieses Thema behandelt die Erstellung von Sperrbildschirm-Apps mit unformatierten Pushbenachrichtigungen mit WNS oder dem Netzwerktriggerfeature. Weitere Informationen finden Sie unter So wird's gemacht: Ausführen einer Hintergrundaufgabe für einen Timer. Weitere Informationen zu Hintergrundaufgaben finden Sie unter Unterstützen von Apps durch Hintergrundaufgaben.

Hintergrundaufgaben und Sandkastenprinzip

Die Lebensdauer einer Hintergrundaufgabe wird durch die Funktion bestimmt, die die Hintergrundaufgabe implementiert. Um sicherzustellen, dass sich Hintergrundaufgaben nicht nachteilig auf die Akkulaufzeit auswirken, erzwingt Windows eine Beschränkung für die CPU- und Netzwerk-E/A-Ressourcen, die eine App für Hintergrundaufgaben verwenden kann. Jede App erhält regelmäßig ein Kontingent dieser Ressourcen. Wenn dieses Kontingent erschöpft ist, wird die Hintergrundaufgabe Ihrer App angehalten. Apps müssen sich stabil verhalten, wenn sie aufgrund des Sandkastenprinzips angehalten werden.

Weitere Informationen finden Sie unter Unterstützen der App mit Hintergrundaufgaben.

Weitere Schritte

Weitere Informationen zum Erstellen von Sperrbildschirm-Apps, die Hintergrund-Netzwerkbenachrichtigungen mit unformatierten Pushbenachrichtigungen empfangen, finden Sie unter So wird's gemacht: Erstellen von Sperrbildschirm-Apps, die unformatierte Hintergrund-Pushbenachrichtigungen verwenden.

Weitere Informationen dazu, wie Sie einen Pushbenachrichtigungskanal registrieren und an den Server senden, wie Sie eine Hintergrundaufgabe registrieren, die von einer unformatierten Pushbenachrichtigung aktiviert wird, und wie Sie eine unformatierte Pushbenachrichtigung an den Kanal senden und die Hintergrundaufgabe aktivieren finden Sie unter So wird's gemacht: Verwenden von WNS zur Übermittlung unformatierter Pushbenachrichtigungen an eine Sperrbildschirm-App.

Weitere Informationen zum Schreiben von Hintergrundaufgaben, um Hintergrund-Netzwerkbenachrichtigungen zu empfangen, die unformatierte Pushbenachrichtigungen verwenden, finden Sie unter So wird's gemacht: Schreiben von Hintergrundaufgaben für unformatierte Pushbenachrichtigungen.

Weitere Informationen zu Richtlinien und Prüflisten für die Verwendung von unformatierten Pushbenachrichtigungen finden Sie unter Richtlinien und Prüfliste für unformatierte Benachrichtigungen.