#目的
Androidにおけるアーキテクチャについて調べてみる
#前提
完璧なアーキテクチャが無い
#Androidにおける設計の難しさ
- LifeCycle管理面倒
- 画面生成・再生性・回転
- 数多く存在するAPI
- OSごとのバージョン管理
- UI・Unitテスト難しい
- Activity・Fragmentの肥大化が半端ない
- 改修・新規機能追加する時にとても不安
- 一画面だけ変更したいのに他のところもたくさん変更しなくちゃ
#MVC Architecture：Model-View-Controller
3つの部分から構成されている
Model
- data, logic, rule
- ビジネスロジック等の処理も持つ
Controller
- フローコントロール
- ユーザーからの入力を受取、ModelとViewへの命令に変換する処理を持つ
View
- Modelからデータを取り出し、UIへの出力担当
問題点
- Modelの値に対応するViewの更新ができない。必ずController通さないと行けない。
- MVCのModelにはデザインの状態を保持する場所が無い
- 例：在庫が無くなっても、非表示できない。
- MVCのModelにはデザインの状態を保持する場所が無い
- ModelとController間のインタラクションがシステム状態に影響を受ける/テストしにくい
- Modelのデータ・ソースが多様
- 各層の依存関係が強い
アプリだけで考えると:
- ViewがActivity。状態を保存する必要がある
- ControllerもActivityにある → Viewと混在している
MVP Architecture：Model-View-Presenter
Model
- MVCと同じ
- data, logic, rule
- ビジネスロジック等の処理も持つ
View
- Viewはなるべく簡潔なものとし、Presenterにて操作を行う
Presenter
- Viewへの参照を持ち、Modelが変更されたらViewを更新する
MVP with Passive View
- ModelとViewが完全に分離され、Presenterがその仲介役を果たす
- 処理の流れ：
- ViewがUserからアクションを取得
- Presenterへアクションを伝達
- Modelでデータの処理をし、Presenterに送信する
- Viewを更新し、Userに表示する
問題点
Presenterが膨らむ
MVP with Supervising Controller
監視役のコントローラー
- ViewがModelのデータに基づくUI
- Viewが常にModelを監視し、データ変更があれば反映する
- Modelのデータ更新処理はViewから直接Modelに行くのではなく、Presenter経由で行う
問題点
ViewとModelの関係性の密着度が高い
→ ViewのデザインによりModelがどんどん大きくなる可能性がある
MVVM Architecture：Model-View-ViewModel
MVCとMVP双方見る感じなアーキテクチャ
- ViewとModelの間に入るViewModelというものが新しく追加される
- データバインディングを行う
- MVPの監視コントローラーより高いレベルで
- UIが操作されるとデータ側も書き換えるような仕組み
- Modelの方のデータが更新されるとUIの方も更新される
- 非同期処理が優秀（RxJavaによる）
MVVMをアプリレベルで具体的に砕いてみる
Model（Data Provider）
- Retrofit
- SharePreferences
- Broadcasts（通知サービス）
View（Activity, Fragment, CustomView, Layout-xml）
- UI・Widgetをコントロール
- Dialog, Toast, Snackbars
- Event Listeners
- Activityコントロール
- Menuハンドリング
- Permissionsハンドリング
- ActivityContextが必要な処理
- etc
ViewModel（ロジックの処理、ステート）
- ステート処理（エラー、プログラス、オフライン、オンライン、空...）
- データを公開して、Viewを更新する
- 表示・非表示
- Validation
- Argrument
- Modelからのデータ更新の呼びに反応
- UIからの命令に答える
- etc
#Clean Architecture
Architecting Android...The clean way?
https://github.com/android10/Android-CleanArchitecture
AndroidオールスターズでClean Architectureについて発表してきた&参考リンク集 - tomoima525's blog
アーキテクチャのイメージ
基本な考え方
MVCでの[アプリ開発の問題点](https://gmo-media.qiita.com/NguyenLinh208/items/161dc27dba7b72bbec90#%E3%83%87%E3%8!
3%A1%E3%83%AA%E3%83%83%E3%83%88)を一個ずつ潰していく感じ
- UIがビジネスロジックから分離される
- ビジネスロジックがAndroidのライフサイクルから分離され、テストし易い
- Modelの仕様変更に柔軟
- モジュールの置き換えが容易
ViewとControllerがActivityに存在
MVPアーキテクチャで解決
ModelとController間のインタラクションがシステム状態に影響を受ける/テストしにくい
DomainLayerで解決
- ビジネスロジックを集約（UseCasesやInteractorと呼ぶ）
- Modelとの処理はDomain経由で行う
- 処理は非同期で実行
イメージ
- UseCase, Threadにより成立
- UseCaseはベースとなるスレッド処理実装
- ConcreteUseCase
- UseCaseを継承し、ロジック処理の実行・Presenterへコールバック
- UIThreadで結果反映
Modelのデータ・ソースが多様
DataLayer（RepositoryPattern）で解決
- データをEntityとして扱う
- DomainLayerで必要なDataSourceを集約するRepositoryクラス
各層の依存関係が強い
Dependency Inversion Principle
- 依存関係逆転の原則
- 上位のModuleは下位のModuleに依存しない
- Interfaceを各層の間に置く
#参考記事
- まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて - Qiita
- 「MVCの勘違い」について、もう一度考えてみる - 圧倒亭グランパのブログ
- やはりお前らのMVCは間違っている - SlideShare
- Android data bindingを使ってMVVMなアプリを書く - Qiita
- Android Architecture Patterns Part 3: Model-View-ViewModel
- Architecting Android...The clean way?
- https://github.com/android10/Android-CleanArchitecture
- AndroidオールスターズでClean Architectureについて発表してきた&参考リンク集 - tomoima525's blog