最近、Androidのアプリ開発においてJetpack Composeを使用する機会が増えました。
ということで、私が特に現場でJetpack Composeを使用してみて感じた（ている）ことを書いていこうと思います。(2022/6/24時点の感想）
知識不足で間違っている点あればご指摘ください。
良いと感じている点
レイアウトの変更・管理がしやすい
- Kotlinコードでレイアウトを書いていくので、個人的にXMLベースよりコードのネスト構造が浅くなる（りやすい）傾向があります。
- Kotlinコードで管理するので、XMLファイルといった形式の異なるレイアウトファイルを管理する必要がほぼなくなります。見るのがKotlinコードに一元化されるので管理がしやすいです。
- 同じKotlinファイル内に複数のComposable定義を記述できるのでグルーピングしたい時とか便利
個人差はあるので、上記はいまいちピンと来ない方がいるかもしれませんが、XMLよりKotlinに慣れ親しんでいるエンジニアは頷けると思います。
状態に応じたUIの出しわけがやりやすい
その時の状態に応じたUIを宣言的に記述するというのがJetpack Composeの思想なので、やはりUIの出し分けを見通しよく表現することに優れています。UI出し分けの実装漏れとかは少なくなります。
LazyColumnが便利
何気に一番感動した点かもしれません。
RecyclerViewやListViewを使っていた頃は、AdapterクラスやXMLレイアウトの作成などが必要でしたが、Jetpack ComposeではLazyColumnを使えば一瞬で終わります。リスト形式のViewを作成する工数大幅減。
使いづらいと思っている点
UI開発が飛躍的に向上するとは限らない
LazyColumnとか開発速度が向上するようなコンポーネントもありますが、XMLファイル時代と比べて開発速度が飛躍的に向上したかと言われると、そんなに変わっていない気がします。
シンプルなUI開発は確かに早く作れますが、UIにこだわったアプリなどはComposeといえどある程度レイアウトの作り込みが必要なので、結局それなりの時間がかかります。
Preiview機能によるレンダリングに時間がかかる
XMLレイアウトのプレビューのレンダリングの方がやっぱり早いので、若干ストレスです。
既存のAndroidViewに比べてAPIが不足している
標準のCompose APIでは実現が大変なUIは結局自前で実装になる
- CoordinatorLayoutチックなUIを表現する標準APIが見当たらない。NestedScrollConnectionを使用すれば模倣できますが、自前の実装が多くなり管理が大変です。
- その他、Scaffoldベースだとカスタマイズがきついので、結局自前で作ったりしがち。
XMLやAndroidViewベースでサポートされていた機能がサポートされていなかったりする
- Textに対してカスタムフォントを適用するときに、XMLのTextViewでいうところのincludeFontPadding属性とかが見当たらなくて困った
- まだ新しいツールなので、ここら辺のサポートはまだまだ足りない
上記のような事象が発生したらプロダクトオーナーに事情を説明して許容してもらったりしました。
毎回State(状態)管理するのもだるい
TextFieldの入力文字列やダイアログの表示制御など、逐一State管理する必要があるのでさっと動きを確認したいときや単純な画面を作りたい時など面倒に感じることがあります。
Application（Activity）のライフサイクルに応じたCompose上の処理制御が難しい
以下の記事とかで対応方法は書いてあったりしますが、ActivityとComposeのライフサイクルは１対１に紐づいているわけではないので、管理が難しいです。
https://stackoverflow.com/questions/66546962/jetpack-compose-how-do-i-refresh-a-screen-when-app-returns-to-foreground
新規プロジェクトでJetpack Composeを導入する際に配慮したいこと
自社サービスとかならアプリ設計の融通はある程度聞くかもしれませんが、受託開発ではそうもいかないこともあります。そんなときに予め注意しておきたい点は次のようなものが挙げられると思います。
メンバー全体の開発レベルを考慮する
今までXMLに慣れ親しんだエンジニアにとってはパラダイムシフトになるので、キャッチアップするにはそれなりのコストがかかります。キャッチアップコストが開発コストに見合わないようであれば、Composeの採用を見送ることも考えないといけません。
素養のある人ならすぐキャッチアップできるかもしれませんが、最低２週間くらいの学習期間は見ておいた方がいいかも。
Jetpack Composeでアプリ要件を満たしたUI開発ができることを最低限検証しておく
最悪、基本的なRowやColumnのようなコンポーネントを組み合わせれば、事実上どのようなUIでも実現はできそうですが、開発コストに影響します。
- 前述のCoordinatorLayoutなど、まだまだ以前のAndroidViewを使用した方が楽に実装できるUIパターンもありますので捨てたものではありません。
- アプリによっては、アプリの操作ログを画面のライフサイクルに応じて記録したりすることがあると思います。そのようなときに、Composeを使用しても無理なく実装できるか最低限シミュレーションしておいた方が良いです。
- Composeのライフサイクルを事前に学習しておかないと結構ハマります（ON_CREATEの呼ばれるタイミングとか、LaunchedEffectでの処理制御とか）。コストに余裕がないのであれば、マルチActivity（1Composable(Screen):1Activity)で行った方が良い場合もあると思います。ライフサイクル制御が難しい部分や、些細なState管理が面倒な部分はActivityに処理を委譲してしまうのも一つの手段です。
Jetpack Composeは今後さらに広まるのか
なんかネガティブな点を結構書いておいてなんですが、なんだかんだ広ま（ってい）るんじゃないでしょうか。
やはり、ロジックもUIも同じKotlinベースで管理できるのは楽です。あとLazyColumnが素晴らしい。
前述のデメリットに対する対応案は日々Tipsが溜まって行くと思いますし、あまり悲観はしていません。
APIがまだまだ不足していますが、Jetpack Composeの開発は盛んに行われているので、2~3年後くらいにはその不足もかなり解消しているような気がします。