Visão geral dos Serviços de Notificação por Push do Windows (WNS)

Visão geral dos Serviços de Notificação por Push do Windows (WNS) (aplicativos do Tempo de Execução do Windows)

[ Este artigo destina-se aos desenvolvedores do Windows 8.x e do Windows Phone 8.x que escrevem aplicativos do Windows Runtime. Se você estiver desenvolvendo para o Windows 10, consulte documentação mais recente]

Os WNS permitem que desenvolvedores terceirizados enviem atualizações do sistema, de blocos, de notificações e brutas pelo próprio serviço de nuvem. Isso proporciona um mecanismo para entregar novas atualizações aos usuários de forma eficaz e confiável.

Como funciona

O diagrama a seguir mostra o fluxo de dados completo envolvido no envio de uma notificação por push. Ele envolve estas etapas:

  1. O aplicativo envia uma solicitação para um canal de notificação por push para a Plataforma de Cliente de Notificações.
  2. A Plataforma de Cliente de Notificações pede ao WNS para criar um canal de notificações. Esse canal é retornado para o dispositivo de chamada sob a forma de um URI.
  3. O URI do canal de notificações é retornado pelo Windows para seu aplicativo.
  4. Seu aplicativo envia o URI para o seu próprio serviço de nuvem. Este mecanismo de retorno de chamada é uma interface entre seu próprio aplicativo e seu próprio serviço. É sua responsabilidade implementar esse retorno de chamada com os padrões seguros e protegidos da Web.
  5. Quando o serviço de nuvem tem uma atualização para envio, ele notifica o WNS usando o URI do canal. Isso é feito por meio da emissão de uma solicitação HTTP POST, incluindo a carga da notificação, sobre o protocolo SSL. Esta etapa requer autenticação.
  6. O WNS recebe a solicitação e encaminha a notificação para o dispositivo apropriado.

Registro, autenticação e fluxo de dados da notificação por push

Registrando seu aplicativo e recebendo as credenciais para o serviço na nuvem

Antes de enviar notificações usando o WNS, seu aplicativo deve ser registrado com o Painel da Windows Store. Isso lhe fornecerá credenciais para o aplicativo que serão usadas pelo serviço na nuvem para a autenticação no WNS. Essas credenciais consistem em um SID (Identificador de Segurança de Pacote) e uma chave secreta. Para realizar esse registro, vá para o Centro de Desenvolvimento do Windows e selecione Painel.

Cada aplicativo tem seu próprio conjunto de credenciais para seu serviço na nuvem. Essas credenciais não podem ser usadas para enviar notificações para qualquer outro aplicativo.

Para obter mais detalhes sobre como registrar seu aplicativo, veja o tópico sobre como autenticar no WNS (Serviço de Notificação do Windows).

Solicitando um canal de notificação

Quando um aplicativo que é capaz de receber notificações por push é executado, ele deve primeiro solicitar um canal de notificação por meio do CreatePushNotificationChannelForApplicationAsync. Para ver uma discussão completa e o exemplo de código, veja Como solicitar, criar e salvar um canal de notificação. Essa API retorna um URI de canal que está associado exclusivamente ao aplicativo de chamada e seu bloco e pelo qual todos os tipos de notificação podem ser enviados.

Depois o aplicativo cria com êxito um URI de canal, ele o envia para seu serviço na nuvem, juntamente com quaisquer metadados específicos ao aplicativo que devem ser associados a esse URI.

Observações importantes

  • Não podemos garantir que o URI do canal de notificação de um aplicativo permanecerá sempre o mesmo. Aconselhamos que o aplicativo solicite um novo canal a cada vez que for executado e atualize seu serviço quando o URI for alterado. O desenvolvedor nunca deve modificar o URI do canal e deve considerá-lo como uma cadeia de caracteres de caixa preta. Nesse momento, os URIs do canal expiram após 30 dias. Os aplicativos que renovam seus canais periodicamente em segundo plano podem seguir o padrão demonstrado no Exemplo de notificações por push e periódicas.
  • A interface entre o aplicativo da Windows Store e o serviço na nuvem é implementada por você, o desenvolvedor. Recomendamos que o aplicativo passe por um processo de autenticação com o seu próprio serviço e transmita dados por meio de um protocolo seguro, como HTTPS.
  • É importante que o serviço na nuvem sempre garanta que o URI do canal use o domínio "notify.windows.com". O serviço nunca deve enviar as notificações por push para um canal em algum outro domínio. Se o retorno de chamada para o aplicativo fosse comprometido, um invasor mal-intencionado poderia enviar um URI de canal para falsificar o WNS. Sem inspecionar o domínio, o serviço na nuvem poderia revelar as informações a este invasor de forma inconsciente.
  • Se o seu serviço na nuvem tentar entregar uma notificação para um canal expirado, o WNS retornará um código de resposta 410. Em resposta a esse código, seu serviço não deverá mais tentar enviar notificações a esse URI.

