Web Redirect para Deep Links: a ponte entre o link e a loja (Parte 7)
Nos primeiros posts da série definimos a estrutura base em Dart (Post 1), implementamos a captura nativa no Android (Post 2) e no iOS (Post 3), e conectamos tudo ao Flutter com DeepLinkService, MethodChannel e EventChannel (Post 4). No Post 5, publicamos os arquivos de verificação em deeplinkslab.dev — App Links e Universal Links funcionando em produção. No Post 6, resolvemos o caso do usuário que ainda não tem o app: como salvar o referralCode antes da instalação e recuperá-lo no primeiro launch.
Falta uma peça: quem salva esse código antes de redirecionar para a loja?
Continuando a série. Esse post é sobre o que acontece quando o usuário clica no link e não tem o app.
Sem tratamento: erro 404. O referralCode some. A conversão não acontece.
A solução é uma página HTML que faz tudo:
- Extrai o
referralCodeda URL - Detecta plataforma (Android / iOS / Desktop)
- Salva o código em
localStorage(backup para o Post 6) - Tenta abrir o app via custom scheme (
fitconnect://) - Aguarda 2 segundos
- Se o app não abriu → redireciona para Play Store ou App Store
function attemptToOpenApp() {
window.location = `fitconnect://deeplinkslab.dev/signup?referralCode=${affiliateCode}`;
setTimeout(() => {
redirectToStore(); // app não respondeu em 2s
}, 2000);
document.addEventListener('visibilitychange', () => {
if (document.hidden) clearTimeout(); // app abriu, cancela redirect
});
}
Por que setTimeout(2000)?
Não existe evento nativo para detectar se o custom scheme abriu o app. O timeout de 2s é a heurística padrão: se o app abrir, a página vai para segundo plano e o redirect não dispara.
Deploy
- Nginx: arquivo estático, zero backend
- Node.js/Express: se precisar de detecção server-side
- Firebase Hosting / Vercel: opção mais simples para começar
Fonte (post completo no Medium)
https://medium.com/p/5c02770e6454?postPublishedType=initial
Alguém tem esse funil mapeado? Do clique no link até o cadastro concluído?
Curiosidade sobre como a galera mede isso.