Administración de registros
En este tema se explica cómo registrar dispositivos en centros de notificaciones para recibir notificaciones push. En el tema se describen los registros en un nivel alto y, a continuación, se presentan los dos patrones principales para registrar dispositivos: registrarse desde el dispositivo directamente en el centro de notificaciones y registrarse a través del back-end de la aplicación.
¿Qué es un registro de dispositivo?
Un registro es una subentidad de un centro de notificaciones que asocia un controlador de PNS de dispositivo (un controlador de servicio de notificaciones de la plataforma, por ejemplo, ChannelURI, token de dispositivo, controlador de registro GCM) con etiquetas y, posiblemente, una plantilla. Las etiquetas se usan para enrutar las notificaciones al conjunto correcto de identificadores de dispositivos. Para obtener más información, consulte Expresiones de etiqueta y enrutamiento. Se utilizan plantillas para implementar la transformación por registro. Para obtener más información, consulte Plantillas.
Es importante tener en cuenta que los registros son transitorios. Al igual que los controladores de PNS que contienen, los registros expiran. Puede establecer el período de vida de un registro en el centro de notificaciones, hasta un máximo de 90 días. Este límite significa que deben actualizarse periódicamente y también que no deben ser el único almacén de información importante. Esta expiración automática también simplifica la limpieza cuando se desinstala la aplicación móvil.
Los registros deben contener el controlador de PNS más reciente para cada dispositivo o canal. Dado que los controladores de PNS solamente se pueden obtener en la aplicación cliente en el dispositivo, una manera de administrar registros es directamente en esa aplicación cliente. Por otro lado, las consideraciones de seguridad y la lógica de negocios relacionadas con etiquetas podrían requerirle que administrara el registro en el back-end de la aplicación. La siguiente sección describe estos dos enfoques.
Administración de registros desde el dispositivo
Al administrar registros desde aplicaciones cliente, el back-end solamente es responsable de enviar notificaciones. Las aplicaciones cliente mantienen los controladores de PNS actualizados y se registran en las etiquetas. La siguiente ilustración muestra este patrón.
.png "Registration Management")
El dispositivo primero recupera el identificador de PNS desde el PSN y, luego, se registra directamente con el centro de notificaciones. Una vez que el registro se realiza correctamente, el back-end de la aplicación puede enviar una notificación orientada a ese registro. Para obtener más información sobre cómo enviar notificaciones, consulte Expresiones de etiqueta y enrutamiento.
Tenga en cuenta que, en este caso, solo usará derechos de escucha para tener acceso a los centros de notificaciones desde el dispositivo. Para obtener más información, consulte Seguridad.
El código siguiente registra el dispositivo mediante referencias de API de 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);
Estos métodos crean o actualizan un registro para el dispositivo en el que se los llamaron. Esto significa que, para actualizar el identificador o las etiquetas, debe sobrescribir todo el registro. Recuerde que los registros son transitorios, de manera que siempre debe tener un almacén confiable (el almacenamiento local en el dispositivo o en el back-end de la aplicación) con las etiquetas actuales que necesita un determinado dispositivo. Consulte el tutorial de noticias de última hora para obtener ejemplos más detallados sobre cómo actualizar los registros.
También puede usar las API de REST para registrar desde el dispositivo. Para obtener más información, consulte Uso de la interfaz REST de Notification Hubs.
Los siguientes tutoriales de escenarios ofrecen una guía paso a paso sobre el registro desde el cliente:
Plantillas
Si desea usar plantillas, cada registro representa una plantilla individual. Esto significa que si el dispositivo usa dos plantillas, debe registrar cada plantilla de forma independiente con su propio controlador de PNS y el conjunto de etiquetas.
En el caso de los registros nativos (es decir, sin plantilla), los métodos de registro de plantillas crean o actualizan los registros existentes. Para dirigirse a varias plantillas, proporcione un nombre de plantilla durante el registro. Deberá proporcionar diferentes nombres si desea mantener varias plantillas para el mismo dispositivo.
Importante
Cuando use plantillas, no es necesario registrar el dispositivo como se muestra en la sección anterior. Ese tipo de registro solo se usa si envía notificaciones nativas (notificaciones enviadas en un formato específico de la plataforma).
El código siguiente registra el dispositivo mediante referencias de API de 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);
Tenga en cuenta que cada llamada de registro proporciona, además del controlador de PNS y el conjunto opcional de etiquetas, una plantilla para el cuerpo de la notificación y un nombre para la plantilla. Además, cada plataforma puede tener propiedades adicionales que forman parte de la plantilla. En el caso de la Tienda Windows (mediante WNS) y Windows Phone 8 (mediante MPNS), es posible que un conjunto adicional de encabezados forme parte de la plantilla. En el caso de APNs, puede establecer una propiedad de expiración en una constante o en una expresión de plantilla.
Para obtener instrucciones sobre cómo modificar estos campos de plantilla, consulte Referencias de API o API REST de Notification Hubs.
Iconos secundarios de Aplicaciones de la Tienda Windows
En el caso de las aplicaciones cliente de la Tienda Windows, enviar notificaciones a los iconos secundarios es igual que enviarlos al icono principal. Se admiten los registros tanto nativos como los de plantilla. La única diferencia es que los iconos secundarios tienen un ChannelUri diferente, que el SDK de la aplicación cliente controla de manera transparente.
En un nivel alto, toda la información proporcionada en las secciones anteriores funciona con iconos secundarios llamando a los métodos correspondientes en los objetos expuestos en la propiedad dictionary Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles. Por ejemplo:
await hub.SecondaryTiles["myTileId"].RegisterNativeAsync(new string[] {"Yankees"});
await hub.SecondaryTiles["myTileId"].RegisterTemplateAsync(buildToastTemplate(), "toastTemplate", new string[] {"RedSox"});
El diccionario SecondaryTiles usa el mismo TileId que se usa para crear el objeto SecondaryTiles en la aplicación Windows Store.
Al igual que lo que ocurre con el ChannelUri principal, los ChannelUri de los iconos secundarios pueden cambiar en cualquier momento. Para mantener actualizados los registros de aplicación cliente en el centro de notificaciones, el dispositivo debe actualizarlos con los ChannelUris actuales de los iconos secundarios.
Nota
Se pueden eliminar iconos secundarios cuando la aplicación está inactiva. Los registros correspondientes no generarán ninguna notificación y los centros de notificaciones los eliminarán automáticamente.
Desventajas del registro desde el dispositivo
El registro desde el dispositivo es el método más sencillo, pero tiene algunas desventajas.
La primera desventaja es que una aplicación cliente solo puede actualizar sus etiquetas cuando la aplicación está activa. Por ejemplo, si un usuario tiene dos dispositivos que registran etiquetas relacionadas con equipos deportivos, cuando el primer dispositivo se registra para una etiqueta adicional (por ejemplo, Seahawks), el segundo dispositivo no recibirá las notificaciones sobre Seahawks hasta que la aplicación del segundo dispositivo se ejecute una segunda vez. De manera más general, cuando son varios los dispositivos que afectan las etiquetas, la administración de estas desde el back-end es una opción conveniente.
La segunda desventaja de la administración de registros desde la aplicación cliente es que, debido a que es posible piratear las aplicaciones, proteger el registro de etiquetas específicas requiere un cuidado adicional, tal como se explica en la sección "Seguridad a nivel de etiqueta".
Administración de registros desde el servidor back-end de la aplicación
Administrar los registros desde el back-end requiere escribir código adicional. La aplicación del dispositivo debe proporcionar el identificador PNS actualizado al back-end cada vez que se inicia la aplicación (junto con etiquetas y plantillas) y el back-end debe actualizar este identificador en Service Bus. La siguiente ilustración muestra este diseño.
.png "Registration Management")
Las ventajas de administrar los registros desde el servidor back-end son la capacidad de modificar etiquetas para los registros, incluso cuando la aplicación correspondiente del dispositivo esté inactiva, y de autenticar la aplicación cliente antes de agregar una etiqueta a su registro.
Desde el back-end de la aplicación, puede ejecutar operaciones de tipo CRUD en los registros. Por ejemplo:
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);
También puede usar Node o las API de REST.
Importante
El back-end debe controlar la simultaneidad entre las actualizaciones de los registros. Service Bus ofrece un control de simultaneidad optimista para la administración de registros. En el nivel HTTP, esto se implementa con el uso de ETag en operaciones de administración de registros. Los SDK de Microsoft utilizan esta característica de manera transparente y generan una excepción si se rechaza una actualización por motivos de simultaneidad. El back-end de aplicación es responsable de controlar estas excepciones y de volver a intentar la actualización, si es necesario.
Recursos adicionales
Los siguientes tutoriales de escenarios ofrecen una guía paso a paso sobre el registro desde el servidor back-end de la aplicación: