1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@YuukiYoshida(Yuuki Yoshida)in株式会社Infreed

Android UI Development is Compose Firstを読んで、既存プロジェクトで考えたいこと

1
Posted at

はじめに

Android Developers Blogで、AndroidのUI開発に関する大きな方針としてAndroid UI Development is Compose Firstという記事が公開されていました。

記事では、Jetpack ComposeがAndroid UI開発の中心的な選択肢になっていることや、今後のガイダンスやライブラリがCompose Firstの考え方に寄っていくことが説明されています。

個人的に印象に残ったのは、Composeを使いましょうという単なる推奨ではなく、今後のAndroid UI開発ではComposeを前提に考える場面がより増えていきそうという点です。

ただし、既存のAndroidプロジェクトでは、まだXML Viewベースの画面も多く残っていると思います。

今回は、公式ブログの内容を読んで、既存プロジェクトではCompose Firstとどう向き合うのがよさそうかを整理してみます。

Android UI Development is Compose Firstとは

公式ブログでは、Jetpack Composeについて以下のような点が挙げられています。

  • モダンなUIを構築しやすい
  • Material Design Componentsとの相性がよい
  • PreviewやLive Editなどのツールにより開発効率を高めやすい
  • さまざまなAndroidデバイスの画面サイズに適応しやすい
  • Kotlinで宣言的にUIを書ける

特にComposeはスマートフォンだけではなく、タブレット、折りたたみ端末、デスクトップ的な表示領域など、さまざまなフォームファクタに対応するためのUI構築手段としても重要になってきています。

また、Google I/O 2026関連の記事でも、ComposeがAndroid UI開発の標準であり、今後のガイダンスやライブラリはCompose Firstのアプローチへ移行していくと説明されています。

つまり、これから新しくAndroid UIを作る場合、まずComposeで作ることを検討するという流れがより自然になっていきそうです。

Compose FirstはXMLを今すぐ捨てる話ではない

ここで注意したいのは、Compose Firstだからといって、既存のXML Viewベースの画面を今すぐすべて置き換える必要があるわけではないという点です。

既存プロジェクトでは、以下のような事情があります。

  • XML Viewで作られた画面が多い
  • FragmentやActivityの構成がView前提になっている
  • 既存のカスタムViewやBinding処理がある
  • QA済みの画面を不用意に触りたくない
  • チーム全体のCompose習熟度に差がある

この状態で、すべての画面を一気にComposeへ置き換えようとすると、かなり大きな作業になります。

UIの書き換えだけでなく、状態管理、画面遷移、テスト、Preview、デザイン反映、既存Viewとの接続など、影響範囲が広がりやすいためです。

そのため、Compose Firstを既存XMLをすぐ全部なくすという意味で捉えるよりも、今後新しく作るUIや、改修タイミングのあるUIではComposeを優先的に検討するという方針として捉える方が現実的だと思います。

既存プロジェクトで考えたいこと

既存プロジェクトでCompose Firstに向き合う場合、まずは以下のように段階を分けて考えるとよさそうです。

新規画面ではComposeを優先する

これから新しく作る画面であれば、Composeを採用しやすいです。

既存画面の置き換えと違って、過去の実装を壊すリスクが少なく、設計も最初からCompose前提にできます。

例えば、以下のような画面はCompose導入の候補になりやすいと思います。

  • 新規機能の画面
  • 独立性の高い画面
  • 表示中心の画面
  • フォーム要素が比較的シンプルな画面
  • 既存画面との依存が少ない画面

Composeを導入したい場合、まずはこうした新規画面から始めるのが安全です。

いきなりアプリ全体のUI方針を変えるのではなく、この新規画面はComposeで作るという単位で始めると、チームとしても学習しやすくなります。

既存画面は触るタイミングで移行を検討する

既存画面については、無理にCompose化するよりも、改修タイミングで検討するのが現実的です。

例えば、以下のようなタイミングです。

  • 画面デザインを大きく変更する
  • UI構成を作り直す
  • 既存のView実装が複雑になっている
  • 状態管理を整理したい
  • 今後も継続的に改修が入りそう

