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

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

できるだけ多くの画面サイズをサポートするには、アプリのレイアウトがレスポンシブ / アダプティブになるように設計する必要があります。レスポンシブ/アダプティブ レイアウトは、画面サイズにかかわらず、最適なユーザー エクスペリエンスを提供します。これにより、アプリはスマートフォン、タブレット、折りたたみ式デバイス、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 つのペインまたは横に並んだ 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 は、アダプティブ レイアウトを使用してさまざまな画面サイズをサポートするアプリです。

動画

前へ
正規レイアウト
次へ
ウィンドウ サイズクラスを使用する