Deep links: abra a tela certa a partir de um convite

O desafio de deep links

Um convite para acompanhar um pedido perde valor quando abre apenas a tela inicial. Deep links conectam um endereço a um destino específico do aplicativo, mas o percurso envolve situações diferentes: app instalado, sessão expirada, registro removido e sistema que abre o navegador. Cada condição precisa de uma resposta definida.

Como organizar links de aplicativo

Modele o endereço como entrada de uma tarefa, com identificador do destino e regras de autorização. A documentação do Android distingue mecanismos de links e verificação de associação. O desenho funcional deve existir antes da configuração técnica, porque o endereço por si só não garante que a pessoa possa acessar o conteúdo.

1. Mapeie o destino, os parâmetros necessários e as condições de acesso ao registro.
2. Preserve a intenção de navegação durante o login, sem expor informação antes da autorização.
3. Defina uma página de fallback e uma resposta para conteúdo removido ou indisponível.

O endereço precisa permitir reconstruir a tela sem depender de memória de navegação. Abrir uma atividade por convite pode ocorrer sem que a pessoa tenha visitado antes a lista do curso. O aplicativo deve obter os dados necessários e montar um caminho de retorno coerente. Documente quais parâmetros são obrigatórios, quais são opcionais e o que acontece quando o formato recebido não é reconhecido pela versão instalada.

Exemplo aplicado: destino do convite

Exemplo hipotético: uma escola de idiomas envia um convite para visualizar uma atividade. Com o app instalado e a sessão válida, o link abre a atividade. Se for preciso entrar na conta, o destino é retomado depois. Quem usa o navegador recebe uma página explicativa com opções coerentes com o serviço.

A navegação não deve aceitar qualquer identificador como autorização. O servidor verifica se a conta pode consultar a atividade, mesmo quando o link parece legítimo.

No retorno após o login, não confie em qualquer destino recebido como se fosse uma instrução interna válida. Restrinja os caminhos permitidos e confira os parâmetros antes de usá-los. A autorização ocorre novamente quando o conteúdo é consultado. Se a conta escolhida não tiver acesso, explique a situação e permita trocar de conta ou voltar, evitando um ciclo que solicita identificação repetidamente sem mostrar por que ela não resolveu.

Critérios para fallback mobile

Escolha destinos estáveis e suficientes para reconstruir a intenção. Evite depender de uma sequência prévia de telas ou guardar informação sensível diretamente no endereço compartilhável.

Testar apenas com o app já aberto esconde problemas de inicialização. Outro erro é perder os parâmetros ao autenticar, deixando a pessoa na página inicial após concluir o login.

Também é necessário planejar destinos antigos. Uma atividade pode ter sido arquivada ou um convite pode ter perdido validade. Em vez de abrir uma tela vazia, apresente a condição encontrada e uma alternativa relacionada à intenção inicial. Para verificar a integração, use o link completo recebido pelos canais reais do produto e observe redirecionamentos e parâmetros. Um endereço digitado manualmente dentro do app não representa todos os passos do percurso externo.

Acompanhamento de navegação com login

Acompanhe aberturas por destino, falhas de resolução e tarefas concluídas após autenticação. Separe o clique recebido do acesso efetivamente autorizado para interpretar o percurso com precisão.

Crie uma matriz com app aberto, app fechado, ausência de instalação e sessão expirada, e percorra cada cenário usando o mesmo convite.