このページは Cloud Translation API によって翻訳されました。

各種の画面サイズのサポート

さまざまな画面サイズをサポートすると、さまざまなデバイスの多くのユーザーがアプリを利用できるようになります。

できるだけ多くの画面サイズをサポートするには、アプリのレイアウトがレスポンシブ / アダプティブになるように設計する必要があります。レスポンシブ/アダプティブレイアウトは、画面サイズに関係なく最適化されたユーザーエクスペリエンスを提供し、アプリはスマートフォン、タブレット、折りたたみ式デバイス、ChromeOS デバイス、縦向きと横向き、サイズ変更可能な設定（マルチウィンドウモードなど）に対応できます。

レスポンシブ/アダプティブレイアウトは、使用可能なディスプレイ領域に応じて変化します。変更の範囲は、スペースを埋めるためのレイアウトの微調整（レスポンシブデザイン）から、アプリがさまざまなディスプレイサイズに最適に対応できるようにレイアウトを完全に置き換える（アダプティブデザイン）まで多岐にわたります。

宣言型 UI ツールキットである Jetpack Compose は、さまざまなディスプレイサイズに合わせて異なる方法でコンテンツをレンダリングするように動的に変更されるレイアウトを設計および実装するのに適しています。

画面レベルのコンポーザブルの大規模なレイアウト変更を明示的にする

Compose を使用してアプリ全体をレイアウトする場合、アプリレベルと画面レベルのコンポーザブルは、レンダリング用としてアプリに与えられるすべてのスペースを占有します。設計のこのレベルでは、大画面を利用できるように画面の全体的なレイアウトを変更することが合理的です。

重要な用語:

アプリレベルのコンポーザブル: アプリに与えられるすべてのスペースを占有し、他のすべてのコンポーザブルを含む単一のルートコンポーザブル。
画面レベルのコンポーザブル: アプリレベルのコンポーザブル内に含まれ、アプリに与えられるすべてのスペースを占有するコンポーザブル。一般的に、各画面レベルのコンポーザブルは、アプリ内を移動する際の特定の移動先を表します。
個別のコンポーザブル: 他のすべてのコンポーザブル。個別の要素、再利用可能なコンテンツのグループ、画面レベルのコンポーザブル内でホストされるコンポーザブルなどがあります。

レイアウトに関する決定を行う際は、物理的なハードウェア値を使用しないでください。固定された具体的な値（デバイスはタブレットかどうか、物理画面のアスペクト比はあるかなど）でも、UI が動作するスペースを判断するうえで、こうした質問への回答は役に立たない場合があります。

スマートフォン、折りたたみ式デバイス、タブレット、ノートパソコンなど、デバイスのさまざまなフォームファクタを示す図。 — **図 1.** スマートフォン、折りたたみ式デバイス、タブレット、ノートパソコンのフォームファクタ

タブレットでは、アプリがマルチウィンドウモードで実行される（つまり、アプリが別のアプリと画面を分割している）場合があります。ChromeOS では、サイズ変更が可能なウィンドウ内でアプリが動作する場合があります。折りたたみ式デバイスのように、複数の物理画面が存在する場合もあります。いずれの場合も、物理画面サイズはコンテンツの表示方法の決定とは無関係です。

そうした決定は、Jetpack の WindowManager ライブラリによって提供される現在のウィンドウ指標など、アプリに割り当てられる画面の実際の領域に基づいて行う必要があります。Compose アプリで WindowManager を使用する方法については、JetNews サンプルをご確認ください。

このアプローチを採用すると、アプリが上記のすべてのシナリオで適切に動作するため、アプリの柔軟性が向上します。また、使用可能な画面スペースに対応できるようにレイアウトをアダプティブにすることで、ChromeOS などのプラットフォームと、タブレットや折りたたみ式デバイスなどのフォームファクタをサポートするための特別な処理の量も削減されます。

アプリが使用できる関連スペースを確認したら、ウィンドウサイズクラスを使用するで説明しているように、未加工のサイズを意味のあるサイズクラスに変換すると便利です。これにより、サイズが標準サイズのバケットにグループ化されます。これは、ほとんどの固有のケースに対してアプリを最適化できる、シンプルさと柔軟性のバランスを取るように設計されたブレークポイントです。これらのサイズクラスはアプリのウィンドウ全体を参照するので、画面レイアウト全体に影響するレイアウトを決定する際に使用してください。これらのサイズクラスは状態として渡すことができます。また、追加のロジックを実行して、ネストされたコンポーザブルに渡す派生状態を作成することもできます。

@Composable
fun MyApp(
    windowSizeClass: WindowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
) {
    // Perform logic on the size class to decide whether to show the top app bar.
    val showTopAppBar = windowSizeClass.windowHeightSizeClass != WindowHeightSizeClass.COMPACT

    // MyScreen knows nothing about window sizes, and performs logic based on a Boolean flag.
    MyScreen(
        showTopAppBar = showTopAppBar,
        /* ... */
    )
}AdaptiveLayoutSnippets.kt

このような階層化されたアプローチでは、画面サイズのロジックを単一の場所にとどめておくことができます。アプリのさまざまな場所にロジックを分散させてそれらの同期を維持する必要はありません。この 1 つの場所から状態が生成され、他のアプリの状態と同様に、他のコンポーザブルに明示的に渡すことができます。状態を明示的に渡すことで、個別のコンポーザブルが簡素化されます。個別のコンポーザブルは、他のデータとともにサイズクラスまたは指定された構成を受け取る通常のコンポーズ可能な関数にすぎないからです。

柔軟なネストされたコンポーザブルは再利用が可能

コンポーザブルは、さまざまな場所に配置できる場合、より再利用しやすくなります。コンポーザブルが常に特定のサイズで特定の場所に配置されることを想定している場合は、別の場所で再利用することや、異なる使用可能なスペースの量で再利用することが困難になります。つまり、再利用可能な個々のコンポーザブルは、「グローバル」のサイズ情報に暗黙的に依存しないようにする必要があります。

次の例を考えてみましょう。リスト詳細レイアウトを実装するネストされたコンポーザブルが、1 つのペインまたは横に並んだ 2 つのペインを表示するとします。

横に並んだ 2 つのペインを表示するアプリのスクリーンショット — **図 2.** 一般的なリストと詳細のレイアウトを表示するアプリのスクリーンショット。1 はリスト領域、2 は詳細領域です。

この決定をアプリの全体的なレイアウトに含めたいので、前述のように、画面レベルのコンポーザブルから決定を渡します。

@Composable
fun AdaptivePane(
    showOnePane: Boolean,
    /* ... */
) {
    if (showOnePane) {
        OnePane(/* ... */)
    } else {
        TwoPane(/* ... */)
    }
}AdaptiveLayoutSnippets.kt

代わりに、使用可能なスペースに応じて、コンポーザブルが自身のレイアウトを個別に変更するようにしたい場合はどうでしょうか。たとえば、スペースに余裕があるときに追加の詳細を表示するカードを使用したい場合です。使用可能なサイズに基づいてロジックを実行する必要がありますが、具体的にどのサイズを実行すればよいでしょうか。

2 種類のカードの例。 — **図 3.** アイコンとタイトルのみを表示する幅の狭いカードと、アイコン、タイトル、簡単な説明を表示する幅の広いカード。

前述のように、デバイスの実際の画面サイズを使用しないようにする必要があります。その値は、複数の画面がある場合も、アプリが全画面表示でない場合も不適切です。

このコンポーザブルは画面レベルのコンポーザブルではないので、再利用可能性を最大化するために、現在のウィンドウ指標も直接使用するべきではありません。コンポーネントがパディング付きで配置されている場合（インセット用など）、またはナビゲーションレールやアプリバーなどのコンポーネントが存在する場合は、コンポーザブルが使用できるスペースの量が、アプリが使用できる全体的なスペースと大きく異なることがあります。

したがって、コンポーザブルが自身のレンダリング時に実際に与えている幅を使用する必要があります。この幅を取得するには、次の 2 つの方法があります。

コンテンツを表示する場所または方法を変更したい場合は、修飾子のコレクションまたはカスタムレイアウトを使用して、レイアウトをレスポンシブにすることができます。これは、すべての使用可能なスペースを子で埋めるか、十分な空間がある場合に複数の列に複数の子をレイアウトする単純な方法で実現できます。

表示する内容を変更したい場合は、代わりにより強力な方法である BoxWithConstraints を使用できます。このコンポーザブルは、使用可能なスペースに応じて異なるコンポーザブルを呼び出すために使用できる測定制約を提供します。ただし、BoxWithConstraints はこれらの制約がわかっているレイアウトフェーズまでコンポジションを延期し、レイアウト中により多くの処理が実行されるため、コストがかかります。

@Composable
fun Card(/* ... */) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(/* ... */)
                Title(/* ... */)
            }
        } else {
            Row {
                Column {
                    Title(/* ... */)
                    Description(/* ... */)
                }
                Image(/* ... */)
            }
        }
    }
}AdaptiveLayoutSnippets.kt

さまざまなサイズですべてのデータを使用できるようにする

追加の画面スペースを利用する場合、大きな画面では、小さな画面よりも多くのコンテンツをユーザーに表示するための空間が必要になることがあります。そのように動作するコンポーザブルを実装する際は、効率化を図るために、現在のサイズの副作用としてデータを読み込みたくなるかもしれません。

しかし、これは単方向データフローの原則に反します。単方向データフローでは、データをホイスティングしてコンポーザブルに提供することにより、適切なレンダリングが可能になります。データの一部が必ずしも使用されない場合でも、任意のサイズで表示する必要がある情報をコンポーザブルが常に保持できるように、コンポーザブルに十分なデータを提供する必要があります。

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(description)
                }
                Image(imageUrl)
            }
        }
    }
}AdaptiveLayoutSnippets.kt

Card の例では、常に description を Card に渡していることに注意してください。description は、それを表示できる幅がある場合にのみ使用されますが、Card は、使用可能な幅と無関係に常にそれを必要とします。

常にデータを渡すことで、アダプティブレイアウトのステートフル性が低くなり、よりシンプルになり、サイズの切り替え（ウィンドウのサイズ変更、向きの変更、デバイスの折りたたみと展開によって発生することもある）の副作用がトリガーされなくなります。

また、この原則により、レイアウトの変更後も状態を保持できます。すべてのサイズで使用されるわけではない情報をホイスティングすることで、レイアウトサイズの変更時もユーザーの状態を保持できます。たとえば、showMore ブール値フラグをホイスティングすると、サイズ変更に応じてレイアウトが説明の表示と非表示を切り替える際に、ユーザーの状態が保持されます。

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    var showMore by remember { mutableStateOf(false) }

    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(
                        description = description,
                        showMore = showMore,
                        onShowMoreToggled = { newValue ->
                            showMore = newValue
                        }
                    )
                }
                Image(imageUrl)
            }
        }
    }
}AdaptiveLayoutSnippets.kt

詳細

Compose のカスタムレイアウトについて詳しくは、以下の参考情報をご覧ください。

サンプルアプリ

CanonicalLayouts は、大画面デバイスで最適なユーザーエクスペリエンスを提供する実績のあるデザインパターンのリポジトリです。
JetNews は、使用可能なスペースを利用するために UI を適応させるアプリの設計方法を示しています。
Reply は、モバイル、タブレット、折りたたみ式デバイスをサポートする適応型のサンプルです。
Now in Android は、アダプティブレイアウトを使用してさまざまな画面サイズをサポートするアプリです。

動画

あなたへのおすすめ

注: JavaScript がオフになっている場合はリンクテキストが表示されます
既存のコードへのコンポーネントのマッピング
Compose レイアウトの基本
Jetpack Compose のフェーズ

正規レイアウト

ウィンドウサイズクラスを使用する