Registrierungsverwaltung

In diesem Thema wird erläutert, wie Sie Geräte für Benachrichtigungshubs registrieren, um Pushbenachrichtigungen zu empfangen. Im Thema werden Registrierungen auf hoher Ebene beschrieben, anschließend werden die beiden Hauptmuster für die Registrierung von Geräten eingeführt: Die Registrierung vom Gerät direkt auf dem Benachrichtigungshub und die Registrierung über das Anwendungs-Back-End.

Was ist eine Geräteregistrierung

Eine Registrierung ist eine Unterentität eines Benachrichtigungshubs und ordnet ein Geräte-PNS-Handle (ein Plattformbenachrichtigungsdienst-Handle, z. B. ChannelURI, Gerätetoken, GCM registrationId) mit Tags und möglicherweise einer Vorlage zu. Tags werden verwendet, um Benachrichtigungen an die richtige Gruppe von Gerätehandles weiterzuleiten. Weitere Informationen finden Sie unter Weiterleitung und Tagausdrücke. Vorlagen werden verwendet, um Transformationen pro Registrierung zu implementieren. Weitere Informationen finden Sie unter Vorlagen.

Es ist wichtig zu beachten, dass Registrierungen vorübergehend sind. Ähnlich wie bei den PNS-Handlen, die sie enthalten, laufen Registrierungen ab. Sie können die Zeit für eine Registrierung im Benachrichtigungshub bis zu maximal 90 Tage festlegen. Dieser Grenzwert bedeutet, dass sie regelmäßig aktualisiert werden müssen und dass sie nicht der einzige Speicher für wichtige Informationen sein sollten. Durch diesen automatischen Ablauf wird auch die Bereinigung vereinfacht, wenn Ihre mobile Anwendung deinstalliert wird.

Registrierungen müssen das neueste PNS-Handle für jedes Gerät/Kanal enthalten. Da PNS-Handle nur in der Client-App auf dem Gerät abgerufen werden können, befindet sich eine Möglichkeit zum Verwalten von Registrierungen direkt in dieser Client-App. Auf der anderen Seite müssen Sicherheitsaspekte und Geschäftslogik im Zusammenhang mit Tags möglicherweise die Registrierung im Back-End der App verwalten. Im folgenden Abschnitt werden diese beiden Ansätze beschrieben.

Registrierungsverwaltung vom Gerät

Beim Verwalten von Registrierungen aus Client-Apps ist das Back-End nur für das Senden von Benachrichtigungen verantwortlich. Client-Apps halten die PNS-Handle auf dem neuesten Stand, und registrieren Sie sich bei Tags. Dieses Muster wird in der folgenden Abbildung veranschaulicht.

Registration Management

Zuerst ruft das Gerät das PNS-Handle aus dem PNS ab und registriert sich dann direkt beim Notification Hub. Wenn die Registrierung erfolgreich verläuft, kann das App-Back-End eine zielgerichtete Benachrichtigung an diese Registrierung senden. Weitere Informationen zum Senden von Benachrichtigungen finden Sie unter Weiterleitung und Tagausdrücke.

Beachten Sie, dass Sie in diesem Fall nur Lauschrechte verwenden, um über das Gerät auf die Notification Hubs zuzugreifen. Weitere Informationen finden Sie unter Sicherheit.

Der folgende Code registriert Ihr Gerät mithilfe von Benachrichtigungshubs-API-Verweisen:

await hub.RegisterNativeAsync(channelUri, tags);
[hub registerNativeWithDeviceToken:deviceToken tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.register(regid, tags);

Durch diese Methoden wird eine Registrierung für das Gerät erstellt oder aktualisiert, auf dem sie aufgerufen werden. Dies bedeutet, dass zum Aktualisieren des Handles oder der Tags die gesamte Registrierung überschrieben werden muss. Denken Sie daran, dass Registrierungen vorübergehend sind, daher sollten Sie immer über einen zuverlässigen Speicher (entweder lokaler Speicher auf dem Gerät oder in Ihrer App-Back-End) mit den aktuellen Tags verfügen, die ein bestimmtes Gerät benötigt. Ausführlichere Beispiele zum Aktualisieren von Registrierungen finden Sie im Lernprogramm "Breaking News ".

Sie können auch die REST-APIs verwenden, um sich vom Gerät zu registrieren. Weitere Informationen finden Sie in der Verwendung der REST-Schnittstelle für Benachrichtigungshubs.

Die folgenden Szenario-Lernprogramme bieten schrittweise Anleitungen zur Registrierung von Ihrem Client:

Vorlagen

Wenn Sie Vorlagen verwenden möchten, stellt jede Registrierung eine einzelne Vorlage dar. Dies bedeutet, dass Sie, wenn Ihr Gerät zwei Vorlagen verwendet, jede Vorlage unabhängig mit einem eigenen PNS-Handle und einer Gruppe von Tags registrieren müssen.

Bei systemeigenen Registrierungen (also ohne Vorlage) können Registrierungsmethoden für Vorlagen vorhandene Registrierungen erstellen oder aktualisieren. Zum Ziel verschiedener Vorlagen geben Sie beim Registrieren einen Vorlagennamen an. Sie geben verschiedene Namen an, wenn Sie mehrere Vorlagen für dasselbe Gerät verwalten möchten.

Wichtig

Wenn Sie Vorlagen verwenden, müssen Sie Ihr Gerät nicht registrieren, wie im vorherigen Abschnitt gezeigt. Diese Registrierung wird nur verwendet, wenn Sie systemeigene Benachrichtigungen senden (Benachrichtigungen, die in einem plattformspezifischen Format gesendet wurden).

Der folgende Code registriert Ihr Gerät mithilfe von Benachrichtigungshubs-API-Verweisen:

await hub.RegisterTemplateAsync(channelUri, template, templateName, tags);
[hub registerTemplateWithDeviceToken:deviceToken name:templateName jsonBodyTemplate: template expiryTemplate:nil tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.registerTemplate(regId, templateName, template, tags);

Beachten Sie, dass jeder Registrierungsaufruf zusätzlich zum PNS-Handle und dem optionalen Satz von Tags eine Vorlage für den Textkörper der Benachrichtigung und einen Namen für die Vorlage bereitstellt. Darüber hinaus kann jede Plattform zusätzliche Eigenschaften haben, die Teil der Vorlage sind. Bei Windows Store (mit WNS) und Windows Phone 8 (mit MPNS) kann eine zusätzliche Gruppe von Kopfzeilen Teil der Vorlage sein. Bei APNs können Sie eine Ablaufeigenschaft auf eine Konstante oder auf einen Vorlagenausdruck festlegen.

Anweisungen zum Ändern dieser Vorlagenfelder finden Sie unter API-Verweise oder Rest-APIs für Benachrichtigungshubs.

Sekundäre Kacheln für Windows Store-Apps

Für Windows Store-Clientanwendungen ist das Senden von Benachrichtigungen an sekundäre Kacheln und an die primäre Kachel identisch. Sowohl systemeigene als auch Vorlagenregistrierungen werden unterstützt. Der einzige Unterschied besteht darin, dass sekundäre Kacheln einen anderen ChannelUri aufweisen, den das SDK in Ihrer Client-App transparent verarbeitet.

Auf hoher Ebene arbeiten alle Informationen in den vorherigen Abschnitten mit sekundären Kacheln, indem die entsprechenden Methoden für die Objekte aufgerufen werden, die auf der Wörterbucheigenschaft Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles verfügbar gemacht werden. Beispiel:

await hub.SecondaryTiles["myTileId"].RegisterNativeAsync(new string[] {"Yankees"});
await hub.SecondaryTiles["myTileId"].RegisterTemplateAsync(buildToastTemplate(), "toastTemplate", new string[] {"RedSox"});

Das SecondaryTiles-Wörterbuch verwendet dieselbe TileId, die zum Erstellen des SecondaryTiles-Objekts in Ihrer Windows Store-App verwendet wird.

Wie beim primären ChannelUri können sich ChannelUris sekundärer Kacheln jederzeit ändern. Damit die Client-App-Registrierungen im Benachrichtigungshub aktualisiert werden können, muss das Gerät sie mit den aktuellen ChannelUris der sekundären Kacheln aktualisieren.

Hinweis

Sie können sekundäre Kacheln löschen, wenn die App inaktiv ist. Die entsprechenden Registrierungen führen nicht zu Benachrichtigungen und werden automatisch von den Benachrichtigungshubs gelöscht.

Nachteile der Registrierung vom Gerät

Die Registrierung über das Gerät ist die einfachste Methode, hat jedoch einige Nachteile.

Der erste Nachteil besteht darin, dass eine Client-App ihre Tags nur aktualisieren kann, wenn die App aktiv ist. Wenn ein Benutzer beispielsweise zwei Geräte besitzt, die Tags im Zusammenhang mit Sportteams registrieren, wenn sich das erste Gerät für ein zusätzliches Tag registriert (z. B. Seahawks), erhält das zweite Gerät erst dann die Benachrichtigungen über die Seahawks, bis die App auf dem zweiten Gerät ein zweites Mal ausgeführt wird. Allgemeiner ausgedrückt bedeutet dies, dass die Verwaltung von Tags möglichst über das Back-End erfolgen sollte, wenn Tags für mehrere Geräte gelten.

Der zweite Nachteil der Registrierungsverwaltung über die Client-App besteht darin, dass die Registrierung mit besonderer Sorgfalt auf bestimmte Tags beschränkt werden muss (wie im Abschnitt "Sicherheit auf Tagebene" erläutert), da Apps gehackt werden können.

Registrierungsverwaltung aus dem App-Back-End

Zum Verwalten von Registrierungen über das Back-End muss zusätzlicher Code geschrieben werden. Die App vom Gerät muss das aktualisierte PNS-Handle jedes Mal bereitstellen, wenn die App gestartet wird (zusammen mit Tags und Vorlagen), und das Back-End muss diesen Handle auf Service Bus aktualisieren. Dieses Verfahren wird in der folgenden Abbildung veranschaulicht.

Registration Management

Die Vorteile der Verwaltung von Registrierungen aus dem Back-End sind die Möglichkeit, Tags in Registrierungen zu ändern, auch wenn die entsprechende App auf dem Gerät inaktiv ist, und um die Client-App zu authentifizieren, bevor Sie der Registrierung ein Tag hinzufügen.

Über das App-Back-End können Sie grundlegende CRUDS-Vorgänge für Registrierungen ausführen. Beispiele:

var hub = NotificationHubClient.CreateClientFromConnectionString("{connectionString}", "hubName");
            
// create a registration description object of the correct type, e.g.
var reg = new WindowsRegistrationDescription(channelUri, tags);

// Create
await hub.CreateRegistrationAsync(reg);

// Get by id
var r = await hub.GetRegistrationAsync<RegistrationDescription>("id");

// update
r.Tags.Add("myTag");

// update on hub
await hub.UpdateRegistrationAsync(r);

// delete
await hub.DeleteRegistrationAsync(r);

Sie können auch Node oder die REST-APIs verwenden.

Wichtig

Die Nebenläufigkeit zwischen Registrierungsupdates muss vom Back-End behandelt werden. Service Bus unterstützt die Steuerung für optimistische Nebenläufigkeit für die Registrierungsverwaltung. Auf HTTP-Ebene wird dies mit der Verwendung von ETag für Registrierungsverwaltungsvorgänge implementiert. Dieses Feature wird von Microsoft-SDKs, die eine Ausnahme auslösen, wenn ein Update aus Gründen der Nebenläufigkeit abgelehnt wird, transparent verwendet. Das Back-End ist dafür verantwortlich, diese Ausnahmen zu behandeln und das Update ggf. zu wiederholen.

Weitere Ressourcen

In den folgenden Szenario-Lernprogrammen finden Sie schrittweise Anleitungen zur Registrierung von Ihrem App-Back-End: