Kotlin/Javaでブランチを分けています。
ざっくり言うと、MVVMは上記MVCの派生パターンであり、MVVMを考慮してアプリケーションを開発する目的は、他のMVC系のパターンと同様にアプリケーションの「プレゼンテーション層(ユーザーが見て触れられる層)とドメイン(ビジネスロジック)を分離」することです。
そのアーキテクチャをAndroidでDataBindingライブラリが登場したことで、利用可能になったよと、そして、 Android Architecture Components の登場により、より扱いやすくなったよ、ということのようです。
大まかなメリットとしては、よくあげられるのは
- 関心の分離
- 依存関係の切り離し
- 画面回転問題
などなど、また、依存関係が
Model (リモートとローカル問わず、データリソースを操作する領域)
⇩
ViewModel (DataBindingライブラリを通し、Viewに表示するデータの監視、取得をする領域)
⇩
View (xml/Activity/Fragment)
と依存関係が単方向になることで、保守性も向上します。 設計についてはもっと詳しい記事が世の中に溢れているので、詳細は以下に紹介いたします。
主要な設計への理解に関しては、以下記事を参考。
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する
設計参考書籍。
Android Architecture ComponentsはGoogleが推奨するデザインパターンを扱いやすくしたライブラリ群です。 4つに分かれてます。(公式ドキュメントから参照/引用)
- Lifecycle (ライフサイクルイベントに自動的に応答するUIを作成)
- LiveData (基礎となるデータベースが変更されたときにビューに通知するデータオブジェクトを構築)
- ViewModel (アプリの回転で破棄されないUI関連のデータを保存)
- Room (アプリ内オブジェクトとコンパイル時のチェックを使用して、アプリのSQLiteデータベースにアクセス)
今回お世話になる、ViewModelはModelの変更を監視し、データをViewにバインドし、View操作を伝達するクラスです。Viewとライフサイクルを共に歩むので、画面回転などユーザの想定外の操作に強くなります。
LiveDataは、Android Architecture Componentsが提供する、ライフサイクルと連動した監視が可能な、データホルダーのクラスです。
【Android Architecture Components】Guide to App Architecture 和訳
参考記事：MVVM architecture, ViewModel and LiveData (Part 1)
ここで紹介されているサンプル(よく見るあるユーザのGithubリポジトリをずらっと表示するだけのクライアントアプリ)の実装を、真似してます。
これだけ
まず、当たり前ですが、依存関係のない方向に従い ( Model-> ViewModel -> View ) の順で実装していきましょう。
設計にこれといった答えはなく、これが正解というわけではないです。色々なサンプルを触って、最もシンプルでわかりやすかったので、あくまで一例です。
