ViewModel を捨てて マルチプラットフォーム に備える

AAC ViewModel

どの Compose バージョンでもシームレスに動作するマルチプラットフォーム ViewModel のようなものをお考えでしょうか?

AAC ViewModel は Android 用の雑なもので、悪いパターンを増殖させる理由はないと思います。データレイヤーが適切に設計されていれば、AAC ViewModel を使う必要がないことに気づくはずです。

しかし、おそらく一番良いのは、アプリが本物のデータ層(キャッシュ、ネットワーク層など)を持つことです。 ViewModel はデータレイヤーを参照するかもしれませんが、ViewModel 自身はすべてのインタラクションを直接処理するべきではなく、プラットフォームに依存しないデータレイヤーがそれを行うべきです。

@JimSproch
Senior software engineer at Google. Progenitor of Jetpack Compose (May 2017). Now working on giving Compose its next-generation super-power.

👉 Jim Sproch(@JimSproch)さん / Twitter hatena-bookmark

クラッジ kludge
その場しのぎに間に合わせで採る安易な方法。またそうした問題回避。特にコンピューターのプログラミングやシステム構築で,とりあえず動くが不調和な組み合わせを持ったその場しのぎのもの。

AAC ViewModel の件、全く同感です。AAC ViewModel を不要にするような形で Compose が考案されたことは喜ばしいことです。
しかし、Compose の成功のためには、マルチプラットフォームのアーキテクチャパターンをいくつか考え出すことが本当に重要だと思います。

印刷して額に入れよう。

あとは、独占しているコンフィグ不要のしくみを取り除いて、人々に返すだけです。
👉 android:configChanges - Android デベロッパー  |  Android Developers hatena-bookmark

「なぜ?」と思われる方のために、もう少し詳しく説明します。

AndroidのViewModelは不要、その理由は?
ViewModel は Android アプリケーションで最も人気のある構成要素の一つですが、私は自分のプロジェクトでは使っていません。Android 開発者の中には、特に「ViewModel 時代」にキャリアをスタートさせた人にとっては、これはクレイジーに聞こえるかもしれません。

最初の導入時、ViewModel は素晴らしかったのですが、今は Navigation Component があり、それを異なる場所に配置しなければならないので、少し混乱しています。しかし、赤ん坊を風呂の水と一緒に捨てるわけにはいかないと思います。

私達は、これらのライブラリはどちらも使用しません。

throw the baby out with the bath water

意味・対訳
大事なものを無用なものといっしょに捨てる

では、AAC ViewModel の優れた代替手段は何ですか?

必要ない、というのが元のツイートのポイントです。ドメインに特化したデータレイヤーが欲しいなら、画面に特化したプレゼンターとレンダーレイヤーを用意すれば良いです。Compose UI やクラシックビューでやればいい。AAC ViewModelは常に奇妙なボルトオンのソリューションでした。

いくつかのプロジェクトをKMMに移行したいのですが、AAC ViewModel を捨てれば、おそらく作業はよりシンプルになると思います。

👉 Android ViewModel が不要である理由 hatena-bookmark
👉 【MVVM】 Kotlin Flow で使える5つの利用パターン hatena-bookmark


関連ワード:  AndroidGoogleJetBrainsJetpackComposeKMPKotlinおすすめ評判開発