基本的に、状態生成とは、変化の増分を UI 状態に適用することです。状態は常に存在し、イベントの結果として変化します。次の表にイベントと状態の違いをまとめます。
イベント |
状態 |
一過性、予測不可能、有限の期間だけ存在 |
常に存在 |
状態生成の入力 |
状態生成の出力 |
UI またはその他のソースから生成される |
UI が使用する |
イベントは以下から発生します。
- ユーザー: アプリの UI を操作したとき
- その他の状態変化のソース: UI（スナックバーのタイムアウト イベントなど）、 ドメインレイヤ（ユースケースなど）、またはデータレイヤ（リポジトリなど）からのアプリデータを表示する API
状態生成の API
状態生成に使用される主な API は、パイプラインのステージに応じて次の 2 つがあります。
パイプラインのステージ |
API |
入力 |
UI ジャンクをなくすために、非同期 API を使用して UI スレッド外で処理を実行することをおすすめします。 たとえば、Kotlin ではコルーチンまたは Flow を使用し、 RxJava またはコールバックを Java プログラミング言語で使用します。 |
出力 |
オブザーバブルなデータホルダーの API を使用し、状態が変化したときに UI を無効化して再レンダリングすることをおすすめします。たとえば、StateFlow や LiveData などです。オブザーバブル データホルダーは、画面に表示される UI 状態を UI が常に持つことを保証します。 |
この 2 つの中で、入力に非同期 API を選ぶことは、出力にオブザーバブルな API を選ぶことよりも、状態生成パイプラインの性質に大きく影響します。これは、入力によって、パイプラインに適用できる処理の種類が決まるためです。
状態生成パイプラインの組み立て
以降のセクションでは、さまざまな入力に最適な状態生成の手法と、それに対応する出力 API について説明します。各状態生成パイプラインは、入力と出力の組み合わせであり、次のようになっていることが推奨されます。
- ライフサイクル対応: UI が見えない状態にある場合や、UI がアクティブでない場合、状態生成パイプラインは、明示的に必要な場合を除き、リソースを消費すべきではありません。
- 状態を使用しやすい: UI は、生成された UI 状態を簡単にレンダリングできるべきです。状態生成パイプラインの出力に関して考慮すべき点は、View システムや Jetpack Compose など、View の API によって異なります。
状態生成パイプラインの出力タイプ
UI 状態に対する出力 API の選択と、その表示の性質は、アプリで UI のレンダリングに使用する API に大きく左右されます。Android アプリでは、View と Jetpack Compose から選択できます。その際には次の点を考慮します。
- ライフサイクルを意識した方法で状態を読み取る。
- 状態ホルダーの 1 つまたは複数のフィールドで状態を公開すべきかどうか。
次の表は、Views フレームワークを使用する場合に、状態生成パイプラインで使用する API をまとめたものです。
入力 |
出力 |
ワンショット API |
|
ストリーム API |
|
ワンショット API とストリーム API |
|