UI の役割は、アプリデータを画面に表示することです。UI は、ユーザー インタラクションの主要なポイントとしても機能します。ユーザー インタラクション（例: ボタンを押す）や外部入力（例: ネットワーク応答）によってデータが変更されるたびに、UI を更新してそのような変更を反映させます。UI は、実質的には、データレイヤから取得されたアプリの状態を視覚的に表したものです。
ただし、一般的に、データレイヤから取得するアプリデータの形式は、表示する必要がある情報の形式とは異なります。たとえば、UI では、データの一部だけが必要になる場合や、ユーザーに関連する情報を提示するために 2 つの異なるデータソースの統合が求められる場合があります。適用するロジックにかかわらず、UI を完全にレンダリングするために必要なすべての情報を UI に渡す必要があります。UI レイヤは、アプリデータの変更を UI が提示できる形式に変換して表示するパイプラインです。
基本的なケーススタディ
ニュース記事をフェッチして読者に提供するアプリを考えてみましょう。このアプリには、読むことのできる記事を提示する記事画面があり、ログインしているユーザーは目を引く記事をブックマークすることもできます。常に多くの記事が続々と生まれることを考えると、読者がカテゴリごとに記事を閲覧できることも必要です。要約すると、このアプリでユーザーは次のことができます。
- 読むことのできる記事を表示する。
- 記事をカテゴリ別に閲覧する。
- ログインして特定の記事をブックマークする。
- 利用資格がある場合は、プレミアム機能を利用する。
次のセクションでは、このサンプルをケーススタディとして使用し、単方向データフローの原則を紹介します。また、UI レイヤのアプリ アーキテクチャのコンテキストで、その原則を適用することにより解決できる問題を説明します。
UI レイヤのアーキテクチャ
「UI」という用語は、データを表示するコンテナやコンポーズ可能な関数などの UI 要素を指します。Android UI を構築するには、Jetpack Compose が推奨されるツールキットです。データレイヤの役割は、アプリデータの保持と管理、そしてアプリデータへのアクセスの提供であるため、UI レイヤは次のステップを実行する必要があります。
- アプリデータを使用し、UI が簡単にレンダリングできるデータに変換する。
- UI がレンダリングできるデータを使用し、ユーザーに表示する UI 要素に変換する。
- このような UI 要素の集合体からのユーザー入力イベントを使用し、必要に応じてその結果を UI データに反映させる。
- ステップ 1～3 を必要な回数だけ繰り返す。
このガイドの残りの部分では、上記のステップを実行する UI レイヤを実装する方法について説明します。このガイドでは、特に次のタスクとコンセプトを取り上げます。
- UI 状態を定義する方法
- UI 状態を生成および管理する手段としての単方向データフロー（UDF）
- UDF の原則に沿って監視可能なデータ型で UI 状態を公開する方法
- 監視可能な UI 状態を使用する UI を実装する方法
この中で最も基本的な事項は、UI 状態の定義です。
UI 状態を定義する
前述のケーススタディでは、UI は記事のリストに加えて、各記事のいくつかのメタデータを表示します。アプリがユーザーに提示するこれらの情報が、UI 状態です。
言い換えると、ユーザーが目にするものが UI であるとすれば、ユーザーが目にするべきであるとアプリがみなすものが UI 状態です。同じコインの両面のように、UI は UI 状態を視覚的に表したものです。UI 状態が変更されると、すぐに UI に反映されます。
ケーススタディを見てみましょう。ニュースアプリの要件を満たすため、UI を完全にレンダリングするのに必要な情報は、次のように定義される NewsUiState データクラスにカプセル化できます。
data class NewsUiState(
val isSignedIn: Boolean = false,
val isPremium: Boolean = false,
val newsItems: List<NewsItemUiState> = listOf(),
val userMessages: List<Message> = listOf()
)
data class NewsItemUiState(
val title: String,
val body: String,
val bookmarked: Boolean = false,
...
)
UI の状態について詳しくは、状態と Jetpack Compose をご覧ください。
不変性
前の例では、UI 状態の定義は不変です。その重要なメリットは、不変オブジェクトがその時点でのアプリの状態を確実に提供できることです。これにより、UI は解放されて唯一の役割に集中できます。それは、状態を読み取り、それに応じて自身の UI 要素を更新することです。UI 自体がそのデータの唯一のソースでない限り、UI 内で UI 状態を直接変更すべきではありません。この原則を破ると、同じ情報について信頼できるソースが複数発生し、データの不整合やわかりにくいバグにつながります。
たとえば、前述のケーススタディについて考えてみましょう。UI 状態の NewsItemUiState オブジェクトの bookmarked フラグが Activity クラス内で更新された場合、そのフラグは、記事の「ブックマーク済み」ステータスのソースとしてデータレイヤと競合することになります。不変のデータクラスは、この種の不整合を防止するために大変役立ちます。
このガイドにおける命名規則
このガイドでは、UI 状態クラスは、画面の機能、または UI 状態クラスで記述される画面の部分に基づいて命名されます。規則は次のとおりです。
機能 + UiState。
たとえば、ニュースを表示する画面の状態の名前は NewsUiState で、ニュース アイテムのリスト内のニュース アイテムの状態の名前は NewsItemUiState です。
単方向データフローで状態を管理する
前のセクションでは、UI 状態が、UI のレンダリングに必要な詳細情報の不変のスナップショットであることを説明しました。しかし、アプリ内のデータは動的な性質を持つため、状態は時間とともに変化する可能性があります。状態の変化は、アプリデータの入力の基になるデータを変更するユーザー インタラクションなどのイベントによって発生します。
こうしたインタラクションはメディエータで処理すると便利です。たとえば、各イベントに適用するロジックを定義し、UI 状態を作成するためにバッキング データソースを変換します。こうしたインタラクションとそのロジックは UI 自体に格納することもできますが、UI が過剰な責任を負うことになると、複雑で手に負えなくなります。さらに、作成されるコードが密結合されたものになるので、テストのしやすさに影響する可能性があります。UI 状態が非常に単純である場合を除き、UI は、UI 状態を使用して表示する責任のみを負うようにしてください。
このセクションでは、こうした責任の健全な分離を実現するアーキテクチャ パターンである単方向データフロー（UDF）について説明します。
状態ホルダー
状態ホルダーは、UI 状態の生成と、その状態の生成に必要なロジックを担当するクラスです。状態ホルダーのサイズは、ボトム アプリバーのような単一のウィジェットから、画面全体またはナビゲーション デスティネーションまで、対応する管理対象の UI 要素のスコープに応じてさまざまです。
後者の場合、一般的な実装は ViewModel のインスタンスですが、アプリの要件によっては単純なクラスで十分な場合もあります。たとえば、ケーススタディのニュースアプリは、NewsViewModel クラスを状態ホルダーとして使用し、そのセクションに表示される画面の UI 状態を生成します。
UI とその状態プロデューサとの共依存関係をモデル化する方法は数多くあります。しかし、UI とその ViewModel クラスの間のインタラクションは、主にイベント入力とそれに続く状態出力として認識できるので、その関係は次の図のように表現できます。
状態が下に流れ、イベントが上に流れるパターンを、単方向データフロー（UDF）と呼びます。このパターンは、アプリ アーキテクチャにおいて次のことを意味します。
- ViewModel は、UI が使用する状態を保持し、公開します。UI 状態は、ViewModel によって変換されたアプリデータです。
- UI は、ユーザー イベントを ViewModel に通知します。
- ViewModel は、ユーザー アクションを処理し、状態を更新します。
- 更新された状態は、UI にフィードバックされてレンダリングされます。
- 上記のステップは、状態の変化を引き起こす任意のイベントで繰り返されます。
ナビゲーション デスティネーションまたは画面の場合、ViewModel はリポジトリまたはユースケース クラスと連携し、データを取得して UI 状態に変換するとともに、状態の変化を引き起こす可能性があるイベントの結果を取り込みます。前述のケーススタディにおける記事のリストでは、それぞれの記事に、タイトル、説明、出典、著者名、公開日、ブックマークされているかどうかの情報があります。各記事アイテムの UI は次のように表示されます。
ユーザーによる記事のブックマークのリクエストは、状態の変化を引き起こすイベントの一例です。UI がレンダリングを完全に行えるよう、UI 状態のすべてのフィールドに値を入力するロジック、およびインベントを処理するロジックをもれなく定義することが、状態プロデューサとしての ViewModel の役割です。
以降のセクションでは、状態の変化を引き起こすイベントと、UDF を使用してイベントを処理する方法について詳しく説明します。
ロジックのタイプ
記事をブックマークする機能は、アプリの価値を高めるビジネス ロジックの一例です。詳しくは、データレイヤのページをご覧ください。しかし、定義することが重要な意味を持つロジックには、さまざまなタイプがあります。
- ビジネス ロジックは、アプリデータに関するプロダクトの要件の実装です。前述のように、ケーススタディのアプリで記事をブックマークすることはその一例です。通常、ビジネス ロジックはドメインレイヤまたはデータレイヤに配置され、UI レイヤに配置されることはありません。
- UI 動作ロジック（または UI ロジック）は、状態の変化を画面に表示する「方法」を意味します。たとえば、Android
Resourcesを使って画面に表示する適切なテキストを取得する、ユーザーがボタンをクリックしたときに特定の画面に移動する、トーストまたはスナックバーを使ってユーザー メッセージを画面に表示する、などの方法があります。
UI ロジックは、特に Context のような UI タイプを含む場合、ViewModel ではなく UI で実行する必要があります。UI が複雑になるため、テストのしやすさと関心の分離を重視して UI ロジックを別のクラスに委任したい場合は、単純なクラスを状態ホルダーとして作成することができます。UI に作成される単純なクラスは、UI のライフサイクルに従うので、Android SDK の依存関係を利用できます。ViewModel オブジェクトはより長く存在します。
状態ホルダーの詳細と、状態ホルダーが UI の構築を容易にするためにいかに役立つかについては、Jetpack Compose の状態に関するガイドをご覧ください。
UDF を使用する理由
UDF は、図 4 に示すように、状態生成のサイクルをモデル化したものです。そこでは、状態の変化が発生する場所、変換される場所、最終的に使用される場所が分かれています。この分離により、UI は、その名前が示すとおりの役割を果たすことができます。それは、状態の変化を監視して情報を表示し、そのような変化を ViewModel に渡してユーザーの意図を伝達することです。
言い換えると、UDF により次のことが実現されます。
- データの整合性。UI に対して、信頼できる唯一のデータソースが存在します。
- テストのしやすさ。状態のソースが分離されるため、UI から独立してテストを行うことができます。
- メンテナンスのしやすさ。状態の変化は、ユーザー イベントおよびデータソースからのデータ取得の結果であるという、明確に定義されたパターンに従います。
UI 状態を公開する
UI 状態を定義し、その状態の生成を管理する方法を決定したら、次のステップとして、生成された状態を UI に提示します。
UDF を使用して状態の生成を管理する場合、生成される状態をストリームとみなすことができます。つまり、時間の経過とともに状態の複数のバージョンが生成されます。StateFlow などの監視可能なデータホルダーで UI 状態を公開します。これにより、UI は ViewModel から直接手動でデータを取得する手間をかけずに、状態の変更に反応できます。このようなタイプには、常に UI 状態の最新バージョンがキャッシュに保存されるというメリットもあります。このことは、構成変更後に状態をすばやく復元するために役立ちます。
class NewsViewModel(...) : ViewModel() {
val uiState: NewsUiState = …
}
Kotlin Flow の概要については、Android での Kotlin Flow をご覧ください。StateFlow を観測可能なデータホルダーとして使用する方法については、Jetpack Compose の高度な状態と副作用の Codelab をご覧ください。
UI に公開されるデータが比較的単純である場合は、データを UI 状態タイプでラップすることがしばしば効果的です。そうすると、状態ホルダーの出力とそれに関連付けられた画面または UI 要素との関係が伝達されるからです。UI 要素が複雑になるにつれて、UI 状態の定義を拡充することが簡単になるため、UI 要素のレンダリングに必要な追加情報に対応できます。
UiState のストリームを作成する一般的な方法は、private set を使用して mutableStateOf プロパティを公開することです。これにより、ViewModel 内の状態は可変のままですが、UI からは読み取り専用になります。
class NewsViewModel(...) : ViewModel() {
var uiState by mutableStateOf(NewsUiState())
private set
...
}
次に、ViewModel は、内部的に状態を変更するメソッドを公開して、UI が使用する更新を公開できます。たとえば、非同期アクションを実行する必要がある場合を考えてみましょう。viewModelScope を使用してコルーチンを起動し、完了したら可変の状態を更新できます。
class NewsViewModel(
private val repository: NewsRepository,
...
) : ViewModel() {
var uiState by mutableStateOf(NewsUiState())
private set
private var fetchJob: Job? = null
fun fetchArticles(category: String) {
fetchJob?.cancel()
fetchJob = viewModelScope.launch {
try {
val newsItems = repository.newsItemsForCategory(category)
uiState = uiState.copy(newsItems = newsItems)
} catch (ioe: IOException) {
// Handle the error and notify the UI when appropriate.
val messages = getMessagesFromThrowable(ioe)
uiState = uiState.copy(userMessages = messages)
}
}
}
}
前述の例では、NewsViewModel クラスは特定のカテゴリの記事をフェッチしようとした後、その試行の結果（成功または失敗）を、UI が反応できる UI 状態に反映させます。エラー処理の詳細については、画面にエラーを表示するセクションをご覧ください。
その他の考慮事項
UI 状態を公開する際は、上記のガイダンスに加えて、次の点も考慮してください。
1 つの UI 状態オブジェクトで、互いに関連付けられた複数の状態を処理するようにします。そうすれば、データの不整合が減少し、コードが理解しやすくなります。ニュース アイテムのリストとブックマーク数を 2 つの異なるストリームで公開すると、一方が更新され、もう一方が更新されない状況が生じる可能性があります。使用するストリームを 1 つにすれば、両方の要素が常に最新の状態に保たれます。さらに、一部のビジネス ロジックでは、ソースの組み合わせが必要になる場合があります。たとえば、ブックマーク ボタンを表示する必要があるのは、ユーザーがログイン済みで、かつプレミアム ニュース サービスを定期購読している場合のみとします。UI 状態クラスは次のように定義できます。
data class NewsUiState( val isSignedIn: Boolean = false, val isPremium: Boolean = false, val newsItems: List<NewsItemUiState> = listOf() ) val NewsUiState.canBookmarkNews: Boolean get() = isSignedIn && isPremiumこの宣言において、ブックマーク ボタンを表示するかどうかは、他の 2 つのプロパティの派生プロパティです。ビジネス ロジックが複雑になるにつれて、すべてのプロパティを直接利用できる唯一の
UiStateクラスを作成することがいっそう重要になります。UI 状態: 1 つのストリームか複数のストリームか。UI 状態を 1 つのストリームで公開するか複数のストリームで公開するかを選択する際の重要な指針は、出力されるアイテム間の関係です。1 つのストリームで公開する最大の利点は、利便性とデータの整合性です。状態のコンシューマは、最新の情報をいつでも利用できます。ただし、次のように、ViewModel からの個別の状態ストリームを使用することが適切な場合もあります。
関連のないデータ型: UI のレンダリングに必要な状態は、互いに完全に独立している場合があります。このような場合は、完全に異なる複数の状態を一緒にまとめると、コストがメリットを上回る可能性があります。ある状態が他の状態より頻繁に更新される場合は、特にそうです。
UiStateの差分抽出:UiStateオブジェクト内のフィールドの数が多いと、その分だけフィールドが更新された結果としてストリームが出力される可能性が高くなります。UI 要素には、連続する出力が異なるものか同じものかを把握する差分抽出メカニズムがないため、出力ごとに UI 要素の更新が発生します。つまり、distinctUntilChanged()などのFlowAPI メソッドを使用して緩和することが必要になる場合があります。
レンダリングと UI の状態について詳しくは、コンポーザブルのライフサイクルをご覧ください。
UI 状態を使用する
UI で UiState オブジェクトのストリームを使用するには、アプリで使用している観測可能なデータ型に終端演算子を使用します。たとえば、Kotlin Flow の場合は collect() メソッドまたはそのバリエーションを使用します。
UI で監視可能なデータホルダーを使用する際は、必ず UI のライフサイクルを考慮してください。コンポーザブルがユーザーに表示されていないときは、UI に UI 状態を監視させないでください。このトピックについて詳しくは、こちらのブログ投稿をご覧ください。フローを使用している場合は、適切なコルーチン スコープと collectAsStateWithLifecycle API を使用してライフサイクルに関する問題を処理することをおすすめします。
@Composable private fun ConversationScreen( conversationViewModel: ConversationViewModel = viewModel() ) { val messages by conversationViewModel.messages.collectAsStateWithLifecycle() ConversationScreen( messages = messages, onSendMessage = { message: Message -> conversationViewModel.sendMessage(message) } ) } @Composable private fun ConversationScreen( messages: List<Message>, onSendMessage: (Message) -> Unit ) { MessagesList(messages, onSendMessage) /* ... */ }
進行中の操作を表示する
UiState クラスで読み込み状態を表現する簡単な方法は、次のブール値フィールドを使用することです。
data class NewsUiState(
val isFetchingArticles: Boolean = false,
...
)
このフラグの値は、UI に進行状況バーが存在するかどうかを表します。
@Composable
fun LatestNewsScreen(
modifier: Modifier = Modifier,
viewModel: NewsViewModel = viewModel()
) {
Box(modifier.fillMaxSize()) {
if (viewModel.uiState.isFetchingArticles) {
CircularProgressIndicator(Modifier.align(Alignment.Center))
}
// Add other UI elements. For example, the list.
}
}
画面にエラーを表示する
UI にエラーを表示する処理は、進行中のオペレーションを表示する処理と似ています。どちらも、存在するかどうかを表すブール値で簡単に表現できるからです。ただし、エラー処理には、ユーザーに返す関連メッセージや、失敗したオペレーションを再試行する関連アクションが含まれることもあります。したがって、進行中のオペレーションは読み込み中かそうでないかのいずれかであるのに対し、エラー状態は、エラーのコンテキストに合ったメタデータをホストするデータクラスでモデル化する必要があります。
記事のフェッチ中に進行状況バーを表示している前の例について考えてみましょう。このオペレーションでエラーが発生した場合、通常は、ユーザーに問題の詳細を示す 1 つ以上のメッセージを表示します。
data class Message(val id: Long, val message: String)
data class NewsUiState(
val userMessages: List<Message> = listOf(),
...
)
エラー メッセージは、スナックバーなどの UI 要素の形式でユーザーに示されます。UI イベントがどのように生成され、使用されるかについて詳しくは、UI イベントをご覧ください。
スレッド化と同時実行
ViewModel 内で実行されるすべての処理が「メインセーフ」である（メインスレッドから安全に呼び出される）ことを確認します。データレイヤとドメインレイヤは、別のスレッドに処理を移動する責任を負います。
ViewModel は、長時間実行オペレーションを実行する場合、そのロジックをバックグラウンド スレッドに移動する責任も負います。同時実行オペレーションを管理する効果的な手段として、Kotlin コルーチンがあります。Jetpack アーキテクチャ コンポーネントには、それらに対するサポートが組み込まれています。Android アプリでコルーチンを使用する方法について詳しくは、Android での Kotlin コルーチンをご覧ください。
ナビゲーション
アプリのナビゲーションの変更は、多くの場合、イベントのような出力によって引き起こされます。たとえば、SignInViewModel クラスがログインを実行した後、UiState で isSignedIn フィールドが true に設定される場合などです。このようなトリガーは、前述の UI 状態を使用するセクションで説明しているような方法で消費するべきです。ただし、例外として、その消費の実装は Navigation コンポーネントに準ずる必要があります。
UI ナビゲーションについて詳しくは、ナビゲーション 3 をご覧ください。
Paging
Paging ライブラリは、UI では PagingData という型で使用されます。PagingData は時間とともに変化する可能性があるアイテムを表現および格納する（つまり、不変の型ではない）ため、不変の UI 状態で表現しないでください。代わりに、ViewModel から固有のストリームで個別に公開します。
Paging ライブラリの Compose API の例を次に示します。
@Composable fun MyScreen(flow: Flow<PagingData<String>>) { val lazyPagingItems = flow.collectAsLazyPagingItems() LazyColumn { items( lazyPagingItems.itemCount, key = lazyPagingItems.itemKey { it } ) { index -> val item = lazyPagingItems[index] Text("Item is $item") } } }
アニメーション
滑らかなトップレベル ナビゲーション遷移を実現するには、アニメーションを開始する前に、後続の画面でデータが読み込まれるのを待機します。
ナビゲーション トランジションについて詳しくは、Navigation 3 と Compose の共有要素トランジションをご覧ください。
参考情報
コンテンツの閲覧
サンプル
次の Google サンプルは、UI レイヤの使用方法を示しています。このガイダンスを実践するためにご利用ください。
あなたへのおすすめ
- 注: JavaScript がオフになっている場合はリンクテキストが表示されます
- UI 状態生成
- 状態ホルダーと UI の状態 {:#mad-arch}
- アプリ アーキテクチャ ガイド