Androidでマルチモジュールをやってみているという話
droidkaigiでマルチモジュール関連の発表をたくさん聞いて、やってみたくなったのでやってみている。
データレイヤーを単に外に出すところまではなんとなくできたけどそこから先のところでうまく行かなかったり腑に落ちたり落ちなかったりしている。基本的な設計力がないからマルチモジュール化できないということなのであろうか。どうしてそうなっているかを理解せず何かの真似でやってみてもうまく行かない。
ちなみにここでモジュールって言ったらGradle（とかKotlin）で言う所のモジュールのことです。
daggerがなんか難しい
- モジュールとSubcomponentとを対応させればいいんじゃね？と考えて公式ページを見ながらやってみるものの説明の通り（？）にやってみたらStackOverflowError
- ComponentをもっているモジュールがSubcomponentの依存関係に引っ張られて本来不要なモジュールに依存せざるを得なくなっている*1
- kaptの挙動がよくないという説がある様子
- apiのモジュールを挟めばいいんだろうか
- koinとかはどうなんだろうと思い始める
スタイルとかテーマって開発中どうやって確認すればいいんだろう
- マテリアルデザインのテーマが読み込めなくてFABを表示できない（？）何が悪いのかもよくわかっていない
- styleとかthemeはsharedなモジュールに置く？スタイルと実装とは切り離して考えるべきだとも思うけどそこまでやるのもなんか違う気がしている。
Activity, Fragment, ViewModelはどう分けるのがよいのか
- ViewModelはViewに依存しないとはいっても、どんなViewDataBindingにバインドされるかは知っているはず*2ではないかと思うので、レイアウトファイルとViewModelはなんとなくセットにしておきたい
- なんだかんだ言って画面はFragmentを組み合わせて作ることになるので、Fragmentのレイアウトファイルと、それとバインドするViewModelとをセットにして作ることになるはず
- そう考えるとFragmentとViewModelは一緒のモジュールに入れればいいんじゃないのか？と思わなくもない。でもモジュール化の意義的に正しいのか、なんとなく違和感を覚える*3
- 一方で、ActivityのレイアウトファイルはFragmentのコンテナしか置かないとかいうやつがでてくる*4
- そういうやつはバインドするデータやビューがあんまりないのでViewModelとバインドできてもおいしくない
- そういうActivityはFragmentの置き換えを実装するだけでいいという感じになる。どんな時にどのFragmentを置くかというのをViewModelで管理することになるかもしれないが、FragmentManagerをいじるロジックはActivityに書くことになり画面が増えてくるとつらい
- Fragmentの置き換えを専門にやるクラスがあればよいのか？→JetpackのNavigationがそれにあたるか
- navigationを使えば、ActivityやFragmentは他にどんなActivityやFragmentがあるのか知らなくてよさそう
- navigationだけがActivityやFragment、他のnavigationを知っていればよいというふうにできれば、navigation（の具象クラス）はapplicationと同じモジュールに置けばよい
- 画面のことはenumとかsealed classで定義したクラス（sharedなモジュールに置く）で表現すれば、navigationの抽象クラスしか知らないクラスの中でも画面遷移を実現できそう
- 画面遷移イベントの発行を行う処理はViewModelでやってよい
- 画面遷移を依頼するようなイベントオブジェクトを定義するとMVIになるのか？
先は長い。俺たちの戦いは始まったばかりだ。
