"Guide to app architecture" に追加された state holder のページを読む
nashcft2021年末に刷新された Android Developers の "Guide to app architecture" というアプリケーションの構成に関する文書に、最近新たにページが追加されていたので前回同様メモを取りつつ読む。
前回のメモは↓
nashcft今回新たに追加されたのは UI layer の state holder や UI state に関するページ:
UI layer の状態管理まわりについては overview のページでも結構解説をしていたと感じていたけど、今回の追加ページではもう少し細かく中身を見ていくことになりそう。 UI layer がより "Android 的" な部分だからか他の layer と比べて特に力を入れている様子? UI events に関する個別ページ[1]が刷新の時点で存在してたし。
nashcftElements of the UI state production pipeline
Overview でも登場した用語 (UI state と logic) について。 Logic の方は他のページでも出ていたもの (business logic と UI behavior logic) を再度紹介しているだけだが、 UI state はここで新たに以下の2つに分類している:
- Screen UI state: 画面に何を表示するかに関わるもの。 UI の要素そのものを表す model のことを指していそう。
- UI element state: それぞれの UI 要素がどのように描画されるかに関わるもの。つまり各要素の attribute を決定するためのデータ。
Android lifecycle and the types of UI state and logic
タイトルの通り UI lifecycle と UI state や logic の関係性について。前半はそれはそうという話。 Business logic の実行と screen UI state の構築は lifecycle の影響を受けないようにしなよ、ただし user events が business logic を起動する部分や screen UI state がその先に流れる部分は影響を受けるよ、他の要素は lifecycle の影響下だよ、はい。
後半は前節で紹介された logic や state の各要素をどういう順番に並べて UI layer のデータの流れを構成したらいいの? という話。結局は図の順番を守りなさいよ (ただし構築する UI の要求によって要素を抜いてよい) ということ。
この節は若干「なんで?」の部分を overview の内容に任せているので人によっては言葉不足感があるかも。 UI lifecycle independent なステップの成果物であるところの screen UI state が immutable だから UI lifecycle dependent なステップがガチャガチャ動いても同じデータにもとづいて (UI configuration やらなんやらで UI elements state に関わる部分に違いは出るだろうけど) 同じ UI を生成できるね、というまとめ方でいいかなあ。私はそういう話だと解釈した。
nashcftState holders and their responsibilities
Overview の state holders の話[1]の掘り下げかと思ったけどあまりそんな感じではなさそう。
前回メモとった時だと全体の overview[2] を読んだときに感じたような内容 (state holders の層までは極力ロジックを持たせず、ロジック本体はそれより下に持たせて state holders はそれを呼ぶだけにしたそう) が前半に書かれている。ここで全体の overview にどんなこと書いてあったか見直したらすごく簡素な UI components と state holders の紹介だけしかなくて、記述が更新されたのか幻覚を見たのかわからんとなった。
後半は logic の種類それぞれに対応した state holder があるよという話。 Note の話はそれはそうという感じ。
Business logic and its state holder
Business logic を担当する state holder の話。実質 Jetpack ViewModel の性質とそこで実装すべきものは何か? みたいな内容。
Business logic state holders が持つべき性質として「UI に対してユニークで、再利用できない」というのがあるが、つまり複数の UI で再利用したいのは state holder それ自体ではなくそこで使われている business logic であって、 state holder ごと別の UI で使いたくなったときは state holder の中から business logic を domain layer や data layer に逃しきれていないんじゃない? という話。あくまで UI state holder というものは UI を表す model を置く場所であり、実装レベルの依存/結合度の意味ではなく表現するものという意味で UI elements と密接な関係にあるコンポーネントなのだということを強調したいのだろう。 Mobile/TV/tablet みたいに form factor が違うだけで (抽象的な意味で) UI としては同一のものを提供している場合は再利用してもよいとのこと。
Warning の内容は composable function 内で ViewModel 自体を下の方まで流し込むと面倒臭くなるからやめようという話。
nashcftUI logic and its state holder
UI behavior logic とその state holder の話。持つべき性質の記述のフォーマットが business logic state holder のそれと違うのなんで?
UI elements にくっついた state holder なので生存期間もそれに準ずるし、同種の element 間で再利用していいよとのこと。 Bisiness logic state holder と違ってただの UI パーツの部品みたいなものなので汎用性を持たせられるねという感じか。あとはこっちの state holder は本当にちょっとしたものという扱いで、 Jetpack ViewModel みたいな大仰なものでこさえなくていいとか、 UI logic が単純で量も少なければ UI elements の中に直接書いてしまってよいとか、ここは無闇に頑張って作り込むなよという雰囲気がある。
Choose between a ViewModel and plain class for a state holder
このページのまとめで、結局どこに何を置いてどういう流れで結びつけるのか? の再確認と、 UI logic state holder は十分複雑な機能を UI に持たせる時だけ切り出してほしい気持ちの念押し。