マルチモジュールアプリの画面遷移処理実装

by こやまカニ大好き

Slide 1

Slide 1 text

マルチモジュールアプリの画面遷移処理実装こやまカニ大好き

Slide 2

Slide 2 text

自己紹介こやまカニ大好きレシピサービス開発部所属モバイルアプリ開発の生産性を向上させるタスクに従事去年から WebView 大好き

Slide 3

Slide 3 text

今日のトピック ● クックパッドアプリの構成 ● クックパッドアプリの画面遷移実装 ● まとめ

Slide 4

Slide 4 text

クックパッドアプリの構成

Slide 5

Slide 5 text

クックパッドアプリの構成 ● マルチモジュールプロジェクト ○ 画面実装は View(Compose)と関連ロジックを Scene という単位で定義 ○ 関連のある複数 Scene で機能モジュール(feature module) を構成 ○ 共通ロジックやドメイン層は役割ごとにライブラリモジュール (library module)を構成 ● モジュール数は全体で 52 ○ 機能モジュール 21 ○ ライブラリモジュール 19 ○ そのほかは App モジュールや Demo モジュール

Slide 6

Slide 6 text

モジュール構成

Slide 7

Slide 7 text

画面遷移の実装 ● クックパッドアプリでは現在 Navigation Component 未使用 ● 今回お話するのは全て自作している画面遷移実装の話 ● Navigation Component 未使用の理由は主にタイミングの問題 ○ Navigation Component 登場時点でマルチモジュール化していたため、導入が難しかった ○ クックパッドアプリの画面遷移が複雑で利用できる箇所が限られていた ○ 特にボトムタブに Multiple Back Stacks 相当の実装を自前で入れていたので乗り換えが難しい状況だった

Slide 8

Slide 8 text

クックパッドアプリの画面遷移実装

Slide 9

Slide 9 text

モジュール間画面遷移の基本 ● 機能モジュールAは機能モジュールBを直接参照しない ○ もし参照しようとすると画面によってはモジュール同士の循環参照になってしまう ● 別モジュールの画面を生成するため、 navigation module に Factory を定義する ● 各画面は navigation module の Factory を経由して画面を生成し、遷移処理を実装する

Slide 10

Slide 10 text

モジュール間画面遷移の基本 FeatureA SceneA FeatureB SceneB :FeatureA:SceneA と :FeatureB:SceneB は相互に画面遷移したいお互いが見える状態にしようとすると :FeatureA と :FeatureB の循環参照になってしまう

Slide 11

Slide 11 text

モジュール間画面遷移の基本 FeatureA SceneA FeatureB SceneB Navigation DestinationFactory fun createSceneB() fun createSceneA() Navigation モジュールの DestinationFactory という interface を経由することにより、モジュールの循環参照を防ぐ

Slide 12

Slide 12 text

モジュール間画面遷移の基本 FeatureA SceneA FeatureB SceneB Navigation DestinationFactory fun createSceneB() Application DestinationFactoryImpl fun createSceneB() 実装 Application モジュールに DestinationFactory の実態があり、各Sceneのインスタンスを生成する Application モジュールは全てのモジュールを参照しているので全ての画面のインスタンスを生成可能

Slide 13

Slide 13 text

追加要求1 ボトムタブごとに画面遷移の履歴(Back Stacks) を切り替えられるようにしたい

Slide 14

Slide 14 text

Back Stacks の切り替え ● ボトムタブを切り替えた際、タブごとに Back Stacks を保存して切り替える機能 ○ いわゆる Multiple Back Stacks 相当の機能 ● PrimaryNavigationFragment という仕組みを使い、タブごとに FragmentManager を制御する Fragment を切り替えることで実現している ○ Activity と実際に表示する画面の間に Fragment 階層を一枚挟み、タブ切り替えを上位 Fragment の切り替えでやっているイメージ ○ back の挙動なども自動的に切り替えてくれる ○ 現在は FragmentManager に saveBackStack/restoreBackStack があるのでもう少しわかりやすい仕組みで切り替え可能

Slide 15

Slide 15 text

Back Stacks の切り替え ● requireActivity().supportFragmentManager を使う代わりに以下のような方法で FragmentManager を取り出すことで常にタブ挙動を考慮した画面遷移にできる

Slide 16

Slide 16 text

