はじめに
with で Android エンジニアをしている 石田 です。with の Android 版アプリ (以下、with-android) では Jetpack Compose 1.0 がリリースされる数か月前より導入の準備を開始し、2022年3月現在で導入して半年が経過しました。
この半年間でのアップデートを簡単にまとめるのがこの記事の目的です。Jetpack Compose をプロダクトに導入済みの方もそうでない方も、何かの参考にしていただければ幸いです。
Compose への移行度
with-android では 新規機能の UI には原則 100% Compose を使用するルールにしています。また、既存機能についても隙間時間で地道に Compose 化を行ってきました。「リファクタリング: Compose化」というラベルを付けて管理しています。

その成果として、この半年間でレイアウトの XML は 648個 から 595個 に減少し 約8% がCompose に移行 されました。このペースで行くと、完全移行まであと 6年 ほどかかる計算です。先は長いです。

ちなみに Composable 関数(Preview 関数は除く) の数は 300個 でした。数が多いですが、これは Compose になって UI を容易に分離でき、再利用性が高まったことの表れだと考えることができます。
こちらの記事を参考にすると、Compose への移行度を簡単に調べられるので読者の方のプロジェクトでも試しに計測してみてください☺️
ガイドラインの作成
Compose のコードの書き方を チームで統一したいので、簡易的なガイドラインを Wiki に作成して認識を合わせています。例えば、引数は 1つ 1つ 改行して末尾にはカンマ(Trailing commas)を必ず付けましょうとか、Preview 関数は可能な限り書きましょう、といったルールを定めています。特徴的なところでいうと、UI の分割の方針は Atomic Design を基本としながらも、敢えて厳密には従わず柔軟にやってよいというルールにしています。
メンバーの意見
Compose 導入当初は Compose のコードを書けるのは 私 1人でしたが、現在ではチーム全員が自信を持って Compose のコードを書けるようになりました。メンバーに聞いた Compose 導入の感想を載せておきます。
メンバー: A
大規模なアプリへの導入も簡単に出来ますし、Preview 機能である程度確認できるので実機確認する頻度が減って便利でした！
メンバー: B
✅ Activity/Fragment から UI が切り離された(印象を受ける)のが良かった
✅ 全部 Kotlin で書けるの良い。XML でのプロパティ名は何だ？と調べなくて良い
✅ View ごとに ID を振らなくて良い
✅ リストが(RecyclerViewに比べて)簡単に実現できるのは感動した
✅ Preview がとても楽
✅ アニメーションが楽で良い
⚠️ (Vim使いなので) UI のコードを書くときに空行を入れる文化がないのが少しつらい(コーディング時、前後の空行へのジャンプをよく使っていた)
メンバー: C
✅ Preview を見ながら動作のコードを書けるのがとっても楽に感じます！
✅ パラメーターによって複数の Preview が見えるのもすごくいい！
✅ State という概念が素晴らしい
⚠️ 9-patchを使うのが少し難しい
Compose で困ったこと
Compose はかなり安定していて、謎のクラッシュ等は今のところ皆無です。しかしながら、 TextField 周りでキーボードがちらついて表示される等の不具合が存在するようです。これらの不具合は 1.2.0 で改善されるようです12。そこで、1.2.0 が出るまでは TextField を使わず、やむを得ず Compose の中でテキスト入力が必要な場合は EditText を AbstractComposeView でラップして使っています。
Compose 導入のこれから
半年間の間で Compose が Android アプリ開発において大活躍してくれることは確認済みです。これからの半年~1年の間ではさらなる Compose 化を進めつつ、最近安定になった compose-navigation 等も含め、よりモダンな Android 開発にシフトしていく予定です。