android cleanarchitecture

Android Clean Architecture ことはじめMercari, Inc. Tomoaki Imai

08/08/2015 Android All Stars @Shibuya dots.

Tomoaki ImaiMercari, Inc.

twitter: @tomoaki_imai

github: tomoima525

今日はみなさんに質問があります

胸に手を当てて振り返ってみてください

キレイな設計、できてますか？

Androidにおける設計の難しさ• Life Cycle(画面再生成 etc)

• 数多く存在するApi

• OSごとのバージョン管理

みんな似たようなことで悩んでる

ライフサイクル考えるのめんどくさい

画面回転が入ると面倒

Activity, Fragmentがどんどん肥大化する

ディレクトリ構成がプロジェクトでまちまち

Unit/UI Testが難しい

“Android Clean Architecture” という考え方

The Clean Architecture by Uncle Bob

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html


The Clean Architecture (Enterprise Application)

(Web Service)+ =

Android Clean Architecture


http://www.slideshare.net/shinnosukekugimiya/ss-50705888

https://github.com/android10/Android-CleanArchitecture


今日みなさんに持って返ってもらいたいもの

• Android Clean Architectureの思想をさっくり理解する

• Android Clean Architectureの実際的な実装方法を理解する

• 既存の設計と比べてどういうメリットがあるか理解する

標準的なWeb設計の指針

“MVC Architecture”

MVC Architecture

Modelアプリケーションデータビジネスロジック

View Modelをレンダリングする

Controller ユーザーイベントをハンドルする

View

Model

Controller

User

usessees

Life Cycle

Data source

Frameworks

Android Frameworks

Activity Life Cycle

MVC Architecture on Android

Model

アプリケーションデータ (http, DB, memory色々) ビジネスロジック

ViewModelをレンダリングする (端末の状態を意識しながら)

Controllerユーザーイベントをハンドルする (端末状態をハンドルする) (色んなViewもハンドルする)

View

Model

Controller

User

usessees

MVCでアプリ

Sample App• GithubからFollowerを取ってくるアプリ

• Followerのrepository見れる

• 選択したFollowerはメモリにキャッシュし、2回目以降はトーストで通知する

https://github.com/tomoima525/CleanArchitectureSample

/app配下 -> MVC で実装

/cleanarchitecture配下 -> Clean Architecture で実装

https://github.com/tomoima525/CleanArchitectureSample

private GithubApi mApi;private UserMemoryCache mUserMemoryCache;…

