Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Regelmäßige Benachrichtigungen, die auch als abgerufene Benachrichtigungen bezeichnet werden, aktualisieren Kacheln und Abzeichen in regelmäßigen Abständen, indem Inhalte von einem Clouddienst heruntergeladen werden. Um regelmäßige Benachrichtigungen zu verwenden, muss Ihr Client-App-Code zwei Informationen bereitstellen:
- Der URI (Uniform Resource Identifier) einer Webadresse 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 Erfahren Sie mehr, indem Sie das Beispiel "Push- und regelmäßige Benachrichtigungen" für Windows 8.1 herunterladen und seinen Quellcode in Ihrer Windows 10-App wiederverwenden.
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 Badge-Inhalt (als XML) herunter, der auf die Anforderung hin bereitgestellt wird, und zeigt den Inhalt auf der Kachel der App an.
Beachten Sie, dass periodische Updates nicht mit Toast-Benachrichtigungen verwendet werden können. Toastnachrichten werden am besten über geplante oder Push-Benachrichtigungen ü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 Tile- oder Badge- XML-Schemaspezifikation entsprechen und UTF-8-codiert sein. Sie können definierte HTTP-Header verwenden, um das Ablaufdatum oder das Tag für die Benachrichtigung anzugeben.
Abfrageverhalten
Rufen Sie eine der folgenden Methoden auf, um mit der Abfrage zu beginnen:
- StartPeriodicUpdate (Kachel)
- StartPeriodicUpdate (Badge)
- StartPeriodicUpdateBatch (Kachel)
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 Ihre Kachel oder Ihr Abzeichen ab, auch wenn Ihre App nie wieder gestartet wird.
Das Wiederholungsintervall
Sie geben das Wiederholungsintervall als Parameter für die oben aufgeführten Methoden an. Beachten Sie, dass Windows sein Bestes tut, um die Abfrage wie angefordert durchzuführen, auch wenn das Intervall nicht präzise ist. 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 einer solchen Situation empfehlen wir, dass Sie die Umfrage zeitnah mit der Aktualisierung Ihres Clouddienstes durchführen. Wenn z. B. eine tägliche Einkaufsseite die Angebote des Tages um 8 Uhr veröffentlicht, fordern Sie kurz nach 8:00 Uhr neue Inhalte für Kachel ab.
Wenn Sie eine Startzeit angeben, fragt der erste Aufruf der Methode sofort Inhalte ab. Anschließend beginnt die regelmäßige Abfrage innerhalb von 15 Minuten nach der angegebenen Startzeit.
Automatisches Wiederholungsverhalten
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. Befindet sich das Gerät im Zustand "Aus", "Standby-Modus" oder "Ruhezustand" zum Zeitpunkt, an dem ein Abrufintervall auftritt, wird der URI abgefragt, wenn das Gerät aus dem Aus- oder Standby-Modus zurückkehrt.
Verwaltung von App-Updates
Wenn Sie ein App-Update freigeben, das Ihren Abfrage-URI ändert, sollten Sie eine tägliche zeitgesteuerte Hintergrundaufgabe hinzufügen, die StartPeriodicUpdate mit dem neuen URI aufruft, damit Ihre Kacheln den neuen URI verwenden. Andernfalls, 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 gelöscht wurden.
Verfall von Kachel- und Badge-Benachrichtigungen
Standardmäßig verfallen regelmäßige Kachel- und Signalbenachrichtigungen drei Tage nach ihrem Herunterladen. Wenn eine Benachrichtigung abgelaufen ist, wird der Inhalt aus dem Abzeichen, der Kachel oder der Warteschlange entfernt und nicht mehr dem Benutzer angezeigt. Es empfiehlt sich, eine explizite Ablaufzeit für alle regelmäßigen Kachel- und Signalbenachrichtigungen unter Verwendung eines Zeitpunktes, der für Ihre App oder Benachrichtigung sinnvoll ist, festzulegen, damit der Inhalt nicht länger vorliegt, als er relevant ist. 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 sowie eine Uhrzeit für eine Benachrichtigung fest, indem der X-WNS-Expires-HTTP-Header in die Antwortnutzlast aufgenommen wird. Der HTTP-Header X-WNS-Expires entspricht dem HTTP-Datumformat . Weitere Informationen finden Sie unter StartPeriodicUpdate oder StartPeriodicUpdateBatch.
Zum Beispiel können Sie während eines aktiven Börsenhandelstages den Ablauf für eine Aktienkursaktualisierung auf das Doppelte Ihres Abfrageintervalls festlegen, z. B. eine Stunde nach Erhalt, wenn Sie alle halbe Stunde abfragen. Als weiteres Beispiel kann eine Nachrichten-App feststellen, dass ein Tag eine geeignete Ablaufzeit für die tägliche Aktualisierung eines Nachrichtenelements 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 wechselt zwischen ihnen.
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 das Festlegen von Tags für Ihre Benachrichtigungen können Sie jedoch die Austauschrichtlinie der Warteschlange beeinflussen. Bei einem Tag handelt es sich um eine appspezifische, unabhängig von der Groß-/Kleinschreibung gültige Zeichenfolge von bis zu 16 alphanumerischen Zeichen, die im X-WNS-Tag HTTP-Header in der Antwortnutzlast angegeben ist. 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 mit demselben 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 dazu finden Sie unter Verwenden der Benachrichtigungswarteschlange.
Aktivieren der Benachrichtigungswarteschlange
Um eine Benachrichtigungswarteschlange zu implementieren, aktivieren Sie zuerst die Warteschlange für Ihre Kachel (siehe Wie die Benachrichtigungswarteschlange mit lokalen Benachrichtigungen genutzt wird). Der Aufruf zum Aktivieren der Warteschlange muss nur einmal während der Lebensdauer Ihrer App ausgeführt werden, aber es gibt kein Problem, wenn Sie ihn jedes Mal aufrufen, wenn Ihre App gestartet wird.
Gleichzeitiges Abfragen 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 annähernd zur selben Zeit für eine einzelne Benachrichtigungsnutzlast abgefragt. Jeder abgefragte URI kann einen eigenen Ablauf- und Tagwert zurückgeben.
Zugehörige Themen
Windows developer