MVI

仕事の UI コードをなんとかするアイデアを得るべく Android Weekly のアーカイブを眺ながら "Application Architecture" 的な話題を探す。

MVVM, MVP あたりまではフォローしていたが MVI (Model-View-Intent)というのが何なのか気になっていた。結論としては MVI = Redux/Flux だった。MVI をウェブで探しても canonical な資料が上の方にでてこないのは、そもそも MVI という用語自体が冗長だからだったのか。発明なしにラベルだけつけ直すとか、ほんとに Android プログラマコミュニティはしょぼいな・・・。

なんとなく Redux は React.js のような Virtual DOM を前提としている気がしたが、MVI の人々は気にしていない。MVVM の ViewModel を functional につくり、Presenter がその ViewModel を View に適用する。要するに ViewModel の POJO Data object なり ORM のオブジェクトなりが React の component の役割を果たす。たしかにそれで概ね問題ない気がする。

React が virtual DOM を必要としているのは,  ウェブフレームワークの伝統として結果を "render" する ... すなわち HTML を生成する... というメタファをそのまま持ち込みたかったからだ、と自分は解釈している。ウェブ以外の UI プログラマからすると "render" としてHTML を生成するのは完全に狂っておりわけがわからない。しかしその狂った伝統を貫き通すため React は virtual DOM (以下 VD) という mad science を必要とした。

一方で伝統的な UI ... というと広すぎるので Android に限った話 ... では、render のように HTML というか View の XML を動的に生成するみたいなナンセンスは存在しないし、そもそも API の ergonomics が頻繁な View 構造の作り直しを促さない。基本的には最初に一回つくっておしまい。状態の反映は既に作られた view hierarchy の property を更新して実現する。Android で Redux をベタにやると property update が雑になるなので副作用を最小化する工夫が必要といえば必要だが、特に難しくはない。というか View の実装は大半の property が既に副作用最小化のガードを実装している。雑な propety update の副作用で性能が落ちるのは、別に Redux に限った問題ではないからね。

VD で特別難しいのはたとえばリストのスクロールなどで View の構造が dynamic に変わりうる場面。だけれど Android だとそういう動的な View 構造の変更は RecyclerView なり ViewPager(2) なりが実装している。そしてこいつらがやっていることは大局的には VD の delta application  とおなじ。RecyclerView の adapter を Redux 的に実装するのは・・・やったことないけどそんな難しくはない、気がする。結局, RecyclerView というのはそれを使うプログラマと協力して View を recycle する・・・すなわち古い View に delta を apply して使いまわす・・・というものなわけだから。

大企業による Android Redux 的なものの紹介記事などをリンクしておく:

なおこいつらは誰も MVI という単語をつかわない。やはり MVI はダメだな。スルーでよし。一体誰が言い出したんだろうね・・・・。軽く調べるとこのへんらしい:

ケチつけてばかりいるのもどうかとおもうので、いちおうあとで読んでみよう・・・。


なお Android なら VD とか要らなくね、という自分の見立てとは裏腹に Android の中の人は Jetpack Compose という Kotlin React みたいのを実装しているらしい。Apple も SwiftUI とかいってるし、時代の流れなのだろね。

冷やかしでかるくコードを眺めると・・・これとか delta application ですかね。とりあえず引き続きスルーでよさそうなのが確認できてよかった。しょうじき使う日はこなそうだが、頭の体操にひやかすのは悪くないかもしれない。そのうち。