こんにちは、TUNAG事業部のカーキ (@khaki_ngy)です。 普段は TUNAG の iOS/Android などのモバイルアプリの開発を行なっています。
今回は TUNAG の Android アプリ開発における Android View の開発での Jetpack Compose を使ったレイアウトプレビューの活用について、Jetpack Composeの導入理由と併せて紹介していきます。
Jetpack Compose の導入
TUNAG の Android アプリでは Jetpack Compose の安定版がリリースされた2021年末から Jetpack Compose の導入を開始し、新規の View に関しては極力 Jetpack Compose を利用して UI の構築を行なっていました。
当時の背景としては、下記の３点を狙いとしていました。
- よりスピーディーな新機能の提供
- レイアウトプレビューによる開発体験の向上
- 今後のUI開発のバラダイムが変わっていくことを見越して
よりスピーディーな新機能の提供
また Jetpack Compose により宣言的にUIを作成することができるため、直感的に記述することができるようになります。 TUNAG アプリは以前から画面の部品単位でコンポーネントに分けて開発を進めていましたが、Android View を使った開発では一つのコンポーネントを作成するのにレイアウトファイルをいくつも作成しないといけないなど、煩雑さを感じていました。
レイアウトプレビューによる開発体験の向上
Jetpack Compose を導入したことにより作成したコンポーネントをプレビューすることができるようになりました。 以前までの Android View を使ったコンポーネント開発では、作成したコンポーネントの振る舞いが意図した通りになっているかどうかの担保は、テスト用の Activity を作成して、そこに配置してテストをおこなっていました。そのためコンポーネントの開発にプラスして、コンポーネントの確認のために時間と工数を費やしていました。
Jetpack Compose のプレビューには、インタラクティブプレビューやアニメーションプレビューなどの動的な動きを確認する仕組みもあり、かつておこなっていたような検証方法は不要になりました。
今後のAndroidのUI開発のパラダイムが変わっていくことを見越して
宣言型UIフレームワークはモバイルでは Flutter や SwiftUI 、Webフロントエンドの領域では React など、現代のフロントエンド開発における技術トレンドになってきています。 ここ数年での技術の成長や技術コミュニティの成熟などを見るに、この傾向は不可逆なものだと考えています。
導入と現状
現在、新しい画面や新しいコンポーネントの開発には積極的に Jetpack Compose を採用しています。
ただ TUNAG のモバイルグループの開発メンバーのリソースは限られ、既存の View を Jetpack Compose に全て置き換えることはできていません。 本来であれば、既存機能の改修のタイミングで既存コンポーネントのComposable 関数への移行もおこなっていきたいのですが、現状そこまでは取り組むことはできていません。
そんな中で Android View を使用した開発でもJetpack Composeによるプレビューによる恩恵を得たいと考えたのが今回の事例になります。 次項では、ブログタイトルにもある Jetpack Compose のプレビューで AndroidView で作成したコンポーネントをプレビューした事例に関して、背景を踏まえて紹介していきます。
チャット返信機能プロジェクト
直近で私達のチームで Android View のプレビュー化を行ったのは、春ごろにリリースをおこなった TUNAG のチャットの返信機能プロジェクトでした。
TUNAG では制度の利用やその閲覧を行うタイムラインの他にビジネス用のチャット機能も提供しています。この春に追加機能としてチャットでの引用返信や動画送信の機能の開発を行いました。
このプロジェクトでメッセージの表示パターンに引用返信が増えるのに当たって、既存のメッセージのレイアウト自体を改修することになりました。 ここでの改修の際に全て Composable 関数で書き換えるという方法もありましたが、開発期間が短く、着手当時は自分たち自身もそこまで Jetpack Compose に詳しくなかったため、現状動いている Android View をベースに改修を行うことになりました。
Jetpack Compose のプレビューを使用した開発
チャットのメッセージコンポーネントにはそのメッセージの状態や選択された時、引用元のメッセージを含む場合とで数十通りのパターンが存在していました。 今までは実行環境でその状態を作り、意図した通りに表示できているかを確認していましたが、これ以上パターンが増える場合は対応できないと判断しました。
そこで目をつけたのが以前から試験的に導入していた Jetpack Compose のプレビュー機能でした。 Android View で作成したものを Composable 関数でラップしプレビューを可能にすれば、現状の Android View で作成したものを活かしながら、プレビューにより網羅的に状態を把握することができます。
Android Viewで作成されたコンポーネントの Composable 関数として利用するのは、Jetpack Compose の公式ドキュメントとして公開されているこちらの Android Developers ドキュメントの相互運用 APIを参考にして進めました。
上の画像はチャット返信機能着手前の時点で36通りですが、これが返信機能によって倍の72通りに増えています。 プレビューの機能を使用したことで、これだけの状態のパターンを全て網羅的に把握することができるようになりました。
このメリットとしては、「View の網羅的な状態の確認ができる」に尽きると思います。
今回、Composable 関数でのプレビューが導入できたことで、デグレを発生させることなく、安心してリリースを行うことができました。
Compose のプレビューのみを使用するデメリット
これまで良い面を紹介してきましたが、開発時や運用してしばらく経ってみて感じたデメリットがいくつかあるので紹介します。
Android View での状態の変化を随時 Composable 関数の方にも反映させないといけない
今回私たちが行なった手法では、実際にコンポーネントとして使用しているのでは AndroidView であり、プレビューしている Composable 関数自身ではありません。 そのため、Android View で状態が増えた場合に、随時 Composable 関数の方にも反映して同期を取っていかないと正しい状態をプレビューできているとはいえなくなってしまいます。 今後基本的にコンポーネントに関わる変更は、プレビューでの正しい表示により確認をしていくので、問題にはなっていないのですが、二重で管理する必要はあります。
ビルド時間が長い
そもそも今回のプロジェクトで進めていたモジュール自体がかなり大きいということにも原因があると思いますが、今回の対応によりビルド時間が長くなりました。 正確に測っているわけではないですが、体感で感じるレベルで長くなりました。 これは純な Composable 関数ではなく、Android View をラップしたものを扱っているところにも原因があると感じています。
上記のようなデメリットはありますが、それを踏まえた上でも Android View で開発中のコンポーネントの確認ができる今回の手法は有用だと思っています。 開発中にこのプレビュー機能を使用したことで、何度も View の不整合に気付くことができ、即座に修正に取り掛かることができました。 それは今回のような改修プロジェクトで、以前までの表示状態を担保しなければいけないという状況にも合っていました。
今後の展望
今後の展望としては、チャットメッセージに関わる全てのコンポーネントを Composable 関数に置き換えたいと考えています。 もちろん開発プロジェクトとの調整を取りながらにはなりますが、コンポーネント自体を Composable 関数にすることで上で紹介したデメリットもある程度解消されます。 また最初に Jetpack Compose をプロジェクトに導入した経緯でも紹介したように、Composable 関数として扱えることで管理が楽になり、より早く新機能・改善を行うことができると確信しています。 TUNAG のチャット機能はまだまだ機能追加される余地が残っているため、早期に Composable 関数への置き換えができれば、今後の開発をより効率的進めることができます。
今回は Android View で作成したコンポーネントを Composable 化してプレビュー可能にすることで開発を加速させた事例の紹介しました。
途中でも述べましたが、新規作成するコンポーネントに関しては Jetpack Compose を使用して作成しています！
Jetpack Compose を使ってガシガシ開発をしたいという方がいらっしゃいましたらぜひ、弊社採用窓口までご連絡ください。
TUNAGの開発体制、使用技術については下記ブログ記事を参照ください。
また弊社では、オンラインサロン用プラットホーム FANTS というサービスも開発・運営しております。 ご興味がある方はぜひ下記のリンクをご覧ください。
またスタメン Engineering Handbookとして体系的にまとめられたページも公開しています。 こちらも是非ご覧ください。
