ディープリンク受信時の画面遷移

Status: Accepted

要約

ディープリンクを受信した際の画面遷移に関する仕様は以下とする
- 未認証時にディープリンクを受け取った場合は、ユーザが認証後、ディープリンクに対応した画面へ遷移させる
- ディープリンクの遷移先画面で戻るボタンをタップ場合は、ディープリンクをタップする前に表示していた画面に戻す
  - ただし、ボトムタブを表示しているナビゲーターなど、通常のユーザ操作では前の画面に戻れないナビゲーターなどに遷移している場合は、前の画面に戻さない
ディープリンクを受信した際の処理に、React Navigationのlinkingを使用せず、独自実装による画面遷移を採用する

このアプリでは、ディープリンクを受信した際、URLに応じた画面へ遷移させます。

しかし、URLと画面のマッピングの管理や、クエリパラメータの取得、認証状態を考慮した画面遷移など、開発する上で考慮すべき事がたくさんあります。

ここではそれらの課題を解決するための方法を検討します。

このアプリでは、ディープリンクを受信した際、URLに応じた画面へ遷移させます。しかし、認証状態に応じた画面表示や、遷移先画面で戻るボタンをタップした場合はどの画面を表示すべきかなど、いくつか検討すべき点がありました。

このアプリでは、認証状態によってユーザが閲覧可能な画面は異なります。ディープリンクに応じた遷移先画面が、未認証時に表示してはいけない画面である場合は、何もしない（ディープリンクに応じた画面へ遷移しない）ようにします。

次に、未認証時に受信したディープリンクの遷移先画面を、認証後に表示すべきかについて考えます。

認証後にディープリンクの遷移先画面を表示しないと、ユーザは本来到達したい画面に辿り着けない可能性があります。

また、辿り着けたとしても、ユーザ操作による画面遷移や再度ディープリンクをタップするなどの追加手順が必要だと、ユーザ体験としては好ましくありません。

そのため、未認証時に受け取ったディープリンクの遷移先画面を、認証後に表示します。

ディープリンクに応じた遷移先画面で戻るボタンをタップした場合の動作は、アプリによって様々です。このアプリでは、以下のような動作をすることがユーザにとって自然な動作であると考えました。

以下は、それぞれの方法における利点と注意事項をまとめた表になります。

実装方法	利点	注意事項
`linking`を使用	URLの解析や、URLと遷移先画面のマッピング定義による自動遷移など、多くの機能を提供してくれるため、開発が容易	・認証フローを考慮したドキュメントがない・デフォルトの画面遷移方法は、`navigation.navigate`と同様の動作になる・デフォルトの画面遷移方法を変更する手段はあるが、ドキュメントでは公開されてない関数を使う方法となる
独自実装	基本的に制限がなく、自由度が高い	・全てを自身で開発する必要があるので、`linking`に比べると開発コストは高い

linkingは、linkingのデフォルト動作に準拠した画面遷移の場合、開発も容易であり非常に有効な手段だと感じました。一方で、ディープリンクの遷移先画面からユーザが前に表示していた画面に戻るには、非公開の関数を使用しなくてはいけない場合があり、積極的に採用するには不安が残ります。

そのため、このアプリではlinkingを使用せず、独自実装による画面遷移を採用しました。

なお、それぞれの方法に関して検討した詳細は以下を参照してください。

ディープリンクを受信した際の画面遷移に関する仕様は以下とする
- 未認証時にディープリンクを受け取った場合は、ユーザが認証後、ディープリンクに対応した画面へ遷移させる
- ディープリンクの遷移先画面で戻るボタンをタップ場合は、ディープリンクをタップする前に表示していた画面に戻す
  - ただし、ボトムタブを表示しているナビゲーターなど、通常のユーザ操作では前の画面に戻れないナビゲーターなどに遷移している場合は、前の画面に戻さない
ディープリンクを受信した際の処理に、React Navigationのlinkingを使用せず、独自実装による画面遷移を採用する