Autenticando seu serviço na nuvem

Para enviar uma notificação, o serviço na nuvem deve ser autenticado por meio do WNS. A primeira etapa neste processo ocorre quando você registra seu aplicativo com o Painel da Windows Store. Durante o processo de registro, o aplicativo recebe um SID (Identificador do Pacote de Segurança) e uma chave secreta. Estas informações são usadas pelo serviço na nuvem para autenticar no WNS.

O esquema de autenticação do WNS é implementado usando o perfil de credenciais de cliente do protocolo OAuth 2.0. O serviço na nuvem autentica no WNS fornecendo suas credenciais (SID do pacote e chave secreta). Em troca, ele recebe um token de acesso. Esse token de acesso permite que um serviço na nuvem envie uma notificação. O token é necessário a cada solicitação de notificação enviada para o WNS.

Um nível elevado, a cadeia de informações é a seguinte:

  1. O serviço na nuvem envia suas credenciais para o WNS sobre HTTPS seguindo o protocolo OAuth 2.0. Isso autentica o serviço no WNS.
  2. O WNS retorna um token de acesso quando a autenticação é bem-sucedida. Este token de acesso é usado nas solicitações de notificações subsequentes até expirar.

Comunicação do serviço na nuvem com o WNS

Na autenticação no WNS, o serviço na nuvem envia uma solicitação HTTP sobre o protocolo SSL. Os parâmetros são fornecidos no formato "application/x-www-for-urlencoded". Forneça seu SID de pacote no campo "client_id" e sua chave secreta no campo "client_secret". Para obter os detalhes da sintaxe, veja a referência para a solicitação de token de acesso.

Observação  Isso é apenas um exemplo, e não o código para copiar e colar que você pode usar com êxito em seu próprio código.
 

 POST /accesstoken.srf HTTP/1.1
 Content-Type: application/x-www-form-urlencoded
 Host: https://login.live.com
 Content-Length: 211
 
 grant_type=client_credentials&client_id=ms-app%3a%2f%2fS-1-15-2-2972962901-2322836549-3722629029-1345238579-3987825745-2155616079-650196962&client_secret=Vex8L9WOFZuj95euaLrvSH7XyoDhLJc7&scope=notify.windows.com

O WNS autentica o serviço na nuvem e, em caso de êxito, envia uma resposta de "200 OK". O token de acesso é retornado nos parâmetros incluídos no corpo da resposta HTTP, usando o tipo de mídia "application/json". Depois que o seu serviço recebe o token de acesso, você está pronto para enviar notificações.

O exemplo a seguir mostra uma resposta de autenticação bem-sucedida, incluindo o token de acesso. Para obter os detalhes da sintaxe, veja Cabeçalhos de solicitação e resposta do serviço de notificação por push.


 HTTP/1.1 200 OK   
 Cache-Control: no-store
 Content-Length: 422
 Content-Type: application/json
 
 {
     "access_token":"EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=", 
     "token_type":"bearer"
 }

Observações importantes

  • O protocolo OAuth 2.0 com suporte neste procedimento segue a versão de rascunho V16.
  • A RFC (Request for Comments) do OAuth usa o termo "client" para se referir ao serviço na nuvem.
  • Poderá haver alterações neste procedimento quando o rascunho do OAuth for finalizado.
  • O token de acesso pode ser reutilizado em várias solicitações de notificação. Isso permite que o serviço na nuvem autentique somente uma vez para enviar muitas notificações. No entanto, quando o token de acesso expira, o serviço na nuvem deve autenticar novamente para receber um novo token de acesso.

Enviando uma notificação

Usando o URI do canal, o serviço na nuvem pode enviar uma notificação sempre que tiver uma atualização para o usuário.

O token de acesso descrito acima pode ser reutilizado em várias solicitações de notificação; o servidor na nuvem não é necessário para solicitar um novo token de acesso para cada notificação. Se o token de acesso tiver expirado, a solicitação de notificação retornará um erro. Recomendamos que você não tente reenviar a notificação mais de uma vez se o token de acesso for rejeitado. Se você encontrar esse erro, precisará solicitar um novo token de acesso e reenviar a notificação. Para obter o código de erro exato, veja os códigos de resposta da notificação por push.

  1. O serviço na nuvem cria um HTTP POST para o URI do canal. Esta solicitação deve ser feita sobre SSL e contém os cabeçalhos e a carga de notificação necessárias. O cabeçalho de autorização deve incluir o símbolo de acesso obtido para a autorização.

    Um exemplo da solicitação é mostrado aqui: Para obter os detalhes da sintaxe, veja os códigos de resposta da notificação por push.

    Os detalhes sobre como compor a carga da notificação estão em Guia de início rápido: enviando uma notificação por push. A carga de uma notificação por push de bloco, do sistema ou de selo é apresentada como conteúdo XML que segue seus respectivos esquemas definidos. A carga de uma notificação bruta não tem uma estrutura especificada. Ela é estritamente definida pelo aplicativo.

    
     POST https://cloud.notify.windows.com/?token=AQE%bU%2fSjZOCvRjjpILow%3d%3d HTTP/1.1
     Content-Type: text/xml
     X-WNS-Type: wns/tile
     Authorization: Bearer EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=
     Host: cloud.notify.windows.com
     Content-Length: 24
    
     <body>
     ....
    
  2. O WNS responde para indicar que a notificação foi recebida e será entregue na próxima oportunidade disponível. No entanto, o WNS não fornece a confirmação completa de que a notificação foi recebida pelo dispositivo ou aplicativo.

A imagem a seguir ilustra este fluxo de dados.

Comunicação do serviço na nuvem com o WNS

Observações importantes

  • O WNS não garante a confiabilidade ou a latência de uma notificação.
  • As notificações nunca devem incluir dados confidenciais ou particulares.
  • Para enviar uma notificação, o serviço na nuvem deve primeiro autenticar no WNS e receber um token de acesso.
  • Um token de acesso permite que um serviço na nuvem envie notificações para apenas o único aplicativo para o qual o token foi criado. Um token de acesso não pode ser usado para enviar notificações entre vários aplicativos. Portanto, se o seu serviço na nuvem oferece suporte a vários apps, ele deverá fornecer o token de acesso correto para o aplicativo ao enviar uma notificação por push para cada URI de canal.
  • Quando o dispositivo está offline, o WNS armazena até cinco notificações de bloco (se a fila está habilitada; caso contrário, uma notificação de bloco) e uma notificação de selo para cada URI de canal e nenhuma notificação bruta. Esse comportamento padrão de armazenamento em cache pode ser alterado pelo cabeçalho X-WNS-Cache-Policy. Observe que as notificações do sistema nunca são armazenadas quando o dispositivo está offline.
  • Nos cenários onde o conteúdo da notificação é personalizado para o usuário, o WNS recomenda que o serviço na nuvem envie essas atualizações imediatamente quando elas são recebidas. Os exemplos desse cenários incluem as atualizações do feed de mídias sociais, os convites de comunicação instantânea, as notificações de novas mensagens ou os alertas. Como alternativa, você pode ter cenários onde a mesma atualização genérica frequentemente é fornecida a um grande subconjunto dos seus usuários. Por exemplo, atualizações de clima, cotações e notícias. As diretrizes do WNS especificam que a frequência dessas atualizações deve ser no máximo uma a cada 30 minutos. O usuário final ou o WNS pode determinar que as atualizações de rotina mais frequentes são abusivas.

Expiração de notificações de selo e bloco

Por padrão, as notificações de bloco e de selo expiram três dias depois que são baixadas. Quando uma notificação expira, o conteúdo é removido do bloco ou da fila e não é mais mostrado para o usuário. É recomendável definir uma expiração em todas as notificações de bloco e de selo usando um tempo que faça sentido para o aplicativo. Assim, você garante que o conteúdo do bloco não continue além do tempo relevante. Um tempo de expiração explícito é essencial para conteúdo com tempo de vida definido. Isso também garante a remoção de conteúdo obsoleto se seu serviço de nuvem parar de enviar notificações ou se o usuário se desconectar da rede por um período de tempo prolongado.

Seu serviço de nuvem pode definir uma expiração para cada notificação com a definição do cabeçalho HTTP X-WNS-Expires para especificar o tempo (em segundos) que sua notificação permanecerá válida após o envio. Para saber mais, veja Cabeçalhos de solicitação e resposta do serviço de notificação por push.

Por exemplo, durante um dia de negociação ativo do mercado de ações, você pode definir a expiração para uma atualização de preços de ações para duas vezes mais do que seu intervalo de envio (por exemplo, uma hora após o recebimento, se estiver enviando notificações a cada meia hora). Outro exemplo é um aplicativo de notícias que pode determinar que um dia é um período de expiração adequado para a atualização de blocos de notícias diárias.

Notificações por push e economia de bateria

