Gestão de Registos

Este tópico explica como registar dispositivos nos centros de notificação para receber notificações push. O tópico descreve as inscrições a um nível elevado, introduzindo depois os dois principais padrões de registo dos dispositivos: registar-se do dispositivo diretamente para o centro de notificação e registar-se através do backend da aplicação.

O que é um registo de dispositivos

Um registo é uma sub-entidade de um centro de notificação, e associa um manípulo PNS do dispositivo (um cabo de Serviço de Notificação da Plataforma, por exemplo, ChannelURI, token do dispositivo, GCM registrationId) com etiquetas e possivelmente um modelo. As etiquetas são utilizadas para encaminhar notificações para o conjunto correto de alças do dispositivo. Para obter mais informações, consulte As Expressões de Encaminhamento e Etiqueta. Os modelos são usados para implementar a transformação por registo. Para obter mais informações, veja Templates (Modelos).

É importante notar que os registos são transitórios. À semelhança das alças de PNS que contêm, as inscrições caducam. Pode marcar a hora de viver para uma inscrição no Centro de Notificação, até um máximo de 90 dias. Este limite significa que devem ser regularmente atualizados e também que não devem ser o único depósito para informações importantes. Esta expiração automática também simplifica a limpeza quando a sua aplicação móvel é desinstalada.

As inscrições devem conter a pega PNS mais recente para cada dispositivo/canal. Como as pegas PNS só podem ser obtidas na aplicação do cliente no dispositivo, uma forma de gerir as inscrições está diretamente nessa aplicação do cliente. Por outro lado, considerações de segurança e lógica de negócio relacionadas com tags podem exigir que você gere o registo na app back-end. A secção seguinte descreve estas duas abordagens.

Gestão de Registos do Dispositivo

Ao gerir registos de aplicações de clientes, o backend é apenas responsável pelo envio de notificações. As aplicações do cliente mantêm as pegas do PNS atualizadas e registam-se nas etiquetas. A imagem a seguir ilustra este padrão.

O dispositivo recupera primeiro a pega PNS do PNS e depois regista-se diretamente com o centro de notificação. Após o sucesso do registo, o backend da aplicação pode enviar uma notificação direcionada para esse registo. Para obter mais informações sobre como enviar notificações, consulte As Expressões de Encaminhamento e Etiquetagem.

Note que, neste caso, utilizará apenas os direitos de escuta para aceder aos seus centros de notificação a partir do dispositivo. Para mais informações, consulte a Segurança.

O código que se segue regista o seu dispositivo utilizando referências API de Centros de Notificação:

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

Estes métodos criam ou atualizam um registo do dispositivo em que são chamados. Isto significa que, para atualizar o manípulo ou as etiquetas, deve substituir todo o registo. Lembre-se que as inscrições são transitórias, pelo que deve ter sempre uma loja fiável (seja o armazenamento local no dispositivo ou na parte traseira da sua aplicação) com as etiquetas atuais de que um dispositivo específico necessita. Consulte o tutorial de Notícias de Última Hora para obter exemplos mais detalhados de como atualizar as inscrições.

Também pode utilizar as APIs REST para se registarem a partir do dispositivo. Para mais informações, consulte Como Utilizar a Interface REST dos Centros de Notificação.

Os seguintes tutoriais de cenário fornecem orientação passo a passo sobre o registo do seu cliente:

• Introdução com centros de notificação

• Notícias de última hora

Modelos

Se quiser utilizar Modelos, cada registo representa um modelo individual. Isto significa que, se o seu dispositivo utilizar dois modelos, deve registar cada modelo de forma independente com o seu próprio cabo PNS e conjunto de etiquetas.

Para registos nativos (isto é, sem modelo), os métodos de registo dos modelos criam ou atualizam os registos existentes. Para direcionar diferentes modelos, você fornece um nome de modelo ao registar.. Irá fornecer nomes diferentes se pretender manter vários modelos para o mesmo dispositivo.

Importante

Ao utilizar modelos, não tem de registar o seu dispositivo como mostrado na secção anterior. Esse registo só é utilizado se enviar notificações nativas (notificações enviadas num formato específico da plataforma).

O código que se segue regista o seu dispositivo utilizando referências API de Centros de Notificação:

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

Note que cada chamada de registo fornece, além do manípulo PNS e do conjunto opcional de tags, um modelo para o corpo da notificação e um nome para o modelo. Além disso, cada plataforma pode ter propriedades adicionais que fazem parte do modelo. No caso de Windows Store (utilizando WNS) e Windows Phone 8 (utilizando MPNS), um conjunto adicional de cabeçalhos pode fazer parte do gabarito. No caso de APNs, você pode definir uma propriedade de validade para uma constante ou para uma expressão de modelo.

Para obter instruções sobre como modificar estes campos de modelo, consulte referências da API ou Centros de Notificação REST APIs.

Azulejos secundários para apps Windows Store

Para Windows aplicações de clientes da Loja, o envio de notificações para azulejos secundários é o mesmo que enviá-las para a primeira. Os registos nativos e de modelos são suportados. A única diferença é que os azulejos secundários têm um ChannelUri diferente, que o SDK na sua aplicação de cliente lida de forma transparente.

A um nível elevado, todas as informações fornecidas nas secções anteriores funcionam com azulejos secundários, chamando os métodos correspondentes sobre os objetos expostos na propriedade do dicionário Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles. Por exemplo:

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

O dicionário SecondaryTiles utiliza o mesmo TileId que é usado para criar o objeto SecondaryTiles na sua aplicação Windows Store.

Tal como acontece com o ChannelUri primário, os ChannelUris de azulejos secundários podem mudar a qualquer momento. Para manter os registos de aplicações do cliente atualizados no centro de notificação, o dispositivo deve atualizá-los com os atuais ChannelUris dos azulejos secundários.

Nota

Pode apagar azulejos secundários quando a aplicação está inativa. Os registos correspondentes não resultarão em notificações e serão automaticamente eliminados pelos centros de notificação.

Inconvenientes do Registo do Dispositivo

Registar-se no dispositivo é o método mais simples, mas tem algumas desvantagens.

A primeira desvantagem é que uma aplicação do cliente só pode atualizar as suas tags quando a aplicação está ativa. Por exemplo, se um utilizador tiver dois dispositivos que registam tags relacionadas com equipas desportivas, quando o primeiro dispositivo se regista para uma etiqueta adicional (por exemplo, Seahawks), o segundo dispositivo não receberá as notificações sobre os Seahawks até que a aplicação do segundo dispositivo seja executada uma segunda vez. De uma forma mais geral, quando as etiquetas são afetadas por vários dispositivos, gerir tags a partir do backend é uma opção desejável.

A segunda desvantagem da gestão do registo da aplicação do cliente é que, uma vez que as aplicações podem ser pirateadas, garantir o registo a etiquetas específicas requer cuidados extra, como explicado na secção "Segurança ao nível do tag".

Gestão de Registos a partir do Back-end app

A gestão dos registos a partir do backend requer a elaboração de código adicional. A aplicação do dispositivo deve fornecer o cabo PNS atualizado para o backend sempre que a aplicação começa (juntamente com tags e modelos), e o backend deve atualizar esta pega no Service Bus. A imagem a seguir ilustra este design.

As vantagens de gerir os registos a partir do backend são a capacidade de modificar tags para registos mesmo quando a aplicação correspondente no dispositivo está inativa, e de autenticar a app do cliente antes de adicionar uma etiqueta ao seu registo.

A partir do seu backend da aplicação, pode realizar operações básicas da CRUDS em registos. Por exemplo:

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

Também pode utilizar o Nó ou as APIs REST.

Importante

O backend deve lidar com a concordância entre as atualizações de registo. Service Bus oferece um controlo otimista de concordância para a gestão do registo. A nível HTTP, este é implementado com a utilização de ETag em operações de gestão de registos. Esta funcionalidade é utilizada de forma transparente pelos SDKs da Microsoft, que lançam uma exceção se uma atualização for rejeitada por razões de concordância. O backend da aplicação é responsável por lidar com estas exceções e tentar novamente a atualização, se necessário.

Recursos Adicionais

Os seguintes tutoriais de cenário fornecem orientação passo a passo sobre o registo a partir do back-end da sua aplicação:

• Utilize tags para enviar notificações a utilizadores autenticados

• Utilize modelos para enviar notificações de plataformas cruzadas a utilizadores autenticados