AULA 16 / 30 · Implementação e consentimento
React Native: destino após instalação Android
Entenda o que getDeferredDestination faz e o que não faz.
Guia baseado em documentação e PRs consultados. SDKs/API citados ainda têm alterações em draft; confirmar release e homologação.
Ver implementação e critérios de aceite →Mudança em revisão
O PR RN #1 está aberto e draft. Filtra first_open de versões nativas legadas e acrescenta políticas explícitas. No Android lê bridgee_link do Install Referrer com timeout e retorno nulo em falha.
Destino validado
getDeferredDestination consulta um endpoint fixo do Dashboard e aceita somente destinos no prefixo de organização e origens HTTPS configuradas. Essa verificação reduz o risco de navegação para URL arbitrária recuperada de um referrer.
O app continua responsável
A função não navega automaticamente e não emite uma instalação. No iOS retorna nulo nesse contrato. O app deve tratar ausência, erro e destino válido, aplicar sua navegação e manter consentimento explícito.
Homologue a instalação real
TypeScript, build JS e testes de bridge não comprovam o módulo nativo na loja. Teste Android em aparelho com Install Referrer e destino específico. Registre app, versão do SDK, organização, link e resultado esperado.
CONTRATO / EXEMPLO
Política no PR RN #1 · revisar o pin do consumidor
// Integração ilustrativa: bridgee e matchBundle já devem estar configurados.
const result = await bridgee.firstOpenWithConsent(matchBundle, {
consentGranted: consentFromCmp,
preserveNativeGoogleAttribution: nativeGooglePolicy,
});
// Nenhuma das decisões de consentimento deve ser presumida como true.Confirme versão, ambiente e políticas na documentação vinculada. Exemplos não ativam coleta ou produção.
SUA VEZ
Leve a aula para a prática
Escreva a ação do app para destino válido, nulo e rejeitado. Não execute URLs fora da origem homologada.
Baixar checklist de homologação ↓Confira o aprendizado
Documentação e evidências
Consultadas em 03/10/2026. Os exercícios e números desta aula são fictícios.