こんにちは！株式会社スマートバンクで今年の8月から Android エンジニアをしております yokomii です。

弊社が配信している家計簿アプリ「B/43(ビーヨンサン)」が、12月9日に新バージョン(v18.0.0)をリリースしました🎉 本リリースには、今後の家計管理機能の拡充を見据えた、「ホーム画面リニューアル＆新カード画面の追加」が含まれています。

今回の主要な画面の再開発にあたり、 AAC(Android Architecture Component) ViewModel の「複雑さを減らす」ことを重要視しました。 ViewModel の詳細な設計方針については、デベロッパーに委ねられる部分が大きいです。

特に意識せずに使っていると、容易に複雑なコードが混入しがちです。本記事が皆様にとって、 ViewModel の設計方針を見直すきっかけとなれば幸いです。

🐶 複雑さを排除する ViewModel の設計方針
終わりに
参考資料

🐶 複雑さを排除する ViewModel の設計方針

1️⃣ UI state を唯一の情報源とする

新ホーム画面の ViewModel では、SSOT(信頼できる単一の情報源)の原則に則り、UI state を UI 状態の唯一の情報源としています。つまり、UI では UI state のみを監視し、それ以外の状態は監視していません。

data class UiState(
    val listItems : List<Item> = emptyList(),
)

class HomeViewModel() : ViewModel() {
    val _uiState = MutableStateFlow<UiState>(UiState())
    val uiState: StateFlow<UiState> = _uiState.asStateFlow()
}

@Composable
fun HomeScreen(viewModel: HomeViewModel) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
    HomeList(listItems = uiState.listItems)
}

情報源が複数存在するだけで、下記のような複雑さにつながる恐れがあります。

状態がどの情報源に含まれるかを知る必要がある
情報源同士で状態を同期するためのロジックが生じる
状態をどの情報源に持たせるべきか検討の必要性が生じる
テストや Compose Preview 用に、情報源のモックを複数用意する手間につながる

あらかじめ情報源を一つに絞っておくことで、これらの複雑さを回避することができます。

2️⃣ UI state を適切な大きさで分割する

UI state を唯一の情報源とすると、UI state が肥大化することで複雑さにつながる恐れがあります。それを回避するため、 UI state を一定の大きさで分割しています。ここでいう「分割」とは、「情報源を増やす」という意味ではなく、情報源内の「状態を分ける」という意味です。

分割方法は下記の2種類があります

表示 UI 単位で分割する
画面の表示状態単位で分割する

表示 UI 単位で分割する

新ホーム画面には主に下記のような UI があります

これらのUIごとに UI state クラスを生成し、画面の情報源となる側の UI state でそれらを包含します。

data class HomeBannerUiState(
        val icon: B43Icon,
        val title: String,
        val description: String,
)

data class UiState(
    val banner : HomeBannerUiState,
    val monthlySummaryPanel : HomeMonthlySummaryPanelUiState,
    val cardPanel : HomeCardPanelUiState,
    val timeline : HomeTimelineUiState,
)

