Registratiebeheer
In dit onderwerp wordt uitgelegd hoe u apparaten registreert bij Notification Hubs om pushmeldingen te ontvangen. In het onderwerp worden registraties op hoog niveau beschreven, waarna de twee hoofdpatronen voor het registreren van apparaten worden geïntroduceerd: rechtstreeks vanaf het apparaat registreren bij de Notification Hub en registreren via de back-end van de toepassing.
Wat is een apparaatregistratie?
Een registratie is een subentiteit van een Notification Hub en koppelt een PNS-ingang (een Platform Notification Service-handle, bijvoorbeeld ChannelURI, apparaattoken, GCM registrationId) aan tags en mogelijk een sjabloon. Tags worden gebruikt om meldingen te routeren naar de juiste set apparaatgrepen. Zie Routerings- en tagexpressies voor meer informatie. Sjablonen worden gebruikt om transformatie per registratie te implementeren. Zie Sjablonen voor meer informatie.
Het is belangrijk te weten dat registraties tijdelijk zijn. Net als bij de PNS-ingangen die ze bevatten, verlopen registraties. U kunt de time to live instellen voor een registratie op de Notification Hub, maximaal 90 dagen. Deze limiet betekent dat ze periodiek moeten worden vernieuwd en dat ze niet de enige opslag mogen zijn voor belangrijke informatie. Deze automatische vervaldatum vereenvoudigt ook het opschonen wanneer uw mobiele toepassing wordt verwijderd.
Registraties moeten de meest recente PNS-ingang voor elk apparaat/kanaal bevatten. Omdat PNS-ingangen alleen kunnen worden verkregen in de client-app op het apparaat, is één manier om registraties rechtstreeks op die client-app te beheren. Aan de andere kant moeten beveiligingsoverwegingen en bedrijfslogica met betrekking tot tags u de registratie in de back-end van de app beheren. In de volgende sectie worden deze twee benaderingen beschreven.
Registratiebeheer vanaf het apparaat
Bij het beheren van registraties van client-apps is de back-end alleen verantwoordelijk voor het verzenden van meldingen. Client-apps houden de PNS-ingangen up-to-date en registreren bij tags. In de volgende afbeelding ziet u dit patroon.
Het apparaat haalt eerst de PNS-ingang op uit de PNS en registreert zich vervolgens rechtstreeks bij de Notification Hub. Nadat de registratie is geslaagd, kan de back-end van de app een melding verzenden die gericht is op die registratie. Zie Routerings- en tagexpressies voor meer informatie over het verzenden van meldingen.
In dit geval gebruikt u alleen listen-rechten voor toegang tot uw Notification Hubs vanaf het apparaat. Zie Beveiliging voor meer informatie.
Met de volgende code wordt uw apparaat geregistreerd met behulp van Notification Hubs API-verwijzingen:
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);
Met deze methoden maakt of werkt u een registratie bij voor het apparaat waarop ze worden aangeroepen. Dit betekent dat u de volledige registratie moet overschrijven om de handle of de tags bij te werken. Houd er rekening mee dat registraties tijdelijk zijn, dus u moet altijd een betrouwbare opslag (lokale opslag op het apparaat of in de back-end van uw app) hebben met de huidige tags die een specifiek apparaat nodig heeft. Zie de zelfstudie Breaking News voor gedetailleerdere voorbeelden van het bijwerken van registraties.
U kunt de REST API's ook gebruiken om u te registreren vanaf het apparaat. Zie De Rest-interface van Notification Hubs gebruiken voor meer informatie.
De volgende scenariozelfstudies bieden stapsgewijze instructies voor het registreren van uw client:
Sjablonen
Als u sjablonen wilt gebruiken, vertegenwoordigt elke registratie een afzonderlijke sjabloon. Dit betekent dat als uw apparaat twee sjablonen gebruikt, u elke sjabloon onafhankelijk moet registreren met een eigen PNS-ingang en een set tags.
Voor systeemeigen registraties (dat wil gezegd, zonder sjabloon), maken of bijwerken registratiemethoden voor sjablonen bestaande registraties. Als u zich wilt richten op verschillende sjablonen, geeft u een sjabloonnaam op bij het registreren. U geeft verschillende namen op als u meerdere sjablonen voor hetzelfde apparaat wilt onderhouden.
Belangrijk
Wanneer u sjablonen gebruikt, hoeft u uw apparaat niet te registreren zoals wordt weergegeven in de vorige sectie. Deze registratie wordt alleen gebruikt als u systeemeigen meldingen verzendt (meldingen die zijn verzonden in een platformspecifieke indeling).
Met de volgende code wordt uw apparaat geregistreerd met behulp van Notification Hubs API-verwijzingen:
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);
Houd er rekening mee dat elke registratieaanroep, naast de PNS-ingang en de optionele set tags, een sjabloon voor de hoofdtekst van de melding en een naam voor de sjabloon biedt. Bovendien kan elk platform aanvullende eigenschappen hebben die deel uitmaken van de sjabloon. In het geval van Windows Store (met WNS) en Windows Phone 8 (met MPNS), kan een extra set headers deel uitmaken van de sjabloon. In het geval van APN's kunt u een verloopeigenschap instellen op een constante of op een sjabloonexpressie.
Zie API-verwijzingen of Rest API's van Notification Hubs voor instructies over het wijzigen van deze sjabloonvelden.
Secundaire tegels voor Windows Store-apps
Voor Windows Store-clienttoepassingen is het verzenden van meldingen naar secundaire tegels hetzelfde als het verzenden ervan naar de primaire. Zowel systeemeigen als sjabloonregistraties worden ondersteund. Het enige verschil is dat secundaire tegels een andere ChannelUri hebben, die de SDK in uw client-app transparant verwerkt.
Op hoog niveau werken alle informatie in de vorige secties met secundaire tegels door de bijbehorende methoden aan te roepen voor de objecten die worden weergegeven in de woordenlijsteigenschap Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles. Bijvoorbeeld:
await hub.SecondaryTiles["myTileId"].RegisterNativeAsync(new string[] {"Yankees"});
await hub.SecondaryTiles["myTileId"].RegisterTemplateAsync(buildToastTemplate(), "toastTemplate", new string[] {"RedSox"});
De SecondaryTiles-woordenlijst gebruikt dezelfde TileId die wordt gebruikt om het SecondaryTiles-object te maken in uw Windows Store-app.
Net als bij de primaire ChannelUri kunnen ChannelUri's van secundaire tegels op elk gewenst moment worden gewijzigd. Als u de registraties van de client-app in de Notification Hub wilt bijwerken, moet het apparaat deze vernieuwen met de huidige ChannelUris van de secundaire tegels.
Notitie
U kunt secundaire tegels verwijderen wanneer de app inactief is. De bijbehorende registraties resulteren niet in meldingen en worden automatisch verwijderd door de Notification Hubs.
Nadelen van het registreren van het apparaat
Registreren vanaf het apparaat is de eenvoudigste methode, maar heeft enkele nadelen.
Het eerste nadeel is dat een client-app de tags alleen kan bijwerken wanneer de app actief is. Als een gebruiker bijvoorbeeld twee apparaten heeft die tags registreren die betrekking hebben op sportteams, wanneer het eerste apparaat zich registreert voor een extra tag (bijvoorbeeld Seahawks), ontvangt het tweede apparaat de meldingen over de Seahawks pas als de app op het tweede apparaat een tweede keer wordt uitgevoerd. Meer in het algemeen, wanneer tags worden beïnvloed door meerdere apparaten, is het beheren van tags van de back-end een wenselijke optie.
Het tweede nadeel van registratiebeheer van de client-app is dat, omdat apps kunnen worden gehackt, het beveiligen van de registratie voor specifieke tags extra zorg vereist, zoals wordt uitgelegd in de sectie 'Beveiliging op tagniveau'.
Registratiebeheer vanuit de back-end van de app
Voor het beheren van registraties van de back-end moet extra code worden geschreven. De app vanaf het apparaat moet de bijgewerkte PNS-ingang naar de back-end leveren telkens wanneer de app wordt gestart (samen met tags en sjablonen) en de back-end moet deze ingang op Service Bus bijwerken. In de volgende afbeelding ziet u dit ontwerp.
De voordelen van het beheren van registraties van de back-end zijn de mogelijkheid om tags te wijzigen in registraties, zelfs wanneer de bijbehorende app op het apparaat inactief is en om de client-app te verifiëren voordat u een tag toevoegt aan de registratie.
Vanuit de back-end van uw app kunt u eenvoudige CRUDS-bewerkingen uitvoeren voor registraties. Bijvoorbeeld:
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);
U kunt ook Node of de REST API's gebruiken.
Belangrijk
De back-end moet gelijktijdigheid tussen registratie-updates verwerken. Service Bus biedt optimistisch gelijktijdigheidsbeheer voor registratiebeheer. Op HTTP-niveau wordt dit geïmplementeerd met het gebruik van ETag voor registratiebeheerbewerkingen. Deze functie wordt transparant gebruikt door Microsoft SDK's, waardoor een uitzondering wordt gegenereerd als een update om gelijktijdigheidsredenen wordt geweigerd. De back-end van de app is verantwoordelijk voor het afhandelen van deze uitzonderingen en het opnieuw proberen van de update indien nodig.
Aanvullende resources
De volgende scenariozelfstudies bieden stapsgewijze instructies voor het registreren van uw app-back-end: