Escolhendo o tipo de canal de notificação por push correto

Este artigo aborda os três tipos de canais de notificações push do Windows (primário, secundário e alternativo) que o ajudam a entregar conteúdo para a sua aplicação.

(Para detalhes sobre como criar notificações push, consulte a visão geral dos Serviços de Notificações Push (WNS) Windows.)

Tipos de canais push

Existem três tipos de canais push que podem ser usados para enviar notificações a uma aplicação Windows. Eles são:

Canal primário - o canal de envio "tradicional". Pode ser usado por qualquer aplicação na loja de aplicações para enviar notificações de toast, mosaico, raw ou ícone. Saiba mais aqui.

Canal de mosaico secundário - utilizado para enviar atualizações de mosaico para um mosaico secundário. Só pode ser usado para enviar notificações de bloco ou emblema para um bloco secundário fixado no ecrã inicial do utilizador

Canal alternativo - Não é mais suportado - Um novo tipo de canal adicionado na Atualização para criadores. Permite que notificações brutas sejam enviadas para qualquer aplicação do Windows, incluindo aquelas que não estão registadas na Loja. Novamente, observe que o canal alternativo não é mais suportado.

Note

Não importa qual canal de push o utilizador use, uma vez que a aplicação esteja a correr no dispositivo, poderá sempre enviar notificações locais de toast, azulejo, ou símbolo. Ele pode enviar notificações locais dos processos do aplicativo em primeiro plano ou de uma tarefa em segundo plano.

Canais principais

Estes são os canais mais usados no Windows neste momento, e são bons para quase qualquer cenário em que a sua aplicação seja distribuída pela Microsoft Store. Eles permitem que você envie todos os tipos de notificações para o aplicativo.

O que os canais principais permitem?

  • Enviar atualizações de bloco ou emblema para o bloco principal. Se o utilizador tiver optado por fixar o seu mosaico no ecrã inicial, esta é a sua oportunidade de se mostrar. Envie atualizações com informações úteis ou lembretes de experiências dentro do seu aplicativo.
  • Envio de notificações 'toast'. As notificações flutuantes são uma oportunidade para apresentar informações ao utilizador imediatamente. Eles são renderizados pelo shell sobre a maioria dos aplicativos e residem na central de ações para que o utilizador possa voltar e interagir com eles mais tarde.
  • Envio de notificações brutas para disparar uma tarefa em segundo plano. Às vezes, você deseja fazer algum trabalho em nome do usuário com base em uma notificação. As notificações brutas permitem que as tarefas em segundo plano do seu aplicativo sejam executadas
  • Encriptação de mensagens em trânsito fornecida pelo Windows usando TLS. As mensagens são criptografadas no fio, tanto entrando no WNS quanto indo para o dispositivo do usuário.

Limitações dos canais primários

  • Requer o uso da API REST WNS para enviar notificações, o que não é padrão entre os fornecedores de dispositivos.
  • Apenas um canal pode ser criado por aplicativo
  • Exige que a tua aplicação esteja registada na Microsoft Store

Criando um canal principal

PushNotificationChannel channel = 
	await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

Canais de mosaico secundários

Esses são canais que podem ser utilizados para enviar atualizações de bloco e ícone para um bloco secundário. Eles são usados por aplicativos para notificar os usuários sobre ações ou informações interessantes com as quais eles podem interagir no aplicativo, como novas mensagens em um bate-papo em grupo ou uma pontuação esportiva atualizada.

O que permitem os canais de blocos secundários?

  • Envio de notificações de bloco ou emblema para blocos secundários. Os blocos secundários são uma ótima maneira de atrair os usuários de volta para seu aplicativo. Eles são um link profundo para informações com as quais eles se importam, e colocar informações relevantes nos blocos ajuda a trazê-los de volta e de novo.
  • Separação de canais (e expirações) entre vários blocos. Isso permite separar a lógica no back-end entre os vários tipos de blocos secundários que um usuário pode fixar na tela inicial.
  • Encriptação de mensagens em trânsito fornecida pelo Windows usando TLS. As mensagens são criptografadas no fio, tanto entrando no WNS quanto indo para o dispositivo do usuário.

Limitações dos canais de mosaico secundários

  • Não são permitidas notificações toast ou não processadas. As notificações de 'toast' ou brutas enviadas para um tile secundário são ignoradas pelo sistema.
  • Exige que a tua aplicação esteja registada na Microsoft Store

Criação de um canal de tile secundário

PushNotificationChannel channel = 
	await PushNotificationChannelManager.CreatePushNotificationChannelForSecondaryTileAsync(tileId);

Canais alternativos

Canais alternativos permitem que as aplicações enviem notificações push sem se registarem na Microsoft Store ou criarem canais push fora do principal utilizado na aplicação.

Note

A partir de 1 de julho de 2021, as aplicações que queiram usar o canal web push ou o canal alternativo para enviar notificações baseadas no navegador através do WNS terão de ser integradas na Microsoft Store.

O que os canais alternativos permitem?

  • Envie notificações push brutas para um Windows a correr em qualquer dispositivo Windows. Os canais alternativos só permitem notificações brutas (no entanto, você ainda pode ativar uma tarefa em segundo plano para mostrar localmente notificações do sistema ou de bloco).
  • Permite que os aplicativos criem vários canais de push brutos para diferentes recursos dentro do aplicativo. Um aplicativo pode criar até 1000 canais alternativos, e cada um é válido por 30 dias. Cada um desses canais pode ser gerenciado ou revogado separadamente pelo aplicativo.
  • Canais alternativos de push podem ser criados sem necessidade de registar uma aplicação na Microsoft Store. Se a sua aplicação for instalada em dispositivos sem a registar na Microsoft Store, continuará a conseguir receber notificações push.
  • Os servidores podem enviar notificações por push usando as APIs REST padrão do W3C e o protocolo VAVID. Canais alternativos usam o protocolo padrão W3C, isso permite simplificar a lógica do servidor que precisa ser mantida.
  • Encriptação de mensagens completa, de ponta a ponta. Embora o canal principal forneça criptografia durante o trânsito, se você quiser ser mais seguro, os canais alternativos permitem que seu aplicativo passe por cabeçalhos de criptografia para proteger uma mensagem.

Limitações de canais alternativos

  • O servidor da sua aplicação não consegue enviar notificações do tipo 'toast', bloco ou emblema. Você só pode enviar notificações push raw. Seu aplicativo ainda pode enviar notificações locais de sua tarefa em segundo plano.
  • Requer uma API REST distinta dos canais de 'tiles' primários ou secundários. Usar a API REST padrão do W3C significa que o seu aplicativo precisará ter uma lógica diferente para enviar notificações pop-up ou atualizações de blocos por push.

Criando um canal alternativo

PushNotificationChannel webChannel = 
	await PushNotificationChannelManager.GetDefault().CreateRawPushNotificationChannelWithAlternateKeyForApplicationAsync(applicationServerKey, appChannelId);

Comparação do tipo de canal

Aqui está uma rápida comparação entre os diferentes tipos de canais:

Type Empurrar torradas? Publicar bloco/emblema? Enviar notificações brutas? Authentication API É necessário registar-se na loja? Channels Encryption
Primary Yes Sim - apenas bloco principal Yes OAuth WNS REST API Yes Um por aplicação Em trânsito
Peça Secundária No Sim - apenas mosaico secundário No OAuth WNS REST API Yes Um por tile secundário Em trânsito
Alternate No No Yes VAPID Padrão WebPush W3C No 1.000 por aplicativo Em trânsito + criptografia de ponta a ponta possível com passagem de cabeçalho (requer código do aplicativo)

Escolher o canal certo

Em geral, recomendamos o uso do canal principal em seu aplicativo, com algumas exceções:

  1. Se você estiver enviando uma atualização de bloco para um bloco secundário, use o canal de envio de bloco secundário.
  2. Se você estiver passando canais para outros serviços (como no caso de um navegador), use o canal alternativo.
  3. Se estiver a criar uma aplicação que não será listada na loja Windows (como uma aplicação LOB), use um canal alternativo.
  4. Se você tiver um código web push existente em seu servidor que deseja reutilizar ou tiver a necessidade de vários canais em seu serviço de back-end, use canais alternativos.