Como Adicionar Notificações à Sua App: Na App, Email e Push

Para adicionar notificações a uma app web, comece pelas notificações na app: uma tabela de notificações na base de dados e um ícone de sino que mostra os itens não lidos. Acrescente o email para coisas que as pessoas precisam de saber quando estão longe, usando um fornecedor de email, e adicione o push web apenas quando os alertas em tempo útil forem importantes, uma vez que exige um service worker, a permissão do utilizador e, no iPhone, a app guardada no ecrã principal. Seja qual for o canal que usar, crie cada notificação num único ponto, no servidor, e deixe os utilizadores escolher o que querem receber.

Este guia compara os canais, mostra uma arquitetura simples e dá prompts que pode usar com um criador de apps com IA.

Os principais canais comparados

A maioria das apps precisa de na app mais email. O push e o SMS valem a pena quando o timing é mesmo importante, como um lembrete de marcação ou um pedido que já está pronto.

Como encaixa um sistema de notificações

Mantenha-o simples e centralizado:

1. Acontece algo. É publicado um comentário, um pagamento falha, uma marcação é amanhã.
2. O seu servidor chama uma única função, como notify(user, type, data).
3. Essa função verifica as preferências do utilizador e escreve uma linha na tabela notifications (para o sino).
4. Depois envia para os outros canais que o utilizador ativou para esse tipo: email através do seu fornecedor, push através da Push API.
5. O frontend mostra as notificações não lidas e marca-as como lidas quando são abertas.

Um único ponto de entrada permite acrescentar um canal, alterar o texto ou respeitar preferências sem andar a procurar pelo código.

O que guardar

Uma tabela de notificações precisa normalmente de: ID do utilizador, tipo (por exemplo comment_reply), um título e corpo curtos, uma ligação para a página relevante, a data de criação e a data de leitura. Uma tabela de preferências separada guarda os canais que cada utilizador quer para cada tipo.

Mostrar notificações novas

• Carregar ao abrir a página e consultar a cada 30–60 segundos. Simples e fiável.
• Atualizações em tempo real com WebSockets ou server-sent events parecem instantâneas, mas acrescentam peças em movimento. Comece com a consulta periódica, a não ser que as atualizações instantâneas sejam importantes.

Notificações por email

O email precisa de um fornecedor de envio e de um domínio verificado; os detalhes estão em como enviar emails a partir da sua app. Para notificações em particular:

• Envie a partir do servidor, nunca com uma chave do fornecedor no navegador.
• Agrupe os eventos repetitivos. «3 novos comentários» num só email é melhor do que três emails.
• Ofereça um resumo diário ou semanal para atividade de baixa prioridade.
• Inclua uma ligação para cancelar a subscrição ou gerir preferências em emails não essenciais. As regras sobre email de marketing variam de país; verifique o que se aplica a si.

Notificações push web

O push web permite que o seu site envie alertas que aparecem como notificações de app. Segundo a documentação da Push API na MDN, funciona assim:

1. O seu site regista um service worker, um script que o navegador pode executar em segundo plano.
2. Depois de o utilizador concordar, o service worker subscreve através de PushManager.subscribe(). O navegador devolve uma subscrição com um endpoint e chaves de encriptação.
3. O seu servidor guarda essa subscrição e, quando algo acontece, envia uma mensagem para o endpoint, normalmente assinada com chaves VAPID (um par de chaves que identifica o seu servidor).
4. O navegador arranca o seu service worker, que mostra a notificação, mesmo que a sua página não esteja aberta.

A MDN refere ainda que o endpoint deve ser mantido em segredo, porque basta conhecê-lo para enviar mensagens a esse utilizador.

iPhone e iPad

A WebKit acrescentou o Web Push para apps web no iOS e iPadOS 16.4, com duas condições do anúncio: o site tem de ser adicionado ao ecrã principal, e a permissão tem de ser pedida em resposta a uma ação do utilizador, como tocar num botão de Subscrever. Por isso, no iPhone, o push só chega aos utilizadores que instalaram a sua app web. Veja apps nativas vs. apps web progressivas para perceber o que significa instalar uma app web.

Pedir a permissão da forma certa

Não peça na primeira visita. Explique primeiro o benefício («Receba um lembrete uma hora antes da aula»), e mostre o pedido do navegador quando o utilizador tocar num botão. Se alguém recusar, o navegador pode não deixar voltar a pedir, por isso um pedido prematuro pode perder essa pessoa para sempre.

As notificações agendadas precisam de um gatilho

«Lembrete 24 horas antes» ou «resumo semanal todas as segundas» precisam de algo que corra de forma agendada. Isso é um problema de tarefas em segundo plano, abordado em como executar tarefas em segundo plano. Um padrão comum: um agendador externo chama um endpoint protegido a cada poucos minutos, e esse endpoint envia o que estiver pendente.

Prompts para dar ao seu criador com IA

Comece pelas notificações na app:

Adicione notificações na app. Crie uma tabela de notificações (utilizador, tipo, título, corpo, ligação, created_at, read_at). Adicione uma função de servidor notify(userId, type, data) que cada funcionalidade chama. Mostre um ícone de sino no cabeçalho com a contagem de não lidas, uma lista pendente com as últimas 20 e um botão «marcar todas como lidas». Consulte novas notificações a cada 60 segundos.

Depois, as preferências e o email:

Adicione definições de notificações: para cada tipo (respostas a comentários, menções, faturação), deixe o utilizador escolher na app, por email, ambos ou nenhum. O notify() tem de respeitar estas escolhas. Envie emails através de [FORNECEDOR] usando o segredo [NOME_DA_VARIÁVEL] apenas no servidor. Agrupe os emails de comentários para que um utilizador receba no máximo um email a cada 15 minutos.

Depois, o push, se precisar:

Adicione push web opcional. Registe um service worker, gere chaves VAPID e guarde a chave privada como segredo. Adicione um botão «Ativar notificações» nas definições que peça a permissão apenas quando for clicado. Guarde cada subscrição por utilizador e dispositivo, envie pushes a partir de notify() quando o utilizador tiver aderido, e apague as subscrições que o serviço de push indicar como expiradas.

Erros comuns

• Notificações espalhadas pelo código. Cada funcionalidade envia o seu próprio email de forma diferente, e as preferências são ignoradas. Use uma única função notify().
• Pedir a permissão de push ao carregar a página. A maioria das pessoas recusa, e pode não haver outra oportunidade.
• Não ter preferências. Quem não consegue desligar alertas incomodativos desliga-os todos, ou abandona a app.
• Enviar a partir do navegador. As chaves de email e de push pertencem ao servidor.
• Não limpar subscrições de push mortas. As subscrições expiradas acumulam-se e desperdiçam envios.
• Detalhes sensíveis no texto da notificação. Os ecrãs de bloqueio mostram-no. «Tem uma nova mensagem» é mais seguro do que a própria mensagem.
• Nenhum registo do que foi enviado. Quando um utilizador diz «nunca recebi o email», os registos com os IDs de mensagem do fornecedor ajudam a descobrir o motivo.

Lista de verificação

• Uma função notify() no servidor usada em todo o lado
• Tabela de notificações com estado de leitura, e um sino com contagem de não lidas
• Preferências por tipo e por canal, respeitadas por notify()
• Email enviado a partir do servidor com um domínio verificado; resumo ou agrupamento para eventos repetitivos
• Permissão de push pedida apenas após uma ação do utilizador, com uma explicação
• Push testado no computador e num iPhone com a app adicionada ao ecrã principal
• Subscrições de push expiradas removidas
• Nenhum conteúdo sensível nas pré-visualizações de push ou email
• Os lembretes agendados têm um gatilho fiável

Notificações na Mythex

A Mythex não inclui um serviço de email ou de push integrado para as apps que cria, por isso traz o seu próprio fornecedor de email e gera as suas próprias chaves de push, guardadas como segredos do projeto. A parte na app só precisa da base de dados do projeto, que a Mythex acrescenta quando a pede. Construa com prompts como os acima, teste o sino e os emails em Preview, e teste o push no seu URL publicado, porque os service workers e o push precisam de um endereço HTTPS real. A receita da documentação Enviar email a partir da sua app tem um prompt inicial. A Mythex não documenta tarefas agendadas, por isso planeie os lembretes temporizados com um gatilho externo, como descrito em como executar tarefas em segundo plano.

Perguntas