Gestion des inscriptions

Cette rubrique explique comment inscrire des appareils aux hubs de notification afin de recevoir des notifications Push. La rubrique décrit les inscriptions à un niveau élevé, puis présente les deux principaux modèles d’inscription des appareils : l’inscription de l’appareil directement vers le hub de notification et l’inscription via le back-end de l’application.

Qu’est-ce qu’une inscription d’appareil

Une inscription est une sous-entité d’un hub de notification et associe un handle PNS d’appareil (handle Platform Notification Service, par exemple, ChannelURI, jeton d’appareil, GCM registrationId) à des balises et éventuellement un modèle. Les balises permettent d’acheminer des notifications vers l’ensemble approprié de handles d’appareils. Pour plus d’informations, consultez Routage et expressions de balises. Les modèles permettent d’implémenter la transformation par inscription. Pour plus d’informations, consultez Modèles.

Il est important de noter que les inscriptions sont temporaires. Comme pour les handles PNS qu’ils contiennent, les inscriptions expirent. Vous pouvez définir la durée de vie d’une inscription sur le Hub de notification, jusqu’à un maximum de 90 jours. Cette limite signifie qu’elles doivent être actualisées régulièrement et qu’elles ne doivent pas être le seul magasin pour les informations importantes. Cette expiration automatique simplifie également le nettoyage lorsque votre application mobile est désinstallée.

Les inscriptions doivent contenir le handle PNS le plus récent pour chaque appareil/canal. Étant donné que les handles PNS ne peuvent être obtenus que dans l’application cliente sur l’appareil, un moyen de gérer les inscriptions est directement sur cette application cliente. En revanche, les considérations de sécurité et la logique métier liées aux balises peuvent nécessiter la gestion de l’inscription dans le back-end de l’application. La section suivante décrit ces deux approches.

Gestion des inscriptions à partir de l’appareil

Lors de la gestion des inscriptions à partir d’applications clientes, le back-end est uniquement responsable de l’envoi de notifications. Les applications clientes conservent les gestions PNS à jour et s’inscrivent aux balises. L’image suivante illustre ce modèle :

L’appareil extrait d’abord le handle PNS du PNS, puis s’inscrit directement auprès du hub de notification. Une fois l’inscription effectuée, le serveur principal de l’application peut envoyer une notification ciblant cette inscription. Pour plus d’informations sur l’envoi de notifications, consultez Routage et expressions de balises.

Notez que, dans ce cas, vous utiliserez les droits Listen (Écouter) pour accéder à vos hubs de notification à partir de l’appareil. Pour plus d’informations, consultez Sécurité.

Le code suivant inscrit votre appareil à l’aide des références d’API Notification Hubs :

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);

Ces méthodes créent ou mettent à jour une inscription de l’appareil sur lequel elles sont appelées. Cela signifie que pour mettre à jour le handle ou les balises, vous devez remplacer la totalité de l’inscription. N’oubliez pas que les inscriptions sont temporaires. Vous devez donc toujours disposer d’un magasin fiable (stockage local sur l’appareil ou dans votre back-end d’application) avec les balises actuelles dont un appareil spécifique a besoin. Pour obtenir des exemples plus détaillés de la mise à jour des inscriptions, consultez le tutoriel Sur les dernières nouvelles .

Vous pouvez également utiliser les API REST pour vous inscrire à partir de l’appareil. Pour plus d’informations, consultez Comment utiliser l’interface REST notification Hubs.

Les tutoriels de scénario suivants fournissent des conseils pas à pas sur l’inscription à partir de votre client :

• Prise en main avec Notification Hubs

• Dernières nouvelles

Modèles

Si vous souhaitez utiliser des modèles, chaque inscription représente un modèle individuel. Cela signifie que si votre appareil utilise deux modèles, vous devez inscrire chaque modèle indépendamment avec son propre handle PNS et son ensemble d’étiquettes.

Pour les inscriptions natives (autrement dit, sans modèle), les méthodes d’inscription pour les modèles créent ou mettent à jour des inscriptions existantes. Pour cibler différents modèles, vous fournissez un nom de modèle lors de l’inscription. Vous fournissez différents noms si vous souhaitez conserver plusieurs modèles pour le même appareil.

Important

Lorsque vous utilisez des modèles, vous n’avez pas besoin d’inscrire votre appareil comme indiqué dans la section précédente. Cette inscription est utilisée uniquement si vous envoyez des notifications natives (notifications envoyées dans un format spécifique à la plateforme).

Le code suivant inscrit votre appareil à l’aide des références d’API Notification Hubs :

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);

Notez que chaque appel d’inscription fournit, en plus du handle PNS et de l’ensemble facultatif de balises, un modèle pour le corps de la notification et un nom pour le modèle. De plus, chaque plateforme peut avoir des propriétés supplémentaires qui font partie du modèle. Dans le cas de Windows Store (à l’aide de WNS) et de Windows Phone 8 (à l’aide de MPNS), un ensemble supplémentaire d’en-têtes peut faire partie du modèle. Dans le cas d’APNs, vous pouvez définir une propriété d’expiration sur une constante ou une expression de modèle.

Pour obtenir des instructions sur la modification de ces champs de modèle, consultez références d’API ou API REST Notification Hubs.

Vignettes secondaires pour les applications Windows Store

Pour les applications clientes Windows Store, le fait d’envoyer des notifications à des vignettes secondaires revient à les envoyer à la vignette principale. Les inscriptions natives et de modèles sont prises en charge. La seule différence est que les vignettes secondaires ont un canalUri différent, que le SDK sur votre application cliente gère de manière transparente.

À un niveau élevé, toutes les informations fournies dans les sections précédentes fonctionnent avec des vignettes secondaires en appelant les méthodes correspondantes sur les objets exposés sur la propriété dictionnaire Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles. Par exemple :

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

Le dictionnaire SecondaryTiles utilise le même TileId utilisé pour créer l’objet SecondaryTiles dans votre application Windows Store.

Comme pour le paramètre principal ChannelUri, le paramètre ChannelUris des vignettes secondaires peut changer à tout moment. Pour conserver les inscriptions des applications clientes dans le hub de notification mis à jour, l’appareil doit les actualiser avec les canaux actuels des vignettes secondaires.

Notes

Vous pouvez supprimer des vignettes secondaires lorsque l’application est inactive. Les inscriptions correspondantes ne entraînent aucune notification et seront automatiquement supprimées par les hubs de notification.

Inconvénients de l’inscription à partir de l’appareil

L’inscription à partir de l’appareil est la méthode la plus simple, mais présente certains inconvénients.

Le premier inconvénient est qu’une application cliente peut mettre à jour ses balises uniquement lorsqu’elle est active. Par exemple, si un utilisateur a deux appareils qui inscrivent des balises liées aux équipes sportives, lorsque le premier appareil s’inscrit pour une balise supplémentaire (par exemple , Seahawks), le deuxième appareil ne reçoit pas les notifications relatives aux Seahawks tant que l’application sur le deuxième appareil n’est pas exécutée une seconde fois. De manière plus générale, lorsque les balises sont affectées par plusieurs appareils, la gestion des balises à partir du serveur principal est une option intéressante.

Le second inconvénient de la gestion des inscriptions à partir de l’application cliente réside dans le fait qu’étant donné que les applications peuvent être piratées, la limitation de l’inscription à des balises spécifiques nécessite de prendre des précautions supplémentaires, comme décrit dans la section « Sécurité au niveau des balises ».

Gestion des inscriptions à partir du back-end de l’application

La gestion des inscriptions à partir du serveur principal nécessite l’écriture de code supplémentaire. L’application à partir de l’appareil doit fournir le handle PNS mis à jour au back-end chaque fois que l’application démarre (ainsi que des balises et des modèles), et le back-end doit mettre à jour ce handle sur Service Bus. L’image suivante illustre cette conception :

Les avantages de la gestion des inscriptions à partir du back-end sont la possibilité de modifier des balises aux inscriptions même lorsque l’application correspondante sur l’appareil est inactive, et d’authentifier l’application cliente avant d’ajouter une balise à son inscription.

À partir de votre serveur principal d’application, vous pouvez effectuer les opérations CRUD de base sur les inscriptions. Par exemple :

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);

Vous pouvez également utiliser Node ou les API REST.

Important

Le serveur principal doit gérer l’accès concurrentiel entre les mises à jour des inscriptions. Service Bus offre un contrôle de l’accès concurrentiel optimiste pour la gestion des inscriptions. Au niveau HTTP, cela est implémenté avec l’utilisation d’ETag sur les opérations de gestion des inscriptions. Cette fonctionnalité est utilisée de manière transparente dans les Kits de développement logiciel (SDK) Microsoft, lesquels lèvent une exception si une mise à jour est refusée en raison d’accès concurrentiel. Le serveur principal d’application est chargé de gérer ces exceptions et, le cas échéant, de tenter une nouvelle mise à jour.

Ressources supplémentaires

Les tutoriels de scénario suivants fournissent des conseils pas à pas sur l’inscription à partir de votre back-end d’application :

• Utiliser des balises pour envoyer des notifications aux utilisateurs authentifiés

• Utiliser des modèles pour envoyer des notifications multiplateformes aux utilisateurs authentifiés