ログ簿の Android UI を Jetpack Compose にリライトした話

Flutter 移行に踏み切る前、ログ簿のネイティブ Android UI を Jetpack Compose へ全面リライトしていました。宣言的 UI に寄せておくことは、後の Flutter 移行の下地としても効いたと感じています。本記事では、その進め方を残します。

画面単位で少しずつ移行する

一気に全部を書き換えるのではなく、画面（Screen）単位で段階的に移行しました。ゲーム一覧、詳細、更新、イベント、統計、設定……と、1画面ずつ Compose に置き換え、動作を確認してから次へ進む方式です。これにより、途中でもアプリは常に動く状態を保てました。

Route と Screen を分離する

移行中に導入して効果が大きかったのが、Route と Screen の分離パターンです。

• Route … 画面遷移と ViewModel の取得・状態収集を担う層
• Screen … 受け取った状態とコールバックだけを描画する純粋な Composable

こうすると Screen が ViewModel に直接依存しなくなり、プレビューやテストが書きやすくなります。状態を引数で受け取り、イベントをコールバックで返すだけの Screen は、見通しがよく再利用も効きます。

旧レイアウトの撤去

すべての画面を Compose に移し終えたら、旧レイアウト（XML）と使われなくなったライブラリを撤去しました。移行期は新旧が同居して依存が膨らみがちなので、最後の「掃除」でビルド構成をすっきりさせるところまでを一区切りとしています。

Compose 化してよかったこと

• UI の状態がコードから追いやすくなり、条件分岐の多い画面ほど恩恵が大きかった。
• 宣言的 UI に慣れたことで、その後の Flutter への移行がスムーズになった。発想が近いので「この画面は Flutter だとこう書く」というイメージがすぐ湧く。

まとめ

大きめの UI リライトは、画面単位の段階移行と状態を持たない Screen への分離の二点を守るだけで、リスクを抑えつつ進められます。そして Compose で宣言的 UI に慣れておくと、Flutter などクロスプラットフォームへ移る際の学習コストも下げられます。ログ簿はこの後、Flutter への移行へと進みました。