【イベントレポート】Jetpack Composeの課題〜モバイルアプリの品質改善を考える〜
皆さん、こんにちは！
ぶっちゃけ系エージェント、ROSCA広報のSahoです。
5月13日（月）に弊社ROSCAが運営する「ROSCAFE」にて「Jetpack Composeの課題〜モバイルアプリの品質改善を考える〜」を開催しました！
この記事では企画・運営、そして当日のモデレーターを勤めました私、Saho@ROSCA広報目線でイベントの様子をお伝えしたいと思います。
「Composeと仲良くなりたい」gumioさん 株式会社mikan Androidエンジニア チームリーダー
最初のLTは株式会社mikanのgumioさんです。
Jetpack Composeを2021年6月頃に導入した当時はComposeのベータバージョンが終了したばかりで、導入初期には多くの試行錯誤が必要だったようです。その後、約3年間にわたってComposeを使用し続け、新規開発だけでなく既存プロジェクトの移行も進め、現在では約7～8割がComposeに移行完了しています。
Jetpack Composeの大きなメリットの一つは、その自由度の高さです。Composeは関数としてUIを定義できるため、非常に自由度が高く、開発者は様々な書き方が可能です。その反面自由度が高いため、開発チームでルールを定める必要があるとgumioさん。
また、Composeはモデルの関心事をUI実装から切り離すことができるため、UI実装に集中でき、テストも容易になります。これにより、役割分担がしやすくなり、開発効率が向上します。特にプレビュー機能の活用により、リアルタイムでUIの確認ができ、ビルド時間の短縮が可能になる点が非常に有益だそうです。
一方で、Composeのデメリットとして、イベント処理関数がルートから渡されるため、コードの分量が多くなる点が挙げられましたが、そこまで大きな問題ではないとのこと。また、画面を構成する各コンポーネントをどの粒度で分けるかが課題となるため、最小限の粒度で切り分けることを意識しています。
具体的な使用例として、共通のコンポーネントをモジュールに集約し、各画面で使用するコンポーネントはそれぞれの機能に特化して配置することが推奨されました。さらに、プレビューコンポーネントには「プライベート」を付けることで、他のコンポーネントと区別しやすくしています。各スクリーンに全てを書き込む「ゴッドスクリーン」を避けるために、コンポーネントを分割し、各メンバーが作成しやすいようにすることも重要です。
試行錯誤は必要ですが、効率的なUI開発が可能になることから、まだComposeを導入していない開発チームに対しても、ぜひ導入を検討してほしい！という熱いLTを発表していただきました。
「Jetpack Composeとデザインシステム」牧山 瞭さん 株式会社Kyash Engineering Manager (Mobile team)
続いてのLTは株式会社Kyashの牧山さん。Jetpack Composeの導入は2021年5月頃から開始し、現在ではKyashのデファクトスタンダードとなっています。既存の画面はまだ完全には移行されていませんが、新規実装の画面はほぼ全てComposeで開発されています。新しい予算管理やリワードの画面がComposeで実装されていて、これらの機能がとてもおすすめだそうです。
次に、デザインシステムについての説明です。Androidにはマテリアルデザインというデザインシステムがあり、Composeを使用すると簡単にデザインシステムを構築できると公式ドキュメントに記載されています。しかし、実際にはプロダクトにデザインシステムを導入するのは簡単ではないと考えているそうです。テーマ設定やコンポーネントの分割など、設計と同様に唯一の正解がないため、悩むことが多いようです。
Kyash社では、マテリアル2をベースとしたデザインシステムを採用しています。これにより、既存のマテリアルコンポーネントを利用しつつ、独自のコンポーネントも実装しています。KyashにはKyash Interface Guideline（KIG）というプロダクトとしての一貫性を保つためのガイドラインが存在し、これに従って実装が進められています。KIGは日々進化しており、デザインシステムもそれに追従しています。
具体的な実装例として、カラーシステムの置き換えについて説明がありました。マテリアルコンポーネントは内部的にマテリアルテーマのカラーを使用しているため、KIGに定義されているものと互換性を持たせるようにしています。独自のシステムであるスペーシングについても説明があり、これはマテリアルシステムには存在しない概念であるため、CompositionLocalを活用して定義しているそうです。
さらに、ボタンの実装方法についても説明いただきました。マテリアルコンポーネントを利用することで、disable状態なども適切にカバーされています。これにより、開発効率が向上し、一貫性のあるデザインを保つことができます。また、TextコンポーザブルではなくStringを受け取るようなコンポーネントも新たに用意することで、ベーシックなスタイルをイージーに利用できるようにし、一貫性が失われることを防いでいるそうです。
「Compose Multiplatformを(頑張って)乗りこなす」坂上 晴信さん 株式会社TOKIUM DevHR
最後のLTはTOKIUM社の坂上さん。Compose Multiplatformの導入により、単一のコードベースで複数のプラットフォームに対応できるという大きなメリットについて紹介いただきました。しかし、導入にはいくつかの課題も伴います。特に、Android以外のプラットフォームに関する情報が少なく、動作検証の対象が多いため確認の労力が増える点があげられました。また、UIプレビュー機能に制限があり、JetBrains Fleetでしか動作しないという制約もあります。
次にCompose MultiplatformのUIテストをどのように実装し最適化するかについて説明いただきました。基本的なUIテストコードの例を示し、ボタンをクリックしてテキストが変化するシンプルなテストから始めました。次に、テスト環境の設定方法を詳述し、テストコードを共通ディレクトリに配置し、Gradleファイルを編集して必要な依存関係を追加する手順を紹介しました。
UIテストの実行には、実機テストとローカルのJVM上でのテストがあります。実機テストは実行コストが高く、継続的なインテグレーション環境ではリソースを大量に消費するため、ローカルのJVM上でテストを実行することが推奨されます。坂上さんは、Android向けのテストをローカルのJVM上で実行するための具体的な方法を紹介し、JUnit4とTestRunnerのカスタマイズを通じてこれを実現しました。
Compose Multiplatformを活用することで、クロスプラットフォーム開発の効率を大幅に向上させることができるそうです。UIテストを自動化することで品質の維持と向上が図れること、具体的な実装例と共に実績を積み重ねることの重要性を説明していただきました。
今回のイベントは150名を超える方に申し込みいただき、非常に活気のあるオンラインイベントとなりました！！改めまして登壇者の皆様、ご参加いただいた皆様、ありがとうございました！
今回も、最後までお読みいただきありがとうございました！
また次回の記事でお会いしましょう！
ROSCAでは、エンジニアに最適なキャリアを選択してほしいという思いから知識を持ったキャリアアドバイザーが毎日厳選したクライアントのみに絞ってお仕事のご支援をさせていただいております。
少しでも関心をお持ちいただけましたら、ぜひお問合せください。
ROSCAの話を詳しく聞きたい！興味があるという方はこちらの募集からどうぞ！
この記事が気に入ったらサポートをしてみませんか？