Android Architect

Android Architect

1. 目的

Androidにおけるアーキテクチャについて調べてみる

2. 前提

完璧なアーキテクチャが無い

3. Androidにおける設計の難しさ

  • LifeCycle管理面倒
  • 画面生成・再生性・回転
  • 数多く存在するAPI
  • OSごとのバージョン管理
  • UI・Unitテスト難しい
  • Activity・Fragmentの肥大化が半端ない
  • 改修・新規機能追加する時にとても不安
  • 一画面だけ変更したいのに他のところもたくさん変更しなくちゃ

4. MVC Architecture:Model-View-Controller

3つの部分から構成されている

Model

  • data, logic, rule
  • ビジネスロジック等の処理も持つ

Controller

  • フローコントロール
  • ユーザーからの入力を受取、ModelとViewへの命令に変換する処理を持つ

View

  • Modelからデータを取り出し、UIへの出力担当
問題点
  • Modelの値に対応するViewの更新ができない。必ずController通さないと行けない。
  • MVCのModelにはデザインの状態を保持する 場所が無い
  • 例:在庫が無くなっても、非表示できない。
  • ModelとController間のインタラクションがシステム状態に影響を受ける/テストしにくい
  • Modelのデータ・ソースが多様
  • 各層の依存関係が強い
アプリだけで考えると:
  • ViewがActivity。状態を保存する必要がある
  • ControllerもActivityにある → Viewと混在している

5. 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がどんどん大きくなる可能性がある

6. MVVM Architecture:Model-View-ViewModel

6.1 MVCとMVP双方見る感じなアーキテクチャ

  • ViewとModelの間に 入るViewModel というものが新しく追加される
  • データバインディングを行う
  • MVPの監視コントローラーより 高いレベルで
  • UIが操作されるとデータ側も書き換えるような仕組み
  • Modelの方のデータが 更新されるとUIの方も更新される
  • 非同期処理が優秀(RxJavaによる)

6.2 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

7. Clean Architecture

7.1 アーキテクチャのイメージ

スクリーンショット 2017-06-23 10.31.14.png

7.2 基本な考え方

MVCでのアプリ開発の問題点を一個ずつ潰していく感じ

  • UIがビジネスロジックから分離される
  • ビジネスロジックがAndroidのライフサイクルから分離され、テストし易い
  • Modelの仕様変更に柔軟
  • モジュールの置き換えが容易

7.3 ViewとControllerがActivityに存在

MVPアーキテクチャで解決

7.4 ModelとController間のインタラクションがシステム状態に影響を受ける/テストしにくい

DomainLayerで解決
  • ビジネスロジックを集約(UseCasesやInteractorと呼ぶ)
  • Modelとの処理はDomain経由で行う
  • 処理は非同期で実行
イメージ
  • UseCase, Threadにより成立
  • UseCaseはベースとなるスレッド処理実装
  • ConcreteUseCase
  • UseCaseを継承し、ロジック処理の実行・Presenterへコールバック
  • UIThreadで結果反映

7.5 Modelのデータ・ソースが多様

DataLayer(RepositoryPattern)で解決

  • データをEntityとして扱う
  • DomainLayerで必要なDataSourceを集約するRepositoryクラス

7.6 各層の依存関係が強い

Dependency Inversion Principle

  • 依存関係逆転の原則
  • 上位のModuleは下位のModuleに依存しない
  • Interfaceを各層の間に置く

8. 参考記事

Leave a Reply