NavigationController の導入 ● 毎回　　　　　　　　　　　　　　　　の記述を書いていられないので、 NavigationController という仕組みを導入した ● アプリ内の画面遷移における共通処理を吸収するレイヤー ○ 処理対象の FragmentManager の選択 ○ replace 時の containerViewId 指定 ○ backstack の管理

Slide 17

Slide 17 text

NavigationController のコード(一部)

Slide 18

Slide 18 text

NavigationController の生成

Slide 19

Slide 19 text

NavigationController を使った画面遷移

Slide 20

Slide 20 text

追加要求2 条件によって遷移先が Fragment だったり Activity だったりする画面遷移を実装したい

Slide 21

Slide 21 text

遷移先がActivity/Fragmentで分岐 ● ユーザー状態などによって遷移先が変わるアクションが存在する ● ログイン済みの場合は目的の画面(Fragment)、未ログインの場合はログイン画面(Activity)という複雑なパターンも存在する

Slide 22

Slide 22 text

Destination の導入 ● Destination は遷移先(Fragment, DialogFragment, Intent)をラップする sealed class ● NavigationController が Destination への遷移をサポートすることで画面実装では遷移先が Fragment 、 DialogFragment 、 Intent のいずれであるのか考慮する必要がなくなった ○ Result を受け取るケースでは考慮する必要があるので Destination を使わない処理になっている

Slide 23

Slide 23 text

Destination の実装

Slide 24

Slide 24 text

NavigationController 側の処理

Slide 25

Slide 25 text

追加要求3 URLによる画面遷移処理を実装したい

Slide 26

Slide 26 text

URL による画面遷移処理 ● いわゆるディープリンク処理 ● 遷移先は Fragment だったり Activity だったり ● 外部からのアプリ起動、WebView内での遷移、APIレスポンスからのアクションなど様々な箇所で同じ挙動を実現したい

Slide 27

Slide 27 text

DestinationParams の導入 ● DestinaionParams は Destination を生成するための情報をまとめたもの ● URLから遷移先(Destination)の種別と必要なパラメータを抽出し、プロパティとして保持する ● DestinationParams の定義は sealed interface なため、when による分岐処理でパターン網羅しやすい

Slide 28

Slide 28 text

DestinationParams の実装

Slide 29

Slide 29 text

DestinationParams の利用ほとんどのケースで、以下のような実装だけで動作するようにしている

Slide 30

Slide 30 text

WebView における DestinationParams ● 去年の DroidKaigi で発表した時点では DestinationParams は存在していなかった ● 現在は WebView 内のURL解釈も DestinationParams で共通化しているため、 WebView画面で実装すべきメソッドは DestinationParams を渡して遷移するメソッドだけになった

Slide 31

Slide 31 text

WebView における DestinationParams

Slide 32

Slide 32 text

DestinationParams の機能ごとのタグづけ各 DestinationParams がサポートする機能ごとにタグづけを行なっている sealed interface は複数実装できるので、サポートする機能によって DestinationParams の sub interface をそれぞれ実装している例えば、ディープリンク関連の処理では DeepLinkSupportedDestinationParams だけを用いることで、 when 分岐の無駄な記述を減らすことができる

Slide 33

Slide 33 text

DestinationParams の機能ごとのタグづけ

Slide 34

Slide 34 text

まとめ

Slide 35

Slide 35 text

クックパッドアプリの画面遷移を支える自作コンポーネント ● DestinationParams ○ 遷移先と必要なパラメータをまとめた sealed interface ○ (理想的には)画面の数だけ DestinationParams が存在する ● Destination ○ 画面遷移に必要なFragmentやActivity(Intent) などの実態を抽象化する sealed class ○ (基本的には) Factory を経由して DestinationParams から生成される ● NavigationController ○ Destination による画面遷移をサポートする仕組み ○ Multiple Back Stacks などの実装を隠蔽し、各画面が意図している画面遷移実装に集中できるようにする

Slide 36

Slide 36 text

今後の課題 ● Jetpack Navigation Component を利用していないこと ● Navigation Component は必須ではないと感じているが、長期的なメンテナンスコストを考えると公式が推している仕組みに近づけた方が良さそう ● Navigation Component のマルチモジュールサポートは自作コンポーネントを完全に置き換えられないため、しばらくは自作した仕組みを Navigation Component に寄せやすくする改良をしていくかも ○ Navigation best practices for multi-module projects ○ モジュール間遷移がディープリンク前提、 SafeArgs 使えないという制約は結構辛い

Slide 37

Slide 37 text

おわり