1
crdornelles
1 min de leitura ·

Deep Links no Android com Kotlin: intent-filter, MethodChannel e EventChannel — sem pacote (Parte 2)

Seguindo a série que estou fazendo sobre deep links em Flutter, no Post 2 fui direto no ponto: implementei tudo no Android usando só código nativo.

Sem uni_links.
Sem go_router.

A maioria dos exemplos que a gente encontra resolve com pacote.

Funciona.

Mas quando quebra em produção, você não sabe se o problema está:

  • no Android (intent-filter)
  • no domínio (App Links)
  • no Flutter (channel)
  • ou no próprio link

E aí vira tentativa e erro.

Nesse post implementei:

  • intent-filter no AndroidManifest.xml

    • custom scheme (fitconnect://)
    • HTTPS (App Links)
    • uso de autoVerify="true"

  • MainActivity.kt

    • MethodChannel → recuperar link no cold start
    • EventChannel → receber link com app aberto
    • tratamento de onCreate vs onNewIntent

  • evitar duplicação de eventos

    • dependendo do device o mesmo link chega duas vezes

  • testes com adb

    adb shell am start -a android.intent.action.VIEW \
      -d "fitconnect://fitconnect.app/signup?referralCode=123"

Coisas que quebram fácil

  • esquecer BROWSABLE
  • não tratar onNewIntent
  • autoVerify sem configuração no domínio
  • mismatch de host/path no manifest

Insight

Deep link não é só abrir uma tela.

Você está lidando com:

  • sistema operacional
  • lifecycle da Activity
  • bridge nativo ↔ Flutter
  • estado do app

Se você não entende isso, debug vira tentativa e erro.

Fonte (post completo no Medium)

https://medium.com/p/562bb353b3b2?postPublishedType=initial

Repo:
https://github.com/crdornelles/fit_connect

Se alguém já sofreu com App Links ou autoVerify, queria ouvir como resolveu — principalmente em casos que abre o seletor em vez do app.

Carregando publicação patrocinada...