TileUpdater.StartPeriodicUpdateBatch Methode
Definition
Wichtig
Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.
Überlädt
| StartPeriodicUpdateBatch(IIterable<Uri>, PeriodicUpdateRecurrence) |
Startet eine Reihe von zeitlimitierten Updates, die auf der Kachel ausgeführt werden, an die der Updater gebunden ist. Der Updateinhalt wird aus einem Array des angegebenen URI (Uniform Resource Identifier) abgerufen. Das erste Update erfolgt sofort, und nachfolgende Updates erfolgen im regelmäßigen Intervall danach. Hinweis Um dieses Feature verwenden zu können, müssen Sie zuerst die Benachrichtigungswarteschlange der Kachel aktivieren, indem Sie EnableNotificationQueue aufrufen. |
| StartPeriodicUpdateBatch(IIterable<Uri>, DateTime, PeriodicUpdateRecurrence) |
Startet eine Reihe von zeitlimitierten Updates, die auf der Kachel ausgeführt werden, an die der Updater gebunden ist. Aktualisierungsinhalte werden aus einem Array des angegebenen URI (Uniform Resource Identifier) abgerufen, wobei Updates zu einem bestimmten Zeitpunkt beginnen und nachfolgende Updates im periodischen Intervall danach erfolgen. Hinweis Um dieses Feature verwenden zu können, müssen Sie zuerst die Benachrichtigungswarteschlange der Kachel aktivieren, indem Sie EnableNotificationQueue aufrufen. |
StartPeriodicUpdateBatch(IIterable<Uri>, PeriodicUpdateRecurrence)
Startet eine Reihe von zeitlimitierten Updates, die auf der Kachel ausgeführt werden, an die der Updater gebunden ist. Der Updateinhalt wird aus einem Array des angegebenen URI (Uniform Resource Identifier) abgerufen. Das erste Update erfolgt sofort, und nachfolgende Updates erfolgen im regelmäßigen Intervall danach.
Hinweis
Um dieses Feature verwenden zu können, müssen Sie zuerst die Benachrichtigungswarteschlange der Kachel aktivieren, indem Sie EnableNotificationQueue aufrufen.
public:
virtual void StartPeriodicUpdateBatch(IIterable<Uri ^> ^ tileContents, PeriodicUpdateRecurrence requestedInterval) = StartPeriodicUpdateBatch;/// [Windows.Foundation.Metadata.Overload("StartPeriodicUpdateBatch")]
void StartPeriodicUpdateBatch(IIterable<Uri> const& tileContents, PeriodicUpdateRecurrence const& requestedInterval);[Windows.Foundation.Metadata.Overload("StartPeriodicUpdateBatch")]
public void StartPeriodicUpdateBatch(IEnumerable<System.Uri> tileContents, PeriodicUpdateRecurrence requestedInterval);function startPeriodicUpdateBatch(tileContents, requestedInterval)Public Sub StartPeriodicUpdateBatch (tileContents As IEnumerable(Of Uri), requestedInterval As PeriodicUpdateRecurrence)Parameter
- tileContents
Ein Array von bis zu fünf URI (Uniform Resource Identifier), aus dem der XML-Inhalt der Zyklenkachelaktualisierungen abgerufen wird. Wenn das Array mehr als fünf URI (Uniform Resource Identifier) enthält, schlägt die Methode fehl.
- requestedInterval
- PeriodicUpdateRecurrence
Die Häufigkeit, mit der der URI (Uniform Resource Identifier) nach neuen Kachelinhalten abgefragt wird, nach der ersten Aktualisierung um startTime.
- Attribute
Hinweise
Verwenden der Benachrichtigungswarteschlange mit regelmäßigen Updates
Um die Benachrichtigungswarteschlange verwenden zu können, müssen Sie sie zuerst für Ihre Kachel mit dieser Codezeile aktivieren:
Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().enableNotificationQueue(true);
Diese API muss nur einmal in der Lebensdauer Ihrer App aufgerufen werden, aber es ist kein Schaden, wenn sie jedes Mal aufgerufen wird, wenn die App gestartet wird.
Bei regelmäßigen Benachrichtigungen wird für jede Benachrichtigung eine eindeutige URL bereitgestellt. Jede URL wird regelmäßig von Windows für aktualisierte Benachrichtigungsinhalte abgefragt. Die von jeder URL zurückgegebene Inhaltsnutzlast sollte Versionen der Benachrichtigungs-XML für alle unterstützten Kachelgrößen enthalten. Jede abgefragte URL kann optional auch ihren eigenen eindeutigen Ablaufzeit- und Tagwert zurückgeben.
Markieren von Benachrichtigungen für regelmäßige Updates
Wenn die Benachrichtigungswarteschlange aktiviert ist, kann Ihre Kachel maximal fünf Benachrichtigungen in der Warteschlange durchlaufen. Im Allgemeinen wird die älteste Benachrichtigung in der Warteschlange ersetzt, wenn eine neue Benachrichtigung eintrifft. Benachrichtigungen können jedoch mit einem Tag versehen werden, sodass eine neue Benachrichtigung mit einem bestimmten Tag eine ältere Benachrichtigung durch dasselbe Tag ersetzt, unabhängig von ihrem Platz in der Warteschlange.
Tags sind optionale Zeichenfolgen mit bis zu 16 Zeichen, die für eine Benachrichtigung als Bezeichner festgelegt werden können. Wenn eine neue Benachrichtigung mit demselben Tag wie eine bereits in der Warteschlange enthaltene Benachrichtigung eingeht, ersetzt die neue Benachrichtigung die alte Benachrichtigung, anstatt unter das standardmäßige Verhalten der First-In-Warteschlange zu fallen. Dadurch wird verhindert, dass zwei Versionen derselben Benachrichtigung – eine davon veraltet – gleichzeitig in der Warteschlange vorhanden sind.
Bei regelmäßigen Benachrichtigungen werden Tags im X-WNS-Tag-Header der HTTP-Antwortnachricht der Benachrichtigung bereitgestellt, die auch den Inhalt der Benachrichtigung enthält. Diese Nachricht wird als Reaktion auf den regelmäßigen Aufruf des Systems an den URI (Uniform Resource Identifier) der Benachrichtigung gesendet. Beim Headernamen und dem Tagwert wird die Groß-/Kleinschreibung nicht beachtet.
Das folgende Beispiel soll dies erläutern:
X-WNS-Tag: stockMSFT
Festlegen einer Ablaufzeit für regelmäßige Updates
Regelmäßige Benachrichtigungen laufen standardmäßig nach drei Tagen ab. Wenn Ihre Benachrichtigungsinhalte eine erheblich andere nützliche Lebensdauer haben – kürzer oder länger –, sollten Sie explizit eine Ablaufzeit für jede Benachrichtigung festlegen. Dadurch wird verhindert, dass veraltete oder irrelevante Inhalte in der Warteschlange verbleiben. Dies ist besonders wichtig, wenn der Computer des Benutzers für einen längeren Zeitraum die Internetverbindung verliert.
Während des aktiven Handels wäre es beispielsweise ratsam, dass eine Aktien-App den Ablauf einer Aktienkursbenachrichtigung auf das Doppelte Ihres Abrufintervalls festlegen sollte, z. B. eine Benachrichtigung, die eine Stunde nach dem Senden abläuft, wenn Sie alle halbe Stunde ein Update abfragen. Bei einer Nachrichten-App wäre ein Ablauf von einem Tag für eine Kachel, die die wichtigsten täglichen Nachrichten anzeigt, angemessen.
Bei regelmäßigen Benachrichtigungen wird die Ablaufzeit im X-WNS-Expires-Header der HTTP-Antwortnachricht der Benachrichtigung festgelegt. Die Ablaufzeit wird als HTTP-Datum ausgedrückt, das eines der in den folgenden Beispielen gezeigten Formate verwendet:
- So, 06 Nov 1994 08:49:37 GMT
- Sonntag, 06-Nov-94 08:49:37 GMT
- So Nov 6 08:49:37 1994
Weitere Informationen zum HTTP-Datumsformat finden Sie im Dokument World Wide Web Consortium (W3C) 3 Protocol Parameters .
Ein Beispiel für eine vollständige Implementierung regelmäßiger Benachrichtigungen, die in Verbindung mit der Benachrichtigungswarteschlange verwendet werden, finden Sie unter Szenario 3 im Beispiel für Push- und regelmäßige Benachrichtigungen (archiviert).
Weitere Informationen
- StartPeriodicUpdateBatch(IIterable<Uri>, DateTime, PeriodicUpdateRecurrence)
- StartPeriodicUpdate(Uri, DateTime, PeriodicUpdateRecurrence)
- So wird's gemacht: Einrichten regelmäßiger Benachrichtigungen für Kacheln
- Richtlinien und Prüfliste für regelmäßige Benachrichtigungen
- Übersicht über Kachel- und Kachelbenachrichtigungen
Gilt für:
StartPeriodicUpdateBatch(IIterable<Uri>, DateTime, PeriodicUpdateRecurrence)
Beginnt eine Reihe von zeitgebundenen Updates, die auf der Kachel, an die der Updater gebunden ist, ausgeführt werden. Aktualisierungsinhalte werden aus einem Array des angegebenen URI (Uniform Resource Identifier) abgerufen, wobei Updates zu einem bestimmten Zeitpunkt beginnen und nachfolgende Updates im periodischen Intervall danach auftreten.
Hinweis
Um dieses Feature verwenden zu können, müssen Sie zuerst die Benachrichtigungswarteschlange der Kachel aktivieren, indem Sie EnableNotificationQueue aufrufen.
public:
virtual void StartPeriodicUpdateBatch(IIterable<Uri ^> ^ tileContents, DateTime startTime, PeriodicUpdateRecurrence requestedInterval) = StartPeriodicUpdateBatch;/// [Windows.Foundation.Metadata.Overload("StartPeriodicUpdateBatchAtTime")]
void StartPeriodicUpdateBatch(IIterable<Uri> const& tileContents, DateTime const& startTime, PeriodicUpdateRecurrence const& requestedInterval);[Windows.Foundation.Metadata.Overload("StartPeriodicUpdateBatchAtTime")]
public void StartPeriodicUpdateBatch(IEnumerable<System.Uri> tileContents, System.DateTimeOffset startTime, PeriodicUpdateRecurrence requestedInterval);function startPeriodicUpdateBatch(tileContents, startTime, requestedInterval)Public Sub StartPeriodicUpdateBatch (tileContents As IEnumerable(Of Uri), startTime As DateTimeOffset, requestedInterval As PeriodicUpdateRecurrence)Parameter
- tileContents
Ein Array von bis zu fünf URI (Uniform Resource Identifier), aus dem der XML-Inhalt der Zyklenkachelaktualisierungen abgerufen wird. Wenn das Array mehr als fünf URI (Uniform Resource Identifier) enthält, schlägt die Methode fehl.
- startTime
- DateTime DateTimeOffset
Der Zeitpunkt, zu dem der anfängliche URI (Uniform Resource Identifier) zuerst nach neuen Inhalten abgefragt werden soll.
- requestedInterval
- PeriodicUpdateRecurrence
Die Häufigkeit, mit der der URI (Uniform Resource Identifier) nach neuen Kachelinhalten abgefragt wird, nach der ersten Aktualisierung um startTime.
- Attribute
Hinweise
Verwenden der Benachrichtigungswarteschlange mit regelmäßigen Updates
Um die Benachrichtigungswarteschlange verwenden zu können, müssen Sie sie zuerst für Ihre Kachel mit dieser Codezeile aktivieren:
Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().enableNotificationQueue(true);
Diese API muss nur einmal in der Lebensdauer Ihrer App aufgerufen werden, aber es ist kein Schaden, wenn sie jedes Mal aufgerufen wird, wenn die App gestartet wird.
Bei regelmäßigen Benachrichtigungen wird für jede Benachrichtigung eine eindeutige URL bereitgestellt. Jede URL wird regelmäßig von Windows für aktualisierte Benachrichtigungsinhalte abgefragt. Die von jeder URL zurückgegebene Inhaltsnutzlast sollte Versionen der Benachrichtigungs-XML für alle unterstützten Kachelgrößen enthalten. Jede abgefragte URL kann optional auch ihren eigenen eindeutigen Ablaufzeit- und Tagwert zurückgeben.
Markieren von Benachrichtigungen für regelmäßige Updates
Wenn die Benachrichtigungswarteschlange aktiviert ist, kann Ihre Kachel maximal fünf Benachrichtigungen in der Warteschlange durchlaufen. Im Allgemeinen wird die älteste Benachrichtigung in der Warteschlange ersetzt, wenn eine neue Benachrichtigung eintrifft. Benachrichtigungen können jedoch mit einem Tag versehen werden, sodass eine neue Benachrichtigung mit einem bestimmten Tag eine ältere Benachrichtigung durch dasselbe Tag ersetzt, unabhängig von ihrem Platz in der Warteschlange.
Tags sind optionale Zeichenfolgen mit bis zu 16 Zeichen, die für eine Benachrichtigung als Bezeichner festgelegt werden können. Wenn eine neue Benachrichtigung mit demselben Tag wie eine bereits in der Warteschlange enthaltene Benachrichtigung eingeht, ersetzt die neue Benachrichtigung die alte Benachrichtigung, anstatt unter das standardmäßige Verhalten der First-In-Warteschlange zu fallen. Dadurch wird verhindert, dass zwei Versionen derselben Benachrichtigung – eine davon veraltet – gleichzeitig in der Warteschlange vorhanden sind.
Bei regelmäßigen Benachrichtigungen werden Tags im X-WNS-Tag-Header der HTTP-Antwortnachricht der Benachrichtigung bereitgestellt, die auch den Inhalt der Benachrichtigung enthält. Diese Nachricht wird als Reaktion auf den regelmäßigen Aufruf des Systems an den URI (Uniform Resource Identifier) der Benachrichtigung gesendet. Beim Headernamen und dem Tagwert wird die Groß-/Kleinschreibung nicht beachtet.
Das folgende Beispiel soll dies erläutern:
X-WNS-Tag: stockMSFT
Festlegen einer Ablaufzeit für regelmäßige Updates
Kacheln laufen standardmäßig nach drei Tagen ab. Wenn Ihre Benachrichtigungsinhalte eine erheblich andere nützliche Lebensdauer haben – kürzer oder länger –, sollten Sie explizit eine Ablaufzeit für jede Benachrichtigung festlegen. Dadurch wird verhindert, dass veraltete oder irrelevante Inhalte in der Warteschlange verbleiben. Dies ist besonders wichtig, wenn der Computer des Benutzers für einen längeren Zeitraum die Internetverbindung verliert.
Während des aktiven Handels wäre es beispielsweise ratsam, dass eine Aktien-App den Ablauf einer Aktienkursbenachrichtigung auf das Doppelte Ihres Abrufintervalls festlegen sollte, z. B. eine Benachrichtigung, die eine Stunde nach dem Senden abläuft, wenn Sie alle halbe Stunde ein Update abfragen. Bei einer Nachrichten-App wäre ein Ablauf von einem Tag für eine Kachel, die die wichtigsten täglichen Nachrichten anzeigt, angemessen.
Bei regelmäßigen Benachrichtigungen wird die Ablaufzeit im X-WNS-Expires-Header der HTTP-Antwortnachricht der Benachrichtigung festgelegt. Die Ablaufzeit wird als HTTP-Datum ausgedrückt, das eines der in den folgenden Beispielen gezeigten Formate verwendet:
- So, 06 Nov 1994 08:49:37 GMT
- Sonntag, 06-Nov-94 08:49:37 GMT
- So Nov 6 08:49:37 1994
Weitere Informationen zum HTTP-Datumsformat finden Sie im Dokument World Wide Web Consortium (W3C) 3 Protocol Parameters .
Ein Beispiel für eine vollständige Implementierung regelmäßiger Benachrichtigungen, die in Verbindung mit der Benachrichtigungswarteschlange verwendet werden, finden Sie unter Szenario 3 im Beispiel für Push- und regelmäßige Benachrichtigungen (archiviert).
Weitere Informationen
- StartPeriodicUpdateBatch(IIterable<Uri>, PeriodicUpdateRecurrence)
- StartPeriodicUpdate(Uri, DateTime, PeriodicUpdateRecurrence)
- So wird's gemacht: Einrichten regelmäßiger Benachrichtigungen für Kacheln
- Richtlinien und Prüfliste für regelmäßige Benachrichtigungen
- Übersicht über Kachel- und Kachelbenachrichtigungen
Gilt für:
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für