mApi = createApi();mUserMemoryCache = UserMemoryCache.getInstance();…public void HogeTask(…){ //ビジネスロジック… mApi.listFollowersAsync(…); mUserMemoryCache.put(…); }

Models

• Modelのデータ元は多様

• ModelとControllerのインタラクション(ビジネスロジック)がテストしにくい

public class MainActivity { @Override protected void onCreate(Bundle savedInstanceState) { // create views... }

@Override protected void onResume(){ // resume/update views when system state is resumed }

@Override protected void onPause(){ // pause views when system state is paused }}

Views

• Viewの状態管理が必要

public class MainActivity { // User events public void onClick(){} public void afterTextChanged(){}

// System events public void onSaveInstanceState(Bundle outState){} public void onRestoreInstanceState(Bundle inState){}

// View events public void gotoUserDetailActivity(Context context){}}

Controllers

• ViewとControllerがActivity上に混在している

• 画面再生成などのシステムの状態もハンドルする必要がある

MVC Architecture on Android における課題

View(の状態管理)とControllerがActivity上に混在している

ModelとController間のインタラクション(ビジネスロジック)がシステム状態(LifeCycle)に影響を受ける/テストしにくい

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

各層の依存関係が強い

Clean Way…?


View(の状態管理)とControllerがActivity上に混在している




MVP Architecture

MVP Architecture

• Presenterを介してModelを制御する設計

View

Presenterからの情報をレンダリングする -> 端末の状態は配慮不要になる

Presenter

- Activityから分割 - ユーザーイベントをハンドルする - Modelの結果をViewに返すAndroid Frameworks

Activity

View

Model

Presenter

Userusessees

public interface ShowUserListView { // UI として表示したい処理を定義する void showLoading(); void hideLoading(); void showNoResultCase(); void hideNoResultCase(); void showResult(Collection<User> usersCollection);}

Views

public abstract class Presenter { // Activity LifeCycle public abstract void initialize(); public abstract void resume(); public abstract void pause(); public abstract void destroy();}

Presenters

public class ShowUserListPresenter extends Presenter { public void setShowUserListView(ShowUserListView view){ mShowUserListView = view; //Viewを監視できるようにする }

public void getFollowerList(String user){ mShowUserListView.showLoading(); // Activity側にCallbackする }}

Activitypublic class MainActivity implements ShowUserListView{

@Override public void onCreate(){ mShowUserListPresenter = new ShowUserListPresenter(…); mShowUserListPresenter.setShowUserListView(this); } @Override public void showLoading() { //実際のUI処理はActivityで実行できる! mListView.setVisibility(View.GONE); mProgress.setVisibility(View.VISIBLE); } @Override public void showResult(Collection<User> usersCollection) { mListView.setVisibility(View.VISIBLE); mUserAdapter.refresh(usersCollection); }}


MVP Architecture




Domain Layer

• Domain Layerにビジネスロジック(interactorまたはuse casesと呼ぶ)を集約する

• Modelとの処理はDomain経由で行う

• 処理は非同期で実行する

• Pure Java

Domain Layer

Domain

Android Frameworks

Activity

View

Model

Presenter

Userusessees

Domain Layer

UseCase <<abstract>> ベースとなるスレッド処理を実装

ConcreteUseCaseUseCaseを継承ロジック処理の実行、Presenterへのコールバック

PostExecutionThread (UIThread) スレッド実行後の処理

• Domain層は大まかにUseCase, Threadにより成立

• 設計方法は多くの手法がある

public abstract class UseCase<T> { // スレッドをキュー処理できるようにする private ExecutorService mExecutorService

= Executors.newSingleThreadExecutor(); public void start(final T params) { mExecutorService.submit(new Runnable() { @Override public void run() { call(params); } }); } //スレッド内でcallされるメソッド abstract protected void call(T params);}

UseCase

https://github.com/kgmyshin/Android-archを参考

https://github.com/kgmyshin/Android-arch%E3%82%92%E5%8F%82%E8%80%83

public class FollowerListUseCase extends UseCase<String> { @Override public void execute(String user, FollowerListUseCaseCallback callback){ mCallback = callback; this.start(user); // (1) ExecutorServiceのスレッド経由でcall()が呼ばれる }

@Override protected void call(String user) { // (2) Modelからデータ取得、バリデーション等のロジック処理。 // …省略 // (3) 処理後はUIThread( PostExecutionThread )にCallbackを返す mPostExecutionThread.post(() -> {mCallback.onUserListLoaded(usersCollection);}); } // UIThreadに返すCallbackのinterface interface FollowerListUseCaseCallback { onUserListLoaded(final Collection<User> usersCollection); onError(); }}

ConcreteUseCase

Presenterpublic class ShowUserListPresenter extends Presenter implements FollowerListUseCaseCallback { private FollowerListUseCase mFollowerListUseCase; public void getFollowerList(String user){ // (1) usecaseを実行 -> 別スレッドへ mFollowerListUseCase.execute(user, this); }

// (2) FollowerListUseCaseCallback経由で処理結果を受け取る @Override onUserListLoaded(final Collection<User> usersCollection){ // Viewへ結果を渡す } @Override onError(){ // error handling }}


MVP Architecture

Domain Layer



Data Layer

Android Frameworks

Data Layer

• データをEntity(メソッドやデータ構造体のかたまり)として扱う

• Domain Layerにデータ元を意識させないためにRepository パターンで実装する

Domain

Android Frameworks

Activity

View

Data

Presenter

Userusessees

Repository Pattern• ドメイン駆動開発で利用されるデザインパターン

• UseCaseで必要なデータソースを集約したRepositoryクラスを実装する

Data

UserRepository DocsRepository XXRepository

public class UserRepository { private GithubApi mApi; // Github API用のインスタンス private UserMemoryCache mUserMemoryCache; //メモリキャッシュ用インスタンス

public UserRepository(){ mUserMemoryCache = UserMemoryCache.getInstance(); mApi = createGithubApi(); }

public void getFollowers(String user,UserListCallback callback) { mApi.listFollowersAsync( ... // Networkから取得 }

public void putUser(User user){ mUserMemoryCache.put(… // メモリにキャッシュ }}

Repository


MVP Architecture

Domain Layer

Data Layer(Repository Pattern)


Dependency Inversion Principle


• 依存関係逆転の原則

• 上位モジュールは下位モジュールに依存しない

例) PresenterはDomainの実装がどのようになってても影響を受けない

• interfaceを各層の間に置く

Android Frameworks

Domain

Android Frameworks

Activity

View

Data

Presenter

Userusessees

interface

interface

public interface UserRepository { // Domain層(UseCase)側はこの interfaceの仕様だけ知っていればOK void getFollowers(String userId, UserRepositoryCallback callback); void getUser(String userId, UserRepositoryCallback callback); void putUser(User user);}

Dependency Inversion

//実際の実装は interfaceを継承する public class UserRepositoryImpl implements UserRepository { @Override public void getFollowers(String userId, UserRepositoryCallback callback){ //データ取得 … } @Override public void putUser(User user) { } //…}


MVP Architecture

Domain Layer

Data Layer(Repository Pattern)


どう変わった？

こう変わった！

Android Frameworks

Domain

Android Frameworks

Activity

View

Data

Presenter

Userusessees

interface

interface

UIがビジネスロジックから分離して見通しが良くなった

ビジネスロジックがAndroidのライフサイクルから分離され、テストが容易に

Modelの仕様変更に柔軟に対応可能になった

モジュールの置き換えが容易になった

なんか難しい…?

少しずつ手をつけるとよいかも

どこから手を付けるべきか

手法実現難易度

MVP Architecture ☆

Domain Layer ☆☆☆

Data Layer(Repository Pattern) ☆☆

Dependency Inversion Principle ☆☆

Next step…• Dependency Injection

• 簡潔に書ける

• モジュールの載せ替えが容易

Next step…• Implementing Observer Pattern

• Domain Layerの煩雑なスレッド処理, Callback地獄からの開放

参考例: https://github.com/android10/Android-CleanArchitecture


– Clean Architecture, Uncle Bob

Architecture is about Intents, not Frameworks

– Clean Architecture, Uncle Bob

設計とは(良いコードが書きたいっていう)

意志である!

フレームワークなんて関係ねぇ!(意訳)

android cleanarchitecture

Engineering