Bài Viết2019.09.10 2021.04.02 Linh Nguyen Khanh

Android Architect

0 Shares

Post Views: 530

Android Architect

android, architecture

By Linh Nguyen Khanh

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 アーキテクチャのイメージ

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. 参考記事

0 Shares

Leave a Reply Cancel reply