Dieser Artikel wurde maschinell übersetzt.
Microsoft Azure
Himmelblau Benachrichtigung Naben: Bewährte Methoden zum Verwalten von Geräten
Laden Sie die Codebeispiele herunter
Der mobile Anwendungen-Markt wächst schneller und schneller und Verbesserung UX jeder Anwendung ist entscheidend, da es die Benutzer Loyalität erhöht. Eines der wichtigsten Merkmale moderner Anwendungen ist, dass sie am Leben gehalten werden können das heißt, der Benutzer informiert über die neuesten Ereignisse, die in der Anwendung aufgetreten sind, auch wenn es nicht genutzt wird. Dies ist möglich durch Push-Benachrichtigungen.
Jede mobile Plattform hat eine eigene Push-Benachrichtigungsdienst (PNS), verantwortlich für den Druck der der Benachrichtigungen — kurze Nachrichten — auf das Gerät. Windows-Anwendungen können apps, verschiedene Push-Benachrichtigung-Typen zu erhalten, die verschiedene Möglichkeiten um die Meldung anzuzeigen darstellen: Toast, Ziegel, Roh und Abzeichen. Für Android-Anwendungen auf der anderen Seite nur eine Schlüssel-Wert-Nachricht wird an das Gerät gesendet und das Layout wird durch die Klasse für die Verwaltung von Push-Benachrichtigungen in der Anwendung definiert. In Apple iOS-Anwendungen ist der Prozess eine Kombination dieser Ansätze.
Die PNS liefert die Benachrichtigungen, obwohl jede Anwendung benötigt ein Back-End oder ein Web- oder Desktopanwendung, die Nachricht zu definieren und zum Herstellen einer Verbindung mit des Push-Benachrichtigung-Anbieters zu senden.
Himmelblau Notification-Hubs ist ein Microsoft Azure-Service, der eine easy-to-Use-Infrastruktur bietet für das Senden von Push-Benachrichtigungen vom Back-End auf jede mobile Plattform. Tatsächlich gibt es zwei Grundprinzipien und zwei Modelle zum Verwalten von Geräten in der Notification-Hubs. In diesem Artikel werde ich zeigen, wie jedes Muster verwendet werden soll; diskutieren Sie die Vorteile, Nachteile und mögliche Szenarien für jeden; und beschreiben Sie die verschiedenen Modelle, die verwendet werden können. Ich werde konzentrieren sich auf bewährte Methoden für das Senden von Cross-Plattform und maßgeschneiderte Push-Benachrichtigungen mit Benachrichtigung Hubs und auch zeigen, wie die Benachrichtigung Hubs in Azure-Mobile-Dienste integriert wird.
Der Lebenszyklus der Push-Benachrichtigung
Der Push-Benachrichtigung-Lebenszyklus besteht aus drei Hauptschritten:
- Die Anwendung sendet eine Anforderung für die Push Notification Service Handle, die ein Token, Channel-URI oder ein RegistrationId, abhängig von der mobilen Plattform sein kann.
- Die Anwendung sendet die PNS an die Back-End speichern behandeln.
- Die Back-End sendet eine Anforderung an die PNS, liefert dann die Push-Benachrichtigung.
Konzeptionell dieser Prozess ist sehr einfach, aber in der Praxis es ist nicht so einfach, da die Infrastruktur erforderlich, um diesen Strom zu implementieren komplexer ist. Wenn eine Anwendung für verschiedene Client-Plattformen bereitgestellt wird, erfordert es eine Implementierung für jede (in Wirklichkeit wird es eine Implementierung für jede Schnittstelle bereitgestellt durch jede Plattform darstellen). Darüber hinaus muss das Format für jede Push-Benachrichtigung eine eigene Plattform-Spezifikationen und, schließlich können diese schwer zu pflegen sein. Und das ist nicht alles: Die Back-End muss in der Lage, einige Push-Benachrichtigung-Dienste zu skalieren, die Ausstrahlung auf mehreren Geräten nicht unterstützen; zum Ziel-Push-Benachrichtigungen für verschiedene Interessengruppen; und überwachen die Push-Benachrichtigungen für Lieferstatus. Diese Probleme müssen im Back-End behandelt werden, und dies erfordert daher eine komplexe Infrastruktur.
Benachrichtigung Hubs verwenden
Wie bereits erwähnt, Azure Benachrichtigung Hubs erleichtert die mobile Push-Benachrichtigungen vom Back-End auf jede mobile Plattform senden und Senden von Pushbenachrichtigungen für verschiedene Interessensgruppen unterstützt und eine Überwachung, Telemetrie und Planen von push-Benachrichtigungen. Auf diese Weise ist die Benachrichtigung Hubs ein Dritter-Service, der hilft, Cross-Plattform- und personalisierte Push-Benachrichtigungen an Anwendungen und implementiert alle Bedürfnisse einer Push-Benachrichtigung-Infrastruktur zu senden.
Um Benachrichtigung Hubs in einer Anwendung zu integrieren erfordert die Konfiguration im Azure Portal; die Verbindung zwischen Benachrichtigung Hubs und die PNS sollten im Separator Konfiguration des jeweiligen Benachrichtigung Hub konfiguriert werden. Ohne diese Konfigurationen Push-Benachrichtigungen nicht gesendet werden, und tritt ein Fehler auf. (Wenn Sie jemals Zweifel über der Push Notification Service von Notification-Hubs unterstützt werden, ist das Trennzeichen Konfiguration der beste Ort, um zu überprüfen.) Um Benachrichtigung Hubs verwenden, müssen Sie verstehen, Markierungen, Vorlagen und die verschiedenen Möglichkeiten Benachrichtigung Hubs verwendet werden können.
Im allgemeinen steht für ein Tag eine Interessengemeinschaft, die Ihnen erlaubt, auf bestimmte Ziele Push-Benachrichtigungen senden. Beispielsweise könnte ein Sportnachrichtenanwendung Markierungen für jede Sportart definieren: Radfahren, Fußball, Tennis und So weiter, auf seine Interessen Basis ermöglicht den Benutzer auswählen, was er erhalten will. Für die Fälle, wo Authentifizierung erforderlich ist und der Fokus ist der Benutzer kann die Benutzer-Id als der Tag verwendet werden. In der Praxis ist ein Tag nicht mehr als eine einfache Zeichenfolge-Wert (wie "Radfahren", "Fußball" oder "Tennis"), und es ist auch nützlich für die Lokalisierung (für verschiedene Sprachen gibt es eine Muster wie "En_cycling" oder "Pt_cycling", welche stellt tags auf Englisch oder Portugiesisch, beziehungsweise).
Vorlagen kein neues Konzept, aber Benachrichtigung Hubs erstellt eine Abstraktion, die können Sie definieren, Plattform-spezifischen Vorlagen oder generische Vorlagen, was bedeutet, dass Sie angeben können, Schlüssel-/Wertpaare für jede Push-Benachrichtigung definiert, wenn das Gerät registriert ist. Die Registrierung liefern eine systemeigene Benachrichtigung (Toast, Nutzlast oder Nachricht), die Ausdrücke enthält (z. B. $(message)) mit einem Wert der Back-End oder Anwendung definieren wird, wenn die Push-Benachrichtigung gesendet wird.
Abbildung 1 zeigt Beispiele für die generische Vorlage (für Windows, iOS und Android) verwenden von Ausdrücken.
Abbildung 1 generische Vorlagen
var toast = new XElement("toast",
new XElement("visual",
new XElement("binding",
new XAttribute("template", "ToastText01"),
new XElement("text",
new XAttribute("id", "1"),
"$(message)")))).ToString(SaveOptions.DisableFormatting);
var alert = new JObject(
new JProperty("aps", new JObject(new JProperty("alert", "$(message)"))),
new JProperty("inAppMessage", notificationText))
.ToString(Newtonsoft.Json.Formatting.None);
var payload = new JObject(
new JProperty("data", new JObject(new JProperty("message", "$(message)"))))
.ToString(Newtonsoft.Json.Formatting.None);
Die Back-End oder die Anwendung füllt den Wert wenn sie den Schlüssel/Wert sendet (Abbildung 2 zeigt den Vorgang):
{"message", "Message here!"}
.png "eine plattformunabhängige Botschaft")
Abbildung 2 eine plattformunabhängige Botschaft
Geräte registrieren
In mobile Entwicklung mit Bekanntgabe Hubs gibt es zwei Muster zum Verwalten von Geräten und Senden von Push-Benachrichtigungen, die zwei verschiedene Modelle verwenden können. Die Muster können in der Regel wie folgt beschrieben werden:
Fall 1: Geräte zur direkten Verbindung Benachrichtigung Hubs
- Die Client-Anwendung verbindet sich direkt mit der Benachrichtigung-Hubs, um das Gerät zu registrieren.
- Die Back-End oder ein Web- oder desktop-Anwendung verbindet sich mit Benachrichtigung Hubs, die Push-Benachrichtigung zu senden.
- Die PNS liefern die mobile Push-Benachrichtigung.
Fall 2: Die Back-End Verwaltung von Geräten in der Notification-Hubs
- Die Client-Anwendung verbindet sich mit dem Back-End.
- Die Back-End verbindet mit Benachrichtigung Hubs, die Geräte zu registrieren.
- Die Back-End definiert die Push-Benachrichtigung, die von Hubs Benachrichtigung gesendet werden soll.
- Die PNS werden die mobilen Push-Benachrichtigung zu verteilen.
Beide Muster können Sie entweder die Registrierung-Modell oder das Modell der Installation zu verwenden; Diese Modelle beschreiben die Art und Weise, die ein Gerät die erforderliche Informationen an die Benachrichtigung-Hub sendet. Das Installation-Modell wurde vor kurzem eingeführt und wird empfohlen für neue Anwendungen oder auch für aktuelle Anwendungen. Dieses neue Modell machen nicht das Registrierung-Modell obsolet. Hier ist eine allgemeine Beschreibung der einzelnen Modelle:
Registrierung-Modell: In diesem Modell die Anwendung sendet eine Registrierungsanforderung an den Notification-Hub, Bereitstellung der PNS Handler und Markierungen und der Hub gibt eine Identifikationsnummer. Für jede Registrierung können Sie eine native Vorlage oder eine generische Vorlage, die die Nachricht definieren.
Installation-Modell: In diesem Modell sendet die Anwendung eine Installation-Anforderung an den Notification-Hub bietet alle für den Prozess erforderlichen Informationen: InstallationId (z. B. eine GUID), Tags, PNS Handler, Vorlagen und sekundäre Vorlagen (für Windows-Anwendungen).
Obwohl beide Modelle derzeit verfügbar sind, wurde das Modell der Installation bestimmte technische Gründe, einschließlich eingeführt:
- Das Installation-Modell ist einfacher zu implementieren und zu verwalten.
- Das Installation-Modell können partielle Aktualisierungen ändern, hinzufügen oder Entfernen von Markierungen, PNS Handler, Vorlagen und So weiter, ohne dass das Installation-Objekt; im Gegensatz dazu erfordert das Registrierung-Modell das gesamten Registrierung-Objekt.
- Das Registrierung-Modell führt die Möglichkeit der doppelten Eintragungen im Back-End für das gleiche Gerät.
- Registrierung-Modell erstellt Komplexität bei der Aufrechterhaltung der Liste der Anmeldungen.
- Egal welches Muster Sie verwenden, wird die Strömung identisch sein.
Java wieder endet mit dem Notification Hubs .NET und Java SDKs oder das Installation-Modell kann in jeder .NET verwendet werden. Für Client-Anwendungen können Sie die REST-API mit diesem Modell bis zur Freigabe des neuen NuGet-Pakets, die das Installation-Modell unterstützen wird. Finden Sie das aktuelle NuGet-Paket mit Unterstützung für die Registrierung-Modell, WindowsAzure.Messaging.Managed, abrufbar unter bit.ly/1ArIiIK.
Jetzt werfen wir einen Blick auf die zwei Muster.
Fall 1: Geräte zur direkten Verbindung Benachrichtigung Hubs
Ich werde zu diskutieren, was passiert, wenn Geräte direkt an Benachrichtigung Hubs anschließen, da dies das Muster von Entwicklern am häufigsten verwendet. Um dies zu beschreiben, wird das Registrierung-Modell verwendet.
Registrieren und Aufheben der Registrierung eines Geräts in Notification-Hubs: Das Gerät fordert einen PNS-Handle von der PNS, dann verbindet es mit einem Notification-Hub zu registrieren, das PNS handle. Die Notification-Hub verwendet diesen Wert in der PNS-Verbindung.
In der Praxis, zum Beispiel mit Universal-Anwendungen startet die Anwendung durch den Kanal von der Windows Push Notification-Dienst (WNS) mit dem folgenden Code anfordern:
// Get the channel from the application
var pushNotificationChannel =
await PushNotificationChannelManager.
CreatePushNotificationChannelForApplicationAsync();
Für Android Google Cloud Messaging stellt ein RegistrationId sowie für iOS, das Apple Push Notification Service bietet ein Token.
Ein Notification-Hub-Objekt werden mit der Hub-Name, definiert in der Azure-Portal und die Verbindungszeichenfolge (genauer gesagt, der DefaultListenSharedAccessSignature-Schlüssel) erstellt:
// Create the notification hub object
var hub = new NotificationHub(HubName, ConnectionString);
Anmerkung, die die NotificationHub-Klasse von Windows bereitgestellt wirdAzure.Messaging.Managed NuGet Paket (bit.ly/1ArIiIK).
Jetzt kann die Anwendung mit der Benachrichtigung-Hub registriert werden:
// Register the device in Notification Hubs
var result =
await hub.RegisterNativeAsync(pushNotificationChannel.Uri, Tags);
Wenn Sie ein Gerät in Hubs Benachrichtigung registrieren, du musst keine Liste von Tags zu bieten, aber wenn die Anwendung Interesse Gruppen definieren muss, sollten die Tags in das Gerät in eine Registrierung-Update zu verwenden gespeichert werden.
Beachten Sie, dass das Ergebnis.RegistrationId empfangen die ID des der Eintragung im Notification Hubs und sollte nicht mit der RegistrationId verwendet in Android-Anwendungen (die Id von Google Cloud Messaging) verwechselt werden.
Die Push-Benachrichtigung senden: Die Back-End (oder eine Anwendung) verbindet mit der Benachrichtigung-Hub die Push-Benachrichtigung zu senden, die an bestimmte Tags (oder nicht) gesendet werden können mithilfe einer spezifischen oder generischen Vorlage.
In diesem Fall ist es nicht wichtig, wer mit der Benachrichtigung-Hub, der Back-End oder ein Web- oder desktop-Anwendung zum Senden der Benachrichtigungs verbunden wird. In der Praxis ein NotificationHubClient-Objekt erstellt werden soll, und es wird der Name des Hub, definiert in der Azure-Portal und die Verbindungszeichenfolge (genauer gesagt, der DefaultFullSharedAccessSignature-Schlüssel) verlangen:
// Create the Notification Hub client object
var hub = NotificationHubClient.CreateClientFromConnectionString(
HubName, ConnectionString);
Als nächstes muss die nativen Push-Benachrichtigung werden definiert, z. B. wie in gezeigt Abbildung 3.
Abbildung 3 Definieren der gebürtige Push-Benachrichtigungen
// Define template for Windows
var toast =
new XElement("toast",
new XElement("visual",
new XElement("binding",
new XAttribute("template", "ToastText01"),
new XElement("text",
new XAttribute("id", "1"),
notificationText)))).ToString(SaveOptions.DisableFormatting);
// Define template for iOS
var alert = new JObject(
new JProperty("aps", new JObject(new JProperty("alert", notificationText))),
new JProperty("inAppMessage", notificationText))
.ToString(Newtonsoft.Json.Formatting.None);
// Define template for Android
var payload = new JObject(
new JProperty("data", new JObject(new JProperty("message", notificationText)))
.ToString(Newtonsoft.Json.Formatting.None);
Und dann kann die Push-Benachrichtigung gesendet werden:
var googleResult =
await hub.SendGcmNativeNotificationAsync(payload, tags);
var windowsResult =
await hub.SendWindowsNativeNotificationAsync(toast, tags;
var appleResult =
await hub.SendAppleNativeNotificationAsync(alert, tags);
Wenn eine mobile Push-Benachrichtigung gesendet wird, eine Liste von Tags angegeben werden kann, aber dies ist optional (es hängt von den Anforderungen der Anwendung).
Verteilen die Push-Benachrichtigung: Um den Vorgang abzuschließen, tritt die PNS die Benachrichtigung auf Geräte. Der Dienst versucht, die Benachrichtigung während eines begrenzten Zeitraums Zeit, drücken Sie die für die einzelnen Dienste variiert.
Einer der Vorteile dieses Szenarios ist, dass es nicht, ein Back-End erforderlich, aber es ein Nachteil, ist wenn ein Benutzer mehrere Geräte verwendet: Die Tags sind nicht von Geräten gemeinsam genutzt, und der Benutzer muss die Markierungen jeweils neu zu definieren. Die mobile Anwendung hängt von der Notification-Hub, und es ist jedes Mal die Tags in der Anwendung zu aktualisieren, die ein Problem sein kann, wenn der Benutzer auf die neueste Version (ein häufiges Problem bei mobilen Anwendungen) aktualisieren nicht nötig.
Mögliche Szenarien für diesen Fall können einschließen:
- Die mobile Anwendung erfordert kein Back-End, z. B. Wann Push-Benachrichtigungen, indem eine desktop-Anwendung mit dieser Kapazität oder Back-Office (der Admin-Website gesendet werden). Betrachten Sie beispielsweise eine Anwendung, die auf der Grundlage eines online-Tech-Ereignisses News-feed, die einen Einstellungen in dem Benutzer ihre Interessen, wie z. B. Veranstaltungen für Entwickler, IT-Pro-Veranstaltungen und so weiter abonnieren können. Nachdem die Interessen ausgewählt werden, erhält der Benutzer die Push-Benachrichtigungen für diese Interessen. Anstatt ein Back-End Push-Benachrichtigungen auslösen, kann eine desktop-Applikation oder Back-Office direkt mit der Benachrichtigung-Hub sprechen, wenn ein neues Ereignis erstellt wird, um Push-Benachrichtigungen an alle Geräte auszulösen, die das spezifische Interesse abonniert haben.
- Die mobile Anwendung verwendet ein Back-End, aber die Push-Benachrichtigungen, aus irgendeinem Grund nicht in den Diensten integriert sind und gesendet werden, indem eine desktop-Anwendung oder Back-Office. Ein Beispiel könnte ein Client befinden, die einen Dienst liefert Informationen in der Anwendung zeigen, aber nicht zulassen, dass Änderungen an den Dienst (die von verschiedenen Anwendungen verwendet werden können). Der Client kann jedoch zur Unterstützung von Push-Benachrichtigungen Benachrichtigungen mithilfe der Back-Office oder auch eine desktop-Anwendung senden.
Fall 2: Die Back-End Verwaltung von Geräten in der Notification-Hubs
Um dieses Muster zu beschreiben, die ich verwende des neuen Konzepts auf der Grundlage der InstallaTion Modell, hat vor kurzem das Notification-Hubs-Team.
Die Anwendung verbindet sich mit dem Back-End: In diesem Fall verbindet die Anwendung mit dem Back-End erstellen oder aktualisieren das Installation-Objekt, das lokal gespeichert werden.
Das Gerät fordert das PNS-Handle von der PNS und erhält von der letzten Installation von Notification-Hub, auf dem Gerät gespeichert. Das Gerät verbindet dann mit dem Back-End erstellen oder aktualisieren Sie die Installation aus dem Gerät in der Notification-Nabe. (Ein neues Objekt der Installation zum ersten Mal erstellt werden, aber es sollte wieder jedes Mal, wenn der Back-End mit der Benachrichtigung-Hub für das gleiche Gerät verwendet werden.)
Beispielsweise wird in Universal-Anwendungen die Anwendung gestartet, durch den Channel-URI von der WNS mit folgendem anfordern:
// Get the channel from the application
var pushNotificationChannel =
await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
Bevor Sie die Anforderung an die Back-End erstellen oder aktualisieren Sie die Installation vornehmen, muss das Installation-Objekt definiert werden:
// Retrieve installation from local storage and
// create new one if it does not exist
var installation = SettingsHelper.Installation;
if (installation == null)
{
installation = new Installation
{
InstallationId = Guid.NewGuid().ToString(),
Platform = NotificationPlatform.Wns,
PushChannel = pushNotificationChannel.ToString(),
Tags = new List<string> {“news", "sports"}
};
}
Die Installation-Klasse in der Clientanwendung verwendet wird aus dem JSON gemäß der Dokumentation erstellt.
An dieser Stelle können Sie die Registrierung mit Code wie folgt anfordern:
// Create a client to send the HTTP registration request
var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Post, new Uri(_registerUri))
{
Content = new StringContent(JsonConvert.SerializeObject(installation),
Encoding.UTF8, "application/json")
};
var response = await client.SendAsync(request);
Die Back-End erstellt oder aktualisiert die Installation vom Gerät in der Notification-Nabe: Wenn der Back-End eine Anforderung an das Gerät mithilfe des Objektmodells Installation registrieren erhält, verbindet mit dem Hub Benachrichtigung erstellen oder aktualisieren Sie die Installation. Z. B. in ASP.NET Web API erstellen Sie eine NotificationHubController um die Dienste zum Verwalten von Geräten in Notification Hubs zu definieren. Die Umsetzung erfordert eine Benachrichtigung Hub-Client-Objekt, das im Konstruktor wie folgt definiert werden kann:
public class NotificationHubController : ApiController
{
private readonly NotificationHubClient _notificationHubClient;
private const string HubName = "<define the notification hub name>";
private const string ConnectionString = "<define the connection string>"
public NotificationHubController()
{
_notificationHubClient =
NotificationHubClient.CreateClientFromConnectionString(
ConnectionString, HubName);
}
Jetzt Sie die Methode, die erstellen oder aktualisieren Sie die Installation, die als Eingabe das Installation-Objekt erhalten schreiben können, etwa so:
[HttpPost]
[Route("api/NH/CreateOrUpdate")]
public async Task CreateOrUpdateAsync(Installation installation)
{
// Before creating or updating the installation is possible,
// you must change the tags to have secure tags
await _notificationHubClient.
CreateOrUpdateInstallationAsync(installation);
}
Beachten Sie, dass die Tags definiert und im Back-End (bei beiden Modellen) gespeichert werden können. Die mobile Anwendung ist nicht erforderlich, um speichern oder sogar über sie wissen. Betrachten Sie beispielsweise eine Bank-Anwendung, die Tags für jedes Konto für einen Kunden definiert. Wenn eine Operation für ein Konto erfolgt ist, ist eine Push-Benachrichtigung an das Gerät für dieses Konto gesendet. In diesem Fall muss die Tags zu sichern und die Back-End wird sie kennen.
Im Installation-Modell werden die Installation in der Notification-Hub gespeichert, die bedeutet, dass, die Sie abgerufen werden können, auf der InstallationId basieren.
Die Back-End definiert die Push-Benachrichtigung, die durch den Hub Benachrichtigung gesendet werden soll: Die Back-End ist verantwortlich für die Push-Benachrichtigung an den Hub Benachrichtigung senden, und Sie können Tags und die Vorlage für jede Plattform (wenn eine generische Vorlage nicht definiert ist).
Die Implementierung ist ähnlich wie das Szenario für den Fall, dass 1, wo die Rückseite enden oder eine Anwendung stellt eine mit der Benachrichtigung-Hub Verbindung, die Push-Benachrichtigung zu senden, damit ich keinen zusätzlichen Code für diesen Fall bieten.
By the way, im Installation-Modell ist es möglich, eine Push-Benachrichtigung an eine spezifische Installation zu senden. Dies ist ein neues Feature nur für Registrierungen, die Grundlage des Installation-Modells. Hier ist der Code dazu:
_notificationHubClient.SendWindowsNativeNotificationAsync(
payload, "$InstallationId:{" + installationId + "}");
Zum Push-Notification-Service werden die Push-Benachrichtigung zu verteilen: Um den Vorgang abzuschließen, liefern die PNS Push-Benachrichtigungen an die Geräte während eines begrenzten Zeitraums.
Einer der Vorteile dieses Falles ist, dass Markierungen statisch oder dynamisch, sein können, was bedeutet, dass sie jederzeit ändern können, ohne zu ändern oder beeinflussen die mobilen Anwendungen; Markierungen sind sicher, weil jeder Benutzer nur für einen Tag registriert werden kann, wenn er authentifiziert ist; Markierungen können zwischen verschiedenen Geräten für den gleichen Benutzer freigegeben werden; die mobile Anwendung ist völlig unabhängig von Notification-Hubs. Der Nachteil dieses Falles ist, dass die Tatsache der Prozess ist komplexer als der erste Fall, wenn das Registrierung-Modell verwendet wird.
Mögliche Szenarien für unter anderem folgende:
- Eine mobile Anwendung, die mit einem Back-End und die Tags verbindet muss sicher sein. Ein gutes Beispiel für diesen Fall ist eine Anwendung, die mit Bezug auf Bankkonten, die Push-Benachrichtigungen, damit Benutzer nicht informiert über Transaktionen auf ihrem Konto unterstützt.
- Eine mobile Anwendung, die mit einem Back-End und Tags verbindet muss dynamisch sein. Betrachten Sie eine Anwendung, die Informationen für verschiedene Musik-Events, mit Tags definieren verschiedene Ereignisse, und für jedes Ereignis können Benutzer abonnieren, um über alle damit verbundenen Informationen aktualisiert werden. Der Lebenszyklus für jedes Tag ist kurz, und jedes Mal, wenn ein neues Ereignis erstellt wird, entsteht ein neues Tag für dieses Ereignis. Tags, daher sind dynamisch und können von der Back-End, halten den Prozess unabhängig von der mobilen Anwendung verwaltet werden.
In beiden Szenarien Tags sollten in die Back-End gespeichert werden, aber das bedeutet nicht, dass die mobile Client nicht bewusst ist.
Aktualisierung der Registrierungen
Mit dem Modell Registrierung müssen jedes Mal, wenn Sie im Zusammenhang mit der Registrierung aktualisieren möchten wie die Tags verwendet wird, Sie die Registrierung wiederherstellen; Dies ist erforderlich, um die Aktualisierung abzuschließen. Aber in der Installation-Modell können Sie nur bestimmte Informationen aktualisieren. Das bedeutet, wenn die Anwendung eine Markierung, die Vorlagen sowie andere Daten aktualisieren muss, ist es möglich ein partielles Update zu tun. Hier ist der Code für die Aktualisierung eines Tags:
// Define the partial update
PartialUpdateOperation replaceTagsOperation =
new PartialUpdateOperation();
replaceTagsOperation.Operation = UpdateOperationType.Replace;
replaceTagsOperation.Path = "/tags/tennis";
replaceTagsOperation.Value = "cycling";
partialUpdates.Add(replaceTagsOperation);
// Send the partial update
_notificationHubClient.PatchInstallation(
installationId, partialUpdates);
Verwenden von Notification-Hubs in himmelblau Mobile Services
Himmelblau Mobile-Services können Sie eine Anwendung mit eine skalierbare und sichere Backend entwickeln (mit der Microsoft .NET Framework oder Node.js) in Azure gehostet. Mit dem Fokus auf mobile Anwendungen bietet Azure Mobile Services die wichtigsten Merkmale, die eine mobile Anwendung, die z. b. CRUD Operationen, soziales Netzwerk-Authentifizierung, offline-Unterstützung, Push-Benachrichtigungen und mehr benötigt.
Push-Benachrichtigungen werden von Notification-Hubs in Azure-Mobile-Dienste bereitgestellt, und jedes Mal, wenn eine Azure-Mobile-Dienst erstellt wird, eine Notification-Hub erstellt und dem Azure-Mobile-Dienst zugeordnet.
Mobile Anwendungen, die Azure-Mobile-Dienste verwenden können Push-Benachrichtigungen auf schnelle und einfache Weise implementieren, da das Azure-Mobile-Services-SDK APIs für bietet:
- Client-Anwendungen, Geräte, die mit dem Back-End zu registrieren.
- Ein Back-End zum Verwalten von Geräten in einem Notification-Hub; um Anforderungen von Geräten zu ändern, kann d. h. die Back-End hinzufügen, ändern oder Löschen von Tags aus dem Antrag von mobilen Anwendungen, oder sogar zu annullieren die Registrierung; Push-Benachrichtigungen (mit einer bestimmten Vorlage und wenn Markierungen erforderlich sind, bieten ihnen) zu senden.
Die Umsetzung der .NET-Back-end wird etwas ähnlich sein:
await Services.Push.SendAsync(
GetWindowsPushMessageForToastText01(
"My push notification message", tags));
Die Methode GetWindowsPushMessageForToastText01 definiert die Vorlage für die Push-Benachrichtigung auf einer Nachricht basierend und umgesetzt werden kann, wie in Abbildung 4.
Abbildung 4 definieren eine WindowsPushMessage basierend auf der ToastText01-Vorlage
public static IPushMessage GetWindowsPushMessageForToastText01(string message)
{
var payload = new XElement("toast",
new XElement("visual",
new XElement("binding",
new XAttribute("template", "ToastText01"),
new XElement("text",
new XAttribute("id", "1"), message))))
.ToString(SaveOptions.DisableFormatting);
return new WindowsPushMessage
{
XmlPayload = payload
};
}
In der Client-Anwendung, zum Beispiel in Universal Apps müssen Sie den Kanal von WNS anfordern:
// Get the channel
var channel =
await PushNotificationChannelManager.
CreatePushNotificationChannelForApplicationAsync();
Dann der mobilen Service-Client erstellt werden soll, und es erlaubt die Interaktion mit dem Backend:
// Create the MobileServiceClient using the
// AzureEndpoint and admin key
var mobileServiceClient =
new Microsoft.WindowsAzure.MobileServices.MobileServiceClient(
AzureEndPoint, AzureMobileServiceApplicationKey);
Die AzureEndPoint sollte etwas sein, wie https://mymobileservice.azure-mobile.net/ und die AzureMobileServiceApplicationKey ist eine Zeichenfolge, die die Anwendungstaste definiert im Azure Portal darstellt.
Die Methode RegisterNativeAsync können Sie um eine Gerät wie folgt zu registrieren:
// Register the device
await MobileServiceClient.Client.GetPush().RegisterNativeAsync(
channel.Uri, tags);
Aber wenn du gehst, um das Gerät mit einer generischen Vorlage zu registrieren, verwenden Sie die RegisterTemplateAsync-Methode.
Unter Azure mobilen Diensten (Back-End mit .NET), zu erweitern, zu ändern oder zu stornieren die Registrierung für Azure Benachrichtigung Naben sollte die INotificationHandler-Schnittstelle implementiert werden. Auf diese Weise können Sie z. B. sichere Tags verfügen.
Zusammenfassung
Benachrichtigung Hubs bietet eine Abstraktion, Push-Benachrichtigungen vom Back-End auf jede mobile Plattform senden, und das neue Modell ermöglicht Ihnen eine einzigartige Installation zu definieren, die die geforderten Benachrichtigung Hubs wesentliche Angaben enthält. Installation vermeidet doppelte Registrierung und Komplexität, für neue Anwendungen oder auch in aktuellen Anwendungen wiederverwendet werden kann, empfiehlt sich das Installation-Modell. Es gibt zwei wichtigsten Muster für die Registrierung von Geräten an Benachrichtigungen Hubs, die je nach Anwendungsanforderungen gewählt werden sollte.
Dieses Modell ermöglicht Ihnen das Senden von Nachrichten auf bestimmte Interessensgruppen mit Tags konzentriert, und es ist auch möglich, allgemeine oder bestimmte Vorlagen zu definieren und zu skalieren und den Service entsprechend den Anforderungen der Anwendung überwachen. Schließlich werden einfach zu bedienende SDKs für die mobile apps und Back-End in mehreren Sprachen bereitgestellt.
Benachrichtigung Naben standardmäßig ein Plus für Entwickler ist, weil dadurch Umsetzung der Funktion für die Push-Benachrichtigung auf eine schnelle und einfache Weise integriert.
Sara Silva ist ein Mathematik-Absolvent und Microsoft MVP. Heute arbeitet sie als mobile Entwickler in Portugal mit einem Schwerpunkt auf Windows-Anwendungen, Xamarin und Microsoft Azure. She bloggt auf saramgsilva.com und kann auf Twitter bei twitter.com/saramgsilva.
Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Piyush Joshi, Paulo Morgado und Chris Risner