1
/
5

エンジニアブログ「献立詳細画面で使っていたFlowの処理をtransformオペレータで書き直した日記」

こんにちは、AndroidエンジニアなのかFlutterエンジニアなのか蕎麦屋なのか分からない男、そば屋です。

献立機能を強化しよう!と言うことでこれまでWeb(WebView)限定となっていた「献立検索」を ネイティブ実装しました。

するとどうでしょう、前回の記事に書いた献立詳細画面にもう一パターン別のAPI呼び出しが入ると言うではありませんか

前回同様に

private val menuResponse = repository.getMenu(menuId).stateIn(viewModelScope, SharingStarted.Lazily, null)
private val aiResponse = repository.getAiMenu(menuId).stateIn(viewModelScope, SharingStarted.Lazily, null)
private val searchResponse = repository.getSearchMenu(menuId).stateIn(viewModelScope, SharingStarted.Lazily, null)

のようにSharingStarted.Lazilyにしてしまい。

購読側で

when (献立のタイプ) {
自分で作った -> 元からの処理(menuResponseを購読)
AI -> 前回作った処理(aiResponseを購読)
献立検索 -> 今回作る処理(searchResponseを購読)
}

とすれば別に動作に問題は起こりません

が、購読側のUI処理でEpoxyのControllerにデータを渡すのに 一度、3個に分かれて購読処理を呼び、再度共通のUI処理を呼ぶとエレガントじゃない気がします。

さらにパターンが今後も増える不安を感じる事も事実としてあります。

ふと、DroidKaigiにFlowでセッション応募したことで再勉強を始めた時に書いた記事に transformオペレータと言うものがあった事を思い出しました。これで勝つる

ViewModelの実装をtransformオペレータを使って書き直す!

Before

class ViewModel(val menuId: Int) : ViewModel(), KoinComponent {
private val repository: Repository by inject()
private val menuResponse = repository.getMenu(menuId).stateIn(viewModelScope, SharingStarted.Lazily, null)
private val aiResponse = repository.getAiMenu(menuId).stateIn(viewModelScope, SharingStarted.Lazily, null)
}

After

class ViewModel(val menuId: Int) : ViewModel(), KoinComponent {
private val repository: Repository by inject()
private val menuType = MutableStateFlow<MenuType?>(null)

        val menuResponse: StateFlow<Response<MenuResponse>?> = menuType.transform { value ->
        val respnse = when (value) {
        MenuType.AI -> menuRepository.getAiMenu(menuId)
        MenuType.MENU_SEARCH -> menuRepository.getSearchMenu(menuId)
        MenuType.MINE -> menuRepository.getMenu(menuId)
        else -> null
       }
       emit(respnse)
        }.stateIn(viewModelScope, SharingStarted.Eagerly, null)

       fun setMenuType(menuType: MenuType) {
       menuType.value = menuType
        }
}

・enumで献立の種類を表すMenuTypeを新設
・MenuTypeをセットするStateFlowであるmenuTypeを新設
・menuTypeが変更された時に実行されるようにtransformオペレータをセット
・献立の種類(MenuType)によって呼び出すAPIを切り替えて結果をemit

Fragment

viewModel.setMenuType(MenuType.AI)

viewModel.menuResponse.flowWithLifecycle(viewLifecycleOwner.lifecycle).onEach {
// UI処理
}.launchIn(viewLifecycleOwner.lifecycleScope)

FragmentはSafeArgsで受け取った献立の種類をViewModelに教えてあげるだけで、 勝手に適当なAPIを呼び出して結果を返してもらえるので、購読先の分岐もなくなりスリムになりました。

最後に

完全にオシャレかつエレガントに作ることができました。 少し(かなり?)背伸び気味にDroidKaigiのセッションに応募し、 焦って学び直した結果生まれたコードなので学ぶと結果は返ってくると言う証明になりました。 ※セッションは不採択となってしまいましたが、勉強をしなおすきっかけになったので良い経験でした。筋肉は裏切らない。

おいしい健康では、モバイル(iOS/Android)、Web、機械学習と様々な職種のエンジニアが働いています。エンジニアブログでは、おいしい健康のエンジニアメンバーが日々どんな課題に向き合っているのかを綴っています。過去のブログもありますので、ご興味ある方はぜひこちらも覗いてみてください。

https://oishi-kenko.hatenablog.com/

おいしい健康では一緒に働く仲間を募集しています
5 いいね!
5 いいね!
同じタグの記事
今週のランキング