Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチモジュールアプリの画面遷移処理実装
Search
こやまカニ大好き
October 28, 2022
Programming
0
6.2k
マルチモジュールアプリの画面遷移処理実装
After Party DroidKaigi 2022 で発表したスライドです。
https://cookpad.connpass.com/event/260672/
こやまカニ大好き
October 28, 2022
Tweet
Share
More Decks by こやまカニ大好き
See All by こやまカニ大好き
Androidアプリの One Experience リリース
nein37
0
97
クックパッド Android アプリのマルチモジュール化とデモアプリの活用
nein37
1
6.7k
2020年代の WebView 実装 / saikou_no_webview_2021
nein37
2
11k
Androidアプリをいつまでも楽しく開発し続けるための取り組み
nein37
5
2.5k
minSdkVersion=21にしてから1年経った話
nein37
8
2.2k
Androidアプリエンジニアの基礎知識
nein37
16
11k
クックパッドアプリのマルチモジュール化への取り組み
nein37
11
10k
Android のセキュリティよくなってきた話
nein37
3
2.4k
Androidアプリのデザイン整理への取り組み
nein37
1
970
Other Decks in Programming
See All in Programming
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
8
1.9k
PHPで学ぶプログラミングの教訓 / Lessons in Programming Learned through PHP
nrslib
4
390
CQRS+ES の力を使って効果を感じる / Feel the effects of using the power of CQRS+ES
seike460
PRO
0
160
iOS開発におけるCopilot For XcodeとCode Completion / copilot for xcode
fuyan777
1
110
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
150
Асинхронность неизбежна: как мы проектировали сервис уведомлений
lamodatech
0
970
Semantic Kernelのネイティブプラグインで知識拡張をしてみる
tomokusaba
0
180
フロントエンドのディレクトリ構成どうしてる? Feature-Sliced Design 導入体験談
osakatechlab
8
4.1k
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
3
750
nekko cloudにおけるProxmox VE利用事例
irumaru
3
460
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
960
Fibonacci Function Gallery - Part 1
philipschwarz
PRO
0
230
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Side Projects
sachag
452
42k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
We Have a Design System, Now What?
morganepeng
51
7.3k
Speed Design
sergeychernyshev
25
670
Practical Orchestrator
shlominoach
186
10k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
170
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Transcript
マルチモジュールアプリの画 面遷移処理実装 こやまカニ大好き
自己紹介 こやまカニ大好き レシピサービス開発部 所属 モバイルアプリ開発の生産性を向上させ るタスクに従事 去年から WebView 大好き
今日のトピック • クックパッドアプリの構成 • クックパッドアプリの画面遷移実装 • まとめ
クックパッドアプリの構成
クックパッドアプリの構成 • マルチモジュールプロジェクト ◦ 画面実装は View(Compose)と関連ロジックを Scene という単位で定義 ◦ 関連のある複数
Scene で機能モジュール(feature module) を構成 ◦ 共通ロジックやドメイン層は役割ごとにライブラリモジュール (library module)を構成 • モジュール数は全体で 52 ◦ 機能モジュール 21 ◦ ライブラリモジュール 19 ◦ そのほかは App モジュールや Demo モジュール
モジュール構成
画面遷移の実装 • クックパッドアプリでは現在 Navigation Component 未使用 • 今回お話するのは全て自作している画面遷移実装の話 • Navigation
Component 未使用の理由は主にタイミングの問題 ◦ Navigation Component 登場時点でマルチモジュール化していたため、導入が難しかった ◦ クックパッドアプリの画面遷移が複雑で利用できる箇所が限られていた ◦ 特にボトムタブに Multiple Back Stacks 相当の実装を自前で入れていたので乗り換えが難し い状況だった
クックパッドアプリの 画面遷移実装
モジュール間画面遷移の基本 • 機能モジュールAは機能モジュールBを直接参照しない ◦ もし参照しようとすると画面によってはモジュール同士の循環参照になってしまう • 別モジュールの画面を生成するため、 navigation module に
Factory を定義す る • 各画面は navigation module の Factory を経由して画面を生成し、遷移処理を 実装する
モジュール間画面遷移の基本 FeatureA SceneA FeatureB SceneB :FeatureA:SceneA と :FeatureB:SceneB は相互に画面 遷移したい
お互いが見える状態にしようとする と :FeatureA と :FeatureB の循環 参照になってしまう
モジュール間画面遷移の基本 FeatureA SceneA FeatureB SceneB Navigation DestinationFactory fun createSceneB() fun
createSceneA() Navigation モジュールの DestinationFactory という interface を経由することにより、モジュール の循環参照を防ぐ
モジュール間画面遷移の基本 FeatureA SceneA FeatureB SceneB Navigation DestinationFactory fun createSceneB() Application
DestinationFactoryImpl fun createSceneB() 実装 Application モジュールに DestinationFactory の実態があり、 各Sceneのインスタンスを生成する Application モジュールは全てのモ ジュールを参照しているので全ての 画面のインスタンスを生成可能
追加要求1 ボトムタブごとに画面遷移の履歴(Back Stacks) を切り替えられるようにしたい
Back Stacks の切り替え • ボトムタブを切り替えた際、タブごとに Back Stacks を保存して切り替える機能 ◦ いわゆる
Multiple Back Stacks 相当の機能 • PrimaryNavigationFragment という仕組みを使い、タブごとに FragmentManager を制御する Fragment を切り替えることで実現している ◦ Activity と実際に表示する画面の間に Fragment 階層を一枚挟み、タブ切り替えを 上位 Fragment の切り替えでやっているイメージ ◦ back の挙動なども自動的に切り替えてくれる ◦ 現在は FragmentManager に saveBackStack/restoreBackStack があるのでもう少しわかり や すい仕組みで切り替え可能
Back Stacks の切り替え • requireActivity().supportFragmentManager を使う代わりに以下のような方法 で FragmentManager を取り出すことで常にタブ挙動を考慮した画面遷移にで きる
NavigationController の導入 • 毎回 の記述を書いていられないので、 NavigationController という仕組みを導入した • アプリ内の画面遷移における共通処理を吸収するレイヤー ◦
処理対象の FragmentManager の選択 ◦ replace 時の containerViewId 指定 ◦ backstack の管理
NavigationController のコード(一部)
NavigationController の生成
NavigationController を使った画面遷移
追加要求2 条件によって遷移先が Fragment だったり Activity だったりする画面遷移を実装したい
遷移先がActivity/Fragmentで分岐 • ユーザー状態などによって遷移先が変わるアクションが存在する • ログイン済みの場合は目的の画面(Fragment)、未ログインの場合はログイン画 面(Activity)という複雑なパターンも存在する
Destination の導入 • Destination は遷移先(Fragment, DialogFragment, Intent)をラップする sealed class •
NavigationController が Destination への遷移をサポートすることで画面実装 では遷移先が Fragment 、 DialogFragment 、 Intent のいずれであるのか考 慮する必要がなくなった ◦ Result を受け取るケースでは考慮する必要があるので Destination を使わない処理になって いる
Destination の実装
NavigationController 側の処理
追加要求3 URLによる画面遷移処理を実装したい
URL による画面遷移処理 • いわゆるディープリンク処理 • 遷移先は Fragment だったり Activity だったり
• 外部からのアプリ起動、WebView内での遷移、APIレスポンスからのアクション など様々な箇所で同じ挙動を実現したい
DestinationParams の導入 • DestinaionParams は Destination を生成するための情報をまとめたもの • URLから遷移先(Destination)の種別と必要なパラメータを抽出し、プロパティと して保持する
• DestinationParams の定義は sealed interface なため、when による分岐処理 でパターン網羅しやすい
DestinationParams の実装
DestinationParams の利用 ほとんどのケースで、以下のような実装だけで動作するようにしている
WebView における DestinationParams • 去年の DroidKaigi で発表した時点では DestinationParams は存在していな かった
• 現在は WebView 内のURL解釈も DestinationParams で共通化しているため、 WebView画面で実装すべきメソッドは DestinationParams を渡して遷移するメ ソッドだけになった
WebView における DestinationParams
DestinationParams の機能ごとのタグづけ 各 DestinationParams がサポートする機能ごとにタグづけを行なっている sealed interface は複数実装できるので、サポートする機能によって DestinationParams の
sub interface をそれぞれ実装している 例えば、ディープリンク関連の処理では DeepLinkSupportedDestinationParams だ けを用いることで、 when 分岐の無駄な記述を減らすことができる
DestinationParams の機能ごとのタグづけ
まとめ
クックパッドアプリの 画面遷移を支える自作コンポーネント • DestinationParams ◦ 遷移先と必要なパラメータをまとめた sealed interface ◦ (理想的には)画面の数だけ
DestinationParams が存在する • Destination ◦ 画面遷移に必要なFragmentやActivity(Intent) などの実態を抽象化する sealed class ◦ (基本的には) Factory を経由して DestinationParams から生成される • NavigationController ◦ Destination による画面遷移をサポートする仕組み ◦ Multiple Back Stacks などの実装を隠蔽し、各画面が意図している画面遷移実装に集中でき るようにする
今後の課題 • Jetpack Navigation Component を利用していないこと • Navigation Component は必須ではないと感じているが、長期的なメンテナンス
コストを考えると公式が推している仕組みに近づけた方が良さそう • Navigation Component のマルチモジュールサポートは自作コンポーネントを 完全に置き換えられないため、しばらくは自作した仕組みを Navigation Component に寄せやすくする改良をしていくかも ◦ Navigation best practices for multi-module projects ◦ モジュール間遷移がディープリンク前提、 SafeArgs 使えないという制約は結構辛い
おわり