class HomeViewModel(
      bannerRepository: BannerRepository,
      monthlySummaryRepository: MonthlySummaryRepository,
      cardRepository: CardRepository,
      timelineRepository: TimelineRepository,
) : ViewModel() {
...
        private val banner = bannerRepository.get()
            .map { HomeBannerUiState(it) }
        private val monthlySummaryPanel = monthlySummaryRepository.get()
            .map { HomeMonthlySummaryPanelUiState(it) }
        private val cardPanel = cardRepository.get()
            .map { HomeCardPanelUiState(it) }
        private val timeline = timelineRepository.get()
            .map { HomeTimelineUiState(it) }

    init {
            combine(
                    banner, monthlySummaryPanel, cardPanel, timeline
            ) { -> banner, monthlySummaryPanel, cardPanel, timeline
                    _uiState.update{ it.copy(banner, monthlySummaryPanel, cardPanel, timeline) }
            }.launchIn(viewModelScope)
}

各 UI の状態管理の責務を適切に分離することで、拡張容易性や、テスト容易性の向上にも繋がります。

画面の表示状態単位で分割する

画面の表示状態によっては、不要な UI 状態が存在することがあります。例えば、データのロード中に Progress indicators だけが画面に表示されているようなときは、その他の UI の状態は実質不要となります。このように「画面に表示される UI の差異」を境界として、UI state を分割します。

sealed interface UiState {
        data object Loading : UiState

        data class Success(
            val banner : HomeBannerUiState,
            val monthlySummaryPanel : HomeMonthlySummaryPanelUiState,
            val cardPanel : HomeCardPanelUiState,
            val timeline : HomeTimelineUiState,
        ): UiState

        data class Error(val e: B43Exception) : UiState
}

こうすることで、各 UI state の関心と責務を分離することができます。

ただしこの分割によって、「とある UI 状態を更新したい」ときに、「その状態が現在の UI state に含まれているか」を都度確認する必要性が生じます。

class HomeViewModel() : ViewModel() {
        fun dismissBanner() {
                val currentState = _uiState.value
                // 現在の UI state を確認
                if(currentState is UiState.Success) {
                        currentState.banner.dismiss()
                }
        }
}

ボイラープレートコードを回避するために、ViewModelState というフラットな状態クラスを別途用意しています。状態の更新は ViewModelState に対して実行し、ViewModelState を UI state に変換することでこの問題に対処しています。

data class ViewModelState(
        val banner : HomeBannerUiState? = null,
    val monthlySummaryPanel : HomeMonthlySummaryPanelUiState? = null,
    val cardPanel : HomeCardPanelUiState? = null,
    val timeline : HomeTimelineUiState? = null,
    val e: B43Exception? = null,
) : ViewModel() {
        fun toUiState() : UiState {
                return when {
            e != null -> UiState.Error(
                e = e,
            )
            banner != null &&
                monthlySummaryPanel != null &&
                cardPanel != null &&
                timeline != null &&
            -> UiState.Success(
                banner = banner,
                monthlySummaryPanel = monthlySummaryPanel,
                cardPanel = cardPanel,
                timeline = timeline,
            )
            else -> UiState.Loading
        }
        }
}

class HomeViewModel(...) {
        private val viewModelState = MutableStateFlow(ViewModelState())
        private val uiState = viewModelState.map { it.toUiState() }

        fun dismissBanner() {
                viewModelState.value.banner?.dismisss()
        }
}

この手法は compose-samples/JetNews でも用いられています。

3️⃣ StateFlow の多用を避ける

「UI state を唯一の情報源とする」の項で述べたように、情報源が複数存在すると、それだけでコードの複雑性に繋がります。 StateFlow は value をキャッシュする情報源であるため、多用することで複雑さの原因となります。

例えば、下記のような StateFlow から別の StateFlow に変換するようなコードがあるとき、変換後の StateFlow の状態のみを更新して、変換前の StateFlow の状態を更新し忘れるなどの不具合につながる恐れがあります。

data class UiState(val isLiked: Boolean)

class MyViewModel(likeRepository: LikeRepository) : ViewModel() {
    val isLiked = MutableStateFlow<Boolean>(false)
    val uiState = MutableStateFlow<UiState>(UiState(false))

    init {
        isLiked.onEach { uiState.value = UiState(it) }
            .launchIn(viewModelScope)

        load()
    }

    fun load() {
        isLiked.value = likeRepository.isLiked()
    }

    fun updateLike(isLike: Boolean) {
        uiState.update { it.copy(isLiked = isLike) }
    }

    // updateLike() による状態変更が反映されていない
    fun isLike() = isLiked.value
}

StateFlow を新しく ViewModel に追加する際には、本当に情報源を増やすべきか、慎重に検討する必要があります。情報を保持しておく必要がないのであれば、 SharedFlow に置き換えるなどの対応をしましょう。

4️⃣ Flow.combine の常用を避ける

Flow.combine は Flow のデータを合成する上で便利な関数ですが、思わぬ不具合に繋がりやすいです。下記は Flow.combine によって、各種アプリデータを待ち合わせた後に、 ViewModelState を更新する例です。

sealed interface Result {
    class Success<T>(value: T) : Result
    class Error(e: B43Exception): Result
}

class CardViewModel(
        userRepository: UserRepository,
      cardRepository: CardRepository,
) : ViewModel() {
...
        private val user: Flow<Result> = userRepository.get()
        private val card: Flow<Result> = cardRepository.get()
        private val error: B43Exception = merge(
                user.filterIsInstance<Result.Error>,
                card.filterIsInstance<Result.Error>,
        ) { it.e }

    init {
            combine(
                    user.filterIsInstance<Result.Success<User>>.map{ it.value },
                    card.filterIsInstance<Result.Success<Card>>.map{ it.value },
                    error,
            ) { -> user, card, error
                    _uiState.update{ it.copy(user, card, error) }
            }.launchIn(viewModelScope)
    }
}

Flow.combine は、すべてのFlowが少なくとも1つ値をエミットするまでは合成をしません。つまり上記のコードでは、 Result が Success と Exception の両条件になることはあり得ないため、 ViewModelState が永遠に更新されません。

その対処として、合成される Flow 側で必ず何らかの値を返す方法があります。

private val error: B43Exception = merge(
        user.filterIsInstance<Result>,
        card.filterIsInstance<Result>,
) { if(it is Result.Error) it.e else null }

しかし、「合成される側」が「合成する側」の実装に合わせて振る舞いを変更することになり、間接的な依存関係が生じてしまいます。また、局所的に対処しても、他にも同様の「値を常に返さない Flow」が生まれる可能性が十分あり得ます。

そのため新画面においては、 Flow.combine で待ち合わせる Flow を限定することにしました。具体的には、画面の初期表示時に必要なデータのみを Flow.combine で待ち合わせて、それ以外は別のオペレーターを用いています。

class CardViewModel(...) : ViewModel() {
...
        init {
                // 初期表示のデータのみを combine
            combine(
                    user.filterIsInstance<Result.Success<User>>.map{ it.value },
                    card.filterIsInstance<Result.Success<Card>>.map{ it.value },
            ) { -> user, card
                    _uiState.update{ it.copy(user, card) }
            }.launchIn(viewModelScope)

            // 常に発生し得ないエラーは個別に処理
            error.onEach { e -> viewModelState.update { it.copy(e = e) } }
            .launchIn(viewModelScope)
        }
}

コードの記述量は増えますが、関係を疎に保ったまま安全に待ち合わせができます。

5️⃣ 初期化処理を `SharedFlow.onSubscription` で実行する

ViewModel で初期化処理を実行するメジャーなトリガーポイントとして、下記の二箇所が挙げられます。

ViewModelの init ブロックで実行
UI のライフサイクルイベント (Compose の LaunchedEffect など) で実行

これらの方法には、下記のメリデメが存在します。

実行箇所	メリット	デメリット
ViewModel.init	トリガーポイントが ViewModel 内に収まる	実行タイミングが UI ライフサイクルとずれる
LaunchedEffect	UI ライフサイルに密接した実行タイミング	構成の変更などでリコンポーズが生じた際に、不要な再実行が発生する可能性がある

これらのデメリットによる問題は、パフォーマンスを意識するようになる開発終盤に顕在化しがちです。問題を未然に防ぐため、別のトリガーポイントとして、 SharedFlow.onSubscription() を採用しています。

class HomeViewModel(...) : ViewModel() {
...
    val uiState: StateFlow<UiState> = viewModelState
        .onSubscription {
                // 初期化処理
                initLoad()
        }
        .map { it.toUiState() }
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), viewModelState.value.toUiState())

    private fun initLoad() { ... }
}

@Composable
fun HomeScreen(viewModel: HomeViewModel) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
    HomeContent(uiState = uiState)
}

Flow.stateIn の started 引数に SharingStarted.WhileSubscribed を設定することで、最初の Subscriber が現れるまでロードを遅延できます。この Flow を collectAsStateWithLifecycle() で監視することで、UIライフサイクルに紐づいた実行が可能となります。

また、SharingStarted.WhileSubscribed の引数の stopTimeoutMillis に5000ミリ秒を設定することで、Subscriber がいなくなっても5秒間はストリームが継続します。それにより、画面回転などで再 Subscribe されても初期化処理の再実行を防ぐことができます。

この手法は nowinandroid でも用いられています。

このように処理を整えておくことで、安定した初期化処理実行が可能となります。ただし、コードの可読性はメジャーな手法群に劣るため、チームでの合意やドキュメント化が重要です。