AndroidでMVIアーキテクチャを使う

Android 開発 MVI アーキテクチャ

droidKaigi2018でMVIという単語を知り、実際に使ってみました。まだまだ勉強中なので、適宜ご指摘お願いします…。

MVIアーキテクチャとは

Model - View - Intent の3つを中心として、データを単一方向のストリームとして扱います。IntentはAndroidのIntentではなく、ユーザからの操作やリクエストのような意味です。Fluxアーキテクチャに似たところがあり、開発でReduxなど使われている方は理解が早いと思います。

droidKaigi2018で発表されていたスライドがこちらです。サンプルコードと合わせて読むとほぼ理解できると思います。
Android における Model-View-Intent アーキテクチャ // Speaker Deck

サンプルコードがこちらです。 github.com

スライドに出てくる核となるパーツ郡

  • Intent
    ユーザー視点からのやりたいこと、操作を詰める

  • Action
    システム視点からのやりたいことを詰める

  • Processor
    非同期処理など実際の処理を行い、結果をResultとして返す

  • Result
    処理の結果を詰める

  • Reducer
    Resultを受け取り、必要に応じてStateを変化させる

  • State
    画面の状態を詰める

  • render
    Stateを受け取って、必要に応じて描画処理をする

よかったこと、よくなかったこと

  • データの流れが把握しやすい
    Fluxと同様にデータの流れが単一方向に絞られる事で、処理のイメージがしやすいです

  • それぞれの層でのやりたい事に集中できる
    上記パーツ郡のように処理を細かく区切った事で、それぞれがやる事が明確になりました。また、非同期処理やライフサイクルによる問題も吸収してくれて、考える事が少し減りました。

  • テストしやすい
    素早くFragmentから切り離され、処理が細かい関数に分かれているので、それぞれのテストがしやすいです。

  • コードの分量は多め
    ViewModelが担当する区域が広いので、ごついViewModelができました。

  • 画面それぞれがstateをもつ
    Reduxのように一括で状態を管理するわけではなく、画面ごとに管理されます。Reduxとの違いの1つでした。

感想

これまでアーキテクチャについて、とりあえずでMVVMにしてみたり、開発中で汚くなったり、曖昧にしている箇所が多くありました。今回新しいアーキテクチャに触れる事で、考え方や長所それぞれ違いがある事を改めて感じました。
そもそもなぜ必要としていたのかもう一度考え直し、他のアーキテクチャについても理解を深めて、それぞれの長所と使い分けを整理しようと強く思いました。