[メモ]URLスキームの画面遷移を考える

作成日
Aug 5, 2021 3:58 PM

目的

アプリの起動・非起動時に関わらずURLによって定められた画面を表示する

Optional

画面遷移は正しく行われており、通常のフローで戻ることができる

URLの遷移元

他のアプリ・ブラウザ

遷移先のアプリが遷移元になるケースもある

これはつまり

基本的には現在ユーザーが見ているコンテンツと異なるコンテキストの画面遷移が行われる

似てるもの

Push通知をタップした時の遷移

  • ライブ開始の通知とか

どうすればいい?

アプリが今のコンテキストを理解している必要がある。

そのコンテキストの延長線上にあるのか、否かを判断する必要がある

延長線上にあるのであれば、今のコンテキストから遷移する

そうでないなら、今のコンテキストを終了し再遷移する

遷移コンテキストの性質

今のコンテキストの性質

遷移コンテキストを遷移できるか

  • できる
    • すぐできる
      • 今の延長線上の遷移でできる
      • モーダルで出せる
      • 別タブに移動するだけでできる(コンテキストを破壊しない)
    • 条件付きでできる
      • 戻る必要がある
      • 認証後にできる
  • 出来ない
    • 不正なもの
    • 権限が足りない

すぐ遷移できるものをURLスキームで対応する

後でできるものは別の機構を用意する

アプリ起動時

現在見ている画面から遷移するのか、遷移情報を破壊するのか

→ Tab, Navigationの根本による気がする

  1. 非破壊で遷移出来ない限りは確認を出す
    1. 確認を出す必要のある画面か否か
      1. 編集中なら勝手に戻ってはいけない
      2. 設定画面開いている程度なら戻って良い
      3. 他人のプロフィール見ているときは?
        1. ユーザーの状態によって異なるケースはある
  2. 非破壊が起こらない画面遷移の設計を行う
    1. 無理

別のコンテキストか否かを見極める

  • 別のコンテキストであれば、Tab, Modalのような遷移
  • 同じコンテキストであれば、pushのような遷移

これは画面(View)ごとが知りうる情報

onOpenURLが叩かれたときに、画面はどうするのか決める。

子Viewは?

取り方

onOpenURLで取れる

複数のViewからも取れる

認証あるなし

→ どこかに保持しておく必要がある

onOpenURLの中で生成したViewではonOpenURLは呼ばれない

一気にstateを構築するのはありか

認証問題がある