はじめに

こんにちは！ディップ株式会社でAndroidエンジニアをしている吉田です。主にバイトルNEXTアプリの開発を担当しています。

バイトルNEXTは主に正社員案件を取り扱う求人広告サービスです。私自身dipに正社員として転職して働いているので、求職者であるユーザーや雇用主であるクライアントの課題に当事者の気持ちで共感しながら、課題解決のため日々エンジニアリングに向き合っています！

前置きはさておき、みなさんはJetpack Composeの導入を進めていますか？バイトルNEXTでは一部の画面のリニューアルに伴って、Jetpack Composeの導入を行いました。

入社1年目の新卒や、初めてJetpack Composeを触るメンバーもいる中で安定した運用をするために工夫したポイントと、実際に使ってみての効果や感想を記事として書き起こしてみましたので、ぜひ最後までお付き合いください🙇

対象の読者

Androidアプリエンジニアの方
Jetpack Composeの導入について興味がある方
宣言型UIについて興味がある方

Jetpack Composeについて

AndroidのUIを宣言的に記述できるUIツールキットです。 ”Compose”と略されることが多いです。

2021 年 7 月 28 日にStable版がリリースされました🚀

Compose以前からある旧来のUIツールキットは”Android View”と呼ばれていて、Androidアプリ開発ではAndroid ViewからComposeに移行することの関心が非常に高まっていると感じています。実際に商用プロダクトへ導入された事例も増えています。

導入の動機

優れたものとしてトレンドになっていて、その恩恵を受けたかった

Composeのリリース以前から、宣言型UIはGUIアプリケーション開発のトレンドとして受け入れられていました。

レイアウトと振る舞いの記述を半ば強制的に分断される命令型UIよりも、

分断が少ないので人間がコードを記述しやすい
UIの振る舞いや状態の表現が、より明確になる
結果的に開発効率や開発体験の向上に繋がっている

というところが大きな要因だと解釈しています👀

バイトルNEXTにおいても、旧来のAndroid Viewから移行することで保守性と開発速度を上げられるのでは、という期待感がありました。

プロダクトの性質上、投資効果が高そうだった

Android Viewにおけるリスト表示はかなり複雑でした。

メモリ効率の問題を解消するためにUIを使い回す思想があり、それを実現するRecyclerViewというUIコンポーネントが用意されています。

これを用いたリスト表示には、LayoutManager、Adapter、ViewHolderなどの実装が必要です。実装ファイルが多く使用言語もバラつくため、認知負荷が高い実装になりやすいです。

他所からAndroid開発にスライドしたエンジニアは、リストUIの実装でRecyclerViewと邂逅して一度衝撃を受けるのではないかなと思います…😇

弊社のプロダクトは、求人リストを表示した上で、そこに広告枠やレコメンドを差し込む機能を持っています。要するに、リスト表示の制御がソフトウェアの重要な仕事の一つになっています。これが複雑で難しいAndroid Viewの性質は、サービスのボトルネックと言って差し支えないと考えています。

RecyclerViewのコンポーネント構成図

一方、Composeでリスト表示するLazyColumnは、ほぼKotlinのみで完結して実装ファイルが膨らみづらいので、従来と比べて複雑さを抑えやすいです。

Android ViewとJetpack Composeの比較w650

Composeへ移行することで、求人の表示機能の保守運用がしやすくなり、新規施策も実装コストを抑えて実現しやすくなることが想像できます。

プロダクトチームのアジリティや持続可能性を高める上で有効な技術投資になるのではないかという期待も、導入の動機として大きかったです。

プロダクトへの導入

以降のセクションでは、バイトルNEXTでのCompose導入の取り組みの一部として、UIの分割指針を紹介します。

前提

技術スタックとソフトウェアアーキテクチャについては

Jetpack Compose + AACのViewModel + Dagger Hilt
Google公式が推奨している MVVM + レイヤードアーキテクチャ

の構成を前提とした解説になります。

また、画面を丸々リニューアルするプロジェクトだったため、Viewを部分的かつ徐々に置き換える話は本記事では出てきません。ご了承ください🙇

UIの分割指針について

Composeの導入にあたって、FatなUI実装が量産されたり、UIの組み方に個人差が出て保守しづらくなる問題を防ぐために、UIの分割指針を定めたいと考えました。

Atomic Designが真っ先に浮かびましたが、以前Webのフロントエンドで実践した際に「分割ルールが難しい」「エンジニア間で分割粒度が揃いにくい」という具合で、うまく扱い切ることができませんでした。そのため、Atomic Designの採用には抵抗がありました。

これに関してはDroidKaigi 2023の構成と、リポジトリに上がっていたIssueが大変参考になりました。

バイトルNEXTではこれに倣って、

Screen/Content
Section
Component

という、大きく３層に分ける分割指針を取ることにしました。

バイトルNEXTアプリにおける、それぞれの層の指針について解説します。

Screen/Contentについて

最も大きいコンポーネントです。１画面全体に相当するものです。

実装では、一つの画面のをScreenとして定義して、同一ファイル内にprivateな関数でContentを書いています。

Screenが”枠”で、Contentが実際にコンテンツの表示を受け持つ”中身”のような関係です。

バイトルNEXTでは以下のような実装パターンに落ち着いています。

@Composable
fun XXScreen( // SuffixにScreenをつける
    viewModel: XXViewModel = hiltViewModel()
) {
    // ViewModelからUiStateを取得
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    XXContent(
        uiState = uiState,
        onClick = { viewModel.XXX() } // イベントホイスティング
    )
}

@Composable
private fun XXContent( // SuffixにContentをつける
    uiState: HogeUiState,
    onClick: () -> Unit
) {
    Scaffold(
        topBar = { ... },
        .
        .
    ) {
        Column(
            modifier = Modifier.clickable{ onClick(...) }
        ) {
            XXSection(uiState = uiState)
            Spacer()
            YYComponent(
                modifier = Modifier.clickable{ onClick(...) }, 
                name = uiState.name
            )
            Spacer()
            .
            .
            .
        }
    }
}

@Preview
@Composable
fun XXScreenPreview() { // エラーでプレビュー不可
    XXScreen()
}

@Preview
@Composable
fun XXContentPreview() { // プレビュー可能
    XXContent(
        uiState = XXUiState(),
        onClick = {}
    )
}