Freigeben über


Übersicht über regelmäßige Benachrichtigungen

Regelmäßige Benachrichtigungen – auch als abgerufene Benachrichtigungen bezeichnet – aktualisieren Kacheln und Signale in festgelegten Intervallen, indem sie Inhalte aus einem Clouddienst herunterladen. Um regelmäßige Benachrichtigungen zu verwenden, muss Ihr Client-App-Code zwei Informationen bereitstellen:

  • Der URI (Uniform Resource Identifier) eines Webspeicherorts für Windows zum Abrufen von Kachel- oder Signalupdates für Ihre App
  • Wie oft dieser URI abgefragt werden soll

Regelmäßige Benachrichtigungen ermöglichen Ihrer App das Abrufen von Live-Kachelupdates mit minimaler Investition in Clouddienst und Client. Regelmäßige Benachrichtigungen sind eine gute Übermittlungsmethode für die Verteilung desselben Inhalts an ein breites Publikum.

Hinweis : Weitere Informationen erhalten Sie, indem Sie das Beispiel für Push- und regelmäßige Benachrichtigungen für Windows 8.1 herunterladen und den Quellcode in Ihrer Windows 10-App erneut verwenden.

 

Funktionsweise

Regelmäßige Benachrichtigungen erfordern, dass Ihre App einen Clouddienst hosten muss. Der Dienst wird regelmäßig von allen Benutzern abgefragt, die die App installiert haben. Bei jedem Abrufintervall, z. B. einmal pro Stunde, sendet Windows eine HTTP GET-Anforderung an den URI, lädt die angeforderte Kachel oder den angeforderten Signalinhalt (als XML) herunter, der als Reaktion auf die Anforderung bereitgestellt wird, und zeigt den Inhalt auf der Kachel der App an.

Beachten Sie, dass regelmäßige Updates nicht mit Popupbenachrichtigungen verwendet werden können. Popups werden am besten über geplante oder Pushbenachrichtigungen übermittelt.

URI-Speicherort und XML-Inhalt

Jede gültige HTTP- oder HTTPS-Webadresse kann als URI verwendet werden, um abgefragt zu werden.

Die Antwort des Cloudservers enthält die heruntergeladenen Inhalte. Der vom URI zurückgegebene Inhalt muss der Xml-Schemaspezifikation für Kacheln oder Signale entsprechen und UTF-8-codiert sein. Sie können definierte HTTP-Header verwenden, um die Ablaufzeit oder das Tag für die Benachrichtigung anzugeben.

Abrufverhalten

Rufen Sie eine der folgenden Methoden auf, um mit der Abfrage zu beginnen:

Wenn Sie eine dieser Methoden aufrufen, wird der URI sofort abgefragt, und die Kachel oder das Signal wird mit dem empfangenen Inhalt aktualisiert. Nach dieser anfänglichen Abfrage stellt Windows weiterhin Updates im angeforderten Intervall bereit. Die Abfrage wird fortgesetzt, bis Sie sie explizit beenden (mit TileUpdater.StopPeriodicUpdate), Ihre App deinstalliert wird oder im Falle einer sekundären Kachel die Kachel entfernt wird. Andernfalls fragt Windows weiterhin Updates für die Kachel oder das Signal ab, auch wenn Ihre App nie wieder gestartet wird.

Das Serienintervall

Sie geben das Serienintervall als Parameter der oben aufgeführten Methoden an. Beachten Sie, dass das Intervall nicht präzise ist, während Windows die Abfrage wie angefordert durchführen kann. Das angeforderte Abrufintervall kann nach Ermessen von Windows um bis zu 15 Minuten verzögert werden.

Die Startzeit

Optional können Sie eine bestimmte Tageszeit angeben, um mit der Abfrage zu beginnen. Betrachten Sie eine App, die den Kachelinhalt nur einmal täglich ändert. In einem solchen Fall wird empfohlen, dass Sie den Zeitpunkt, zu dem Sie Ihren Clouddienst aktualisieren, in der Nähe abfragt. Wenn z. B. eine tägliche Shopping-Website die Angebote des Tages um 8 Uhr veröffentlicht, fordern Sie kurz nach 8:00 Uhr neue Kachelinhalte ab.

Wenn Sie eine Startzeit angeben, ruft der erste Aufruf der Methode sofort inhalte ab. Anschließend beginnt die regelmäßige Abfrage innerhalb von 15 Minuten nach der angegebenen Startzeit.

Verhalten der automatischen Wiederholung

Der URI wird nur abgefragt, wenn das Gerät online ist. Wenn das Netzwerk verfügbar ist, aber der URI aus irgendeinem Grund nicht kontaktiert werden kann, wird diese Iteration des Abrufintervalls übersprungen, und der URI wird erneut im nächsten Intervall abgefragt. Wenn sich das Gerät im Zustand "Aus", "Ruhezustand" oder "Ruhezustand" befindet, wenn ein Abrufintervall erreicht wird, wird der URI abgefragt, wenn das Gerät aus dem Aus- oder Ruhezustand zurückkehrt.

Behandeln von App-Updates

Wenn Sie ein App-Update freigeben, das Ihren Abruf-URI ändert, sollten Sie eine tägliche Zeitauslöser-Hintergrundaufgabe hinzufügen, die StartPeriodicUpdate mit dem neuen URI aufruft, um sicherzustellen, dass Ihre Kacheln den neuen URI verwenden. Wenn Benutzer Ihr App-Update erhalten, ihre App jedoch nicht starten, verwenden ihre Kacheln weiterhin den alten URI, der möglicherweise nicht angezeigt werden kann, wenn der URI jetzt ungültig ist oder wenn die zurückgegebene Nutzlast auf lokale Bilder verweist, die nicht mehr vorhanden sind.

Ablauf von Kachel- und Signalbenachrichtigungen

Standardmäßig laufen regelmäßige Kachel- und Signalbenachrichtigungen drei Tage ab dem Zeitpunkt des Downloads ab. Wenn eine Benachrichtigung abläuft, wird der Inhalt aus dem Signal, der Kachel oder der Warteschlange entfernt und dem Benutzer nicht mehr angezeigt. Es empfiehlt sich, eine explizite Ablaufzeit für alle regelmäßigen Kachel- und Signalbenachrichtigungen unter Verwendung einer Für Ihre App oder Benachrichtigung sinnvollen Zeitpunkt festzulegen, um sicherzustellen, dass der Inhalt nicht länger als relevant bleibt. Eine explizite Ablaufzeit ist für Inhalte mit definierter Lebensdauer unerlässlich. Außerdem wird sichergestellt, dass veraltete Inhalte entfernt werden, wenn Ihr Clouddienst nicht erreichbar ist oder wenn der Benutzer eine Verbindung zum Netzwerk für einen längeren Zeitraum trennt.

Ihr Clouddienst legt ein Ablaufdatum und eine Uhrzeit für eine Benachrichtigung fest, indem der X-WNS-Expires-HTTP-Header in die Antwortnutzlast eingeschlossen wird. Der X-WNS-Expires-HTTP-Header entspricht dem HTTP-Datumsformat. Weitere Informationen finden Sie unter "StartPeriodicUpdate" oder "StartPeriodicUpdateBatch".

So können Sie z. B. während des aktiven Börsenhandelstages den Ablauf für eine Aktienkursaktualisierung auf doppelt so hoch festlegen wie das Ihres Abrufintervalls (z. B. eine Stunde nach Erhalt, wenn Sie alle halbe Stunde abfragen). Ein weiteres Beispiel: Für eine Nachrichten-App könnte festgelegt werden, dass ein Tag eine geeignete Ablaufzeit für ein tägliches Update auf der Nachrichtenkachel ist.

Regelmäßige Benachrichtigungen in der Benachrichtigungswarteschlange

Sie können regelmäßige Kachelaktualisierungen mit Benachrichtigungszyklen verwenden. Standardmäßig zeigt eine Kachel auf dem Startbildschirm den Inhalt einer einzelnen Benachrichtigung an, bis sie durch eine neue Benachrichtigung ersetzt wird. Wenn Sie das Durchlaufen aktivieren, werden bis zu fünf Benachrichtigungen in einer Warteschlange verwaltet, und die Kachel wird durchlaufen.

Wenn die Warteschlange ihre Kapazität von fünf Benachrichtigungen erreicht hat, ersetzt die nächste neue Benachrichtigung die älteste Benachrichtigung in der Warteschlange. Durch Festlegen von Tags für Ihre Benachrichtigungen können Sie sich jedoch auf die Ersatzrichtlinie der Warteschlange auswirken. Bei einem Tag handelt es sich um eine appspezifische Zeichenfolge ohne Groß-/Kleinschreibung von bis zu 16 alphanumerischen Zeichen, die im X-WNS-Tag-HTTP-Header in der Antwortnutzlast angegeben sind. Windows vergleicht das Tag einer eingehenden Benachrichtigung mit den Tags aller Benachrichtigungen, die sich bereits in der Warteschlange befinden. Wenn eine Übereinstimmung gefunden wird, ersetzt die neue Benachrichtigung die Benachrichtigung in der Warteschlange durch dasselbe Tag. Wenn keine Übereinstimmung gefunden wird, wird die Standardersetzungsregel angewendet, und die neue Benachrichtigung ersetzt die älteste Benachrichtigung in der Warteschlange.

Sie können Benachrichtigungswarteschlangen und Tagging verwenden, um eine Vielzahl von umfangreichen Benachrichtigungsszenarien zu implementieren. Beispielsweise könnte eine Aktien-App fünf Benachrichtigungen senden, die jeweils über eine andere Aktie und jeweils mit einem Aktiennamen gekennzeichnet sind. Dadurch wird verhindert, dass die Warteschlange jemals zwei Benachrichtigungen für die gleiche Aktie enthält, deren älter veraltet ist.

Weitere Informationen finden Sie unter Verwenden der Benachrichtigungswarteschlange.

Aktivieren der Benachrichtigungswarteschlange

Um eine Benachrichtigungswarteschlange zu implementieren, aktivieren Sie zuerst die Warteschlange für Ihre Kachel (siehe Verwenden der Benachrichtigungswarteschlange mit lokalen Benachrichtigungen). Der Aufruf zum Aktivieren der Warteschleife muss nur einmal während der Lebensdauer Ihrer App ausgeführt werden, aber es gibt keinen Schaden beim Aufrufen jedes Mal, wenn Ihre App gestartet wird.

Gleichzeitiges Abrufen mehrerer Benachrichtigungen

Sie müssen einen eindeutigen URI für jede Benachrichtigung angeben, die Windows für Ihre Kachel herunterladen soll. Mithilfe der StartPeriodicUpdateBatch-Methode können Sie bis zu fünf URIs gleichzeitig für die Verwendung mit der Benachrichtigungswarteschlange bereitstellen. Jeder URI wird für eine einzelne Benachrichtigungsnutzlast gleichzeitig oder in der Nähe abgefragt. Jeder abgefragte URI kann einen eigenen Ablauf- und Tagwert zurückgeben.