お仕事でDeepLink対応をおこなったので、自分なり備忘録を残します。
今回は、既存のandroid・iOS 両方のアプリで、
「LINE上のURLをタップすると、アプリの特定の画面に遷移させたい」という要件がありました。
今回は実現するための手法を1から検討し、実現性の検証を行いました。
LINE上のURLはすでにバックエンドサーバが稼働していたため、
バックエンド側の修正工数も考慮する必要がありました。
（ただし、修正不可ではなく、運用コストも含めて総合的に判断という温度感でした）
また、バックエンドサーバの仕様として、
画面遷移のためにユーザIDのようなものをパラメータに含め、
アプリはそれを読み取らなければいけないという設計上の制約がありました。
例) https://example.com/transition/detail?userId=xxx
調べたもの
- カスタムスキーマ
- Universal Link & Android App Link
- Firebase Dynamic Link
解説はこの記事がわかりやすかったです。あとは公式を...
https://qiita.com/y-some/items/e0e0f5cb4d7d5559b09c
カスタムスキーマについてはLINEでサポートをしておらず（セキュリティ事件もあったので、一応方法はありそう）、対象外。
Firebase Dynamic LinkはuserIdを毎回パラメータに付与するという要件に適用せず、除外。
（1日に発行できる回数に引っかかる恐れがある、そもそもuserIdのような可変のパラメータは向かなそう）
Universal Link & Android App Link を使用することにしました。
Universal Link は サーバ上のファイルでURLの定義と挙動を決める。
Android App Link は アプリのintent-filterでURLの定義と挙動を決める。
iOSとandroidの実装差分では、この部分が大きな差かな、と思います。
あとはAndroid App Link の方が制約が厳しいので、寄せるならAndroid App Linkから寄せる方が良い。
まとめ
今回は、Universal Link & Android App Link を採用しました。
よりモダンで簡単そうなのがFirebase Dynamic Link だったのですが、
今回のアーキテクチャの最適解は選んだ方だと思ったので、良い判断ができたと思いました。
Firebaseになじみがあったので、Firebaseから選定しましたが、
他にも選択肢はあったかもしれません。
今回は時間的に選択肢を広げても調査・検証しきれないな...と思いましたが、
最適を見つけるために常にアンテナを張るべきだな..とも思いました。