LoginSignup
73

More than 5 years have passed since last update.

Androidアーキテクチャ(保存版)

Last updated at Posted at 2017-06-23

目的

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にはデザインの状態を保持する場所が無い
      • 例:在庫が無くなっても、非表示できない。
  • 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

参考:All about MVVM

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

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

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

基本な考え方

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

  • 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を各層の間に置く

参考記事

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
73