こうしたタイミングであれば、Compose化する価値が出やすいです。

逆にほとんど触る予定がない画面や、安定していて大きな課題がない画面を無理に置き換える必要はないと思います。

Compose移行は目的ではなく手段なので、移行することで保守性や開発効率が上がるかを見て判断した方がよさそうです。

部分導入も選択肢になる

Composeは、既存のViewベースの画面へ部分的に導入することもできます。

例えば、XML Viewベースの画面の一部に ComposeView を配置して、特定のUIだけComposeで実装する方法があります。

val composeView = findViewById<ComposeView>(R.id.compose_view)

composeView.setContent {
    SampleContent()
}

また、XML側では以下のように ComposeView を配置できます。

<androidx.compose.ui.platform.ComposeView
    android:id="@+id/compose_view"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

この方法であれば、画面全体を一気にCompose化しなくても、部分的にComposeを試せます。

例えば、以下のようなUIは部分導入しやすいです。

  • バナー
  • カードUI
  • 空状態の表示
  • ダイアログ風のUI
  • 複雑になりすぎた一部のレイアウト

ただし、ViewとComposeが混在すると、状態の受け渡しやライフサイクルの考慮が必要になります。

そのため、部分導入する場合も、
「どの責務をCompose側に持たせるのか」
「状態はどこで管理するのか」
を決めておくとよさそうです。

Composeを導入するときに気をつけたいこと

Composeを導入する場合、単にXMLをComposeに置き換えるだけではなく、状態管理の考え方も少し変わります。

Viewベースの実装では、Viewに対して命令的に値をセットすることが多いです。

textView.text = title
button.isEnabled = enabled

一方、Composeでは状態をもとにUIを再描画する考え方になります。

@Composable
fun SampleContent(
    title: String,
    enabled: Boolean,
    onClick: () -> Unit
) {
    Button(
        enabled = enabled,
        onClick = onClick
    ) {
        Text(text = title)
    }
}

そのため、Composeを導入する場合は、UIの状態をどう表現するかが重要になります。

例えば、ViewModel側で画面の状態をまとめて持つようにすると、Compose側はその状態を受け取って表示するだけにしやすくなります。

data class SampleUiState(
    val title: String = "",
    val enabled: Boolean = false,
    val isLoading: Boolean = false
)

Compose Firstの流れに乗るには、UIの書き方だけでなく、状態管理や画面設計も合わせて整理していく必要がありそうです。

既存プロジェクトでの進め方

既存プロジェクトでComposeを導入する場合、個人的には以下のような進め方がよさそうだと感じました。

  1. 新規画面でComposeを使う
  2. 独立性の高いUIコンポーネントをCompose化する
  3. Previewを活用してUI確認の速度を上げる
  4. 既存画面は大きな改修タイミングでCompose化を検討する
  5. チーム内でComposeの書き方や状態管理方針を揃える

特に重要なのは、最初から完璧な移行計画を作ろうとしすぎないことだと思います。

Composeへの移行は、一気に進めるよりも、新規開発や改修の流れの中で自然に増やしていくくらいの方が現実的です。

小さく導入して、チーム内に知見を貯めていく。
その積み重ねで、結果的にComposeの比率が上がっていく形がよさそうです。

まとめ

Android Developers BlogのAndroid UI Development is Compose Firstを読んで、今後のAndroid UI開発ではComposeを前提に考える場面がより増えていきそうだと感じました。

ただし、既存プロジェクトにおいては、XML Viewベースの画面を今すぐすべて置き換える必要はないと思います。

現実的には、以下のような向き合い方がよさそうです。

  • 新規画面ではComposeを優先的に検討する
  • 既存画面は大きな改修タイミングで移行を検討する
  • 部分導入で小さく始める
  • 状態管理の方針も合わせて整理する
  • Compose移行自体を目的にしない

Compose FirstはXMLをすぐに捨てるという話ではなく、これからのAndroid UI開発でComposeを第一候補として考えるという流れだと捉えるのがよさそうです。

さいごに

謎の風邪が流行っているようですね。
みなさん、どうかお身体ご自愛ください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?