A economia de bateria estende a vida útil da bateria, limitando a atividade em segundo plano no dispositivo. O Windows 10 e o Windows Phone 8.1 permitem que o usuário defina a ativação automática da economia de bateria quando a carga da bateria cair abaixo de um limite especificado. Quando a economia de bateria está ativada, o recebimento de notificações por push é desabilitado para economizar energia. Mas há algumas exceções para isso. As configurações de economia de bateria a seguir do Windows 10 (encontradas no aplicativo Configurações) permitem que o aplicativo receba notificações por push, mesmo quando a economia de bateria está ativada.

  • Permitir notificações por push de qualquer aplicativo em economia de bateria: esta configuração permite que todos os aplicativos recebam notificações por push enquanto a economia de bateria está ativada. Observe que a configuração se aplica somente ao Windows 10 para edições de área de trabalho (Home, Pro, Enterprise e Education).
  • Sempre permitido: esta configuração permite que aplicativos específicos sejam executados em segundo plano enquanto a economia de bateria está ativada, inclusive o recebimento de notificações por push. Essa lista é mantida manualmente pelo usuário.

Não há nenhuma maneira de se verificar o estado dessas duas configurações, mas você pode verificar o estado de economia de bateria. No Windows 10, use a propriedade EnergySaverStatus para verificar o estado de economia de bateria. O aplicativo também pode usar o evento EnergySaverStatusChanged para escutar alterações na economia de bateria. No Windows Phone 8.1, use PowerSavingModeEnabled para verificar o estado de economia de bateria.

Se o aplicativo depende muito de notificações por push, recomendamos notificar os usuários de que eles podem não receber notificações enquanto a economia de bateria estiver ativada e facilitar para que eles possam ajustar as configurações de economia de bateria. Usando o esquema de URI de configurações de economia de bateria no Windows 10, ms-settings:batterysaver-settings, você pode fornecer um link conveniente para o aplicativo Configurações.

Dica  Quando notificar o usuário sobre as configurações de economia de bateria, é recomendável fornecer uma maneira para suprimir a mensagem no futuro. Por exemplo, a caixa de seleção dontAskMeAgainBox no exemplo a seguir mantém a preferência do usuário em LocalSettings.
 

Veja um exemplo de como verificar se a economia de bateria está ativada no Windows 10. Este exemplo notifica o usuário e inicia o aplicativo Configurações para as configurações de economia de bateria. O dontAskAgainSetting permite que o usuário suprima a mensagem se ele não quiser ser notificado novamente.


using System;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Navigation;
using Windows.System;
using Windows.System.Power;
...
...
async public void CheckForEnergySaving()
{
   //Get reminder preference from LocalSettings
   bool dontAskAgain;
   var localSettings = Windows.Storage.ApplicationData.Current.LocalSettings;
   object dontAskSetting = localSettings.Values["dontAskAgainSetting"];
   if (dontAskSetting == null)
   {  // Setting does not exist
      dontAskAgain = false;
   }
   else
   {  // Retrieve setting value
      dontAskAgain = Convert.ToBoolean(dontAskSetting);
   }
   
   // Check if battery saver is on and that it's okay to raise dialog
   if ((PowerManager.EnergySaverStatus == EnergySaverStatus.On)
         && (dontAskAgain == false))
   {
      // Check dialog results
      ContentDialogResult dialogResult = await saveEnergyDialog.ShowAsync();
      if (dialogResult == ContentDialogResult.Primary)
      {
         // Launch battery saver settings (settings are available only when a battery is present)
         await Launcher.LaunchUriAsync(new Uri("ms-settings:batterysaver-settings"));
      }

      // Save reminder preference
      if (dontAskAgainBox.IsChecked == true)
      {  // Don't raise dialog again
         localSettings.Values["dontAskAgainSetting"] = "true";
      }
   }
}

Este é o XAML para a ContentDialog em destaque neste exemplo.


<ContentDialog x:Name="saveEnergyDialog"
               PrimaryButtonText="Open battery saver settings"
               SecondaryButtonText="Ignore"
               Title="Battery saver is on."> 
   <StackPanel>
      <TextBlock TextWrapping="WrapWholeWords">
         <LineBreak/><Run>Battery saver is on and you may 
          not receive push notifications.</Run><LineBreak/>
         <LineBreak/><Run>You can choose to allow this app to work normally
         while in battery saver, including receiving push notifications.</Run>
         <LineBreak/>
      </TextBlock>
      <CheckBox x:Name="dontAskAgainBox" Content="OK, got it."/>
   </StackPanel>
</ContentDialog>

Tópicos relacionados

Exemplo de notificações por push e periódicas
Início rápido: enviando uma notificação por push
Como atualizar uma notificação por meio de notificações por push
Como solicitar, criar e salvar um canal de notificação
Como interceptar notificações para aplicativos em execução
Como autenticar com o Serviço de Notificação por Push do Windows (WNS)
Cabeçalhos de solicitação e resposta de serviço de notificação por push
Diretrizes e lista de verificação de notificações por push
Notificações brutas

 

 

Mostrar:
© 2017 Microsoft