アーキテクチャ編

1. Androidアプリ開発にクリーン
アーキテクチャを取り入れよう
（アーキテクチャ編）
2016/02/18
notice,inc.
http://www.notice.co.jp/
@notice_inc

2. Androidアプリ開発の悩み
FatAcitivity
なんでもかんでもアクティビティに詰め込む
Recreation
アクティビティのリクリエーション時の再生処理
Fragment
フラグメントの複雑なライフサイクルにともなうクラッシュ
Asynchronous
非同期処理実装の困難さ

3. アクティビティリクリエーションに関して
configureChangeで回転を止めると、オリエンテー
ション変更のイベントがとれず、画面をアダプティブ
にできない（オリエンテーション固定アプリなら有
効）。
仕様検討するときに、可能な限り復元しなくていい
ように考慮すべき。
フラグメントの注意点
ref. WTF what the fuck! なんだこれ？
http://ninjinkun.hatenablog.com/entry/2014/10/16/234611

4. 様々なアーキテクチャと開発手法
基礎
PofEAA(Patterns of Enterprise Application Architecture) - Martin Fowler
DDD(Domain Driven Design) - Eric Evans
UCDD(Use Case Driven Design)
MVCの発展形
MVVM(Model-View-ViewModel)
MVP(Model-View-Presenter)
テスティング
TDD(Test Driven Development) - Kent Beck
BDD(Behavior Driven Development)
非同期処理
FRP(Functional Reactive Programing)
Rx(Reactive Extentions)

5. クリーンアーキテクチャ
The Clean Architecture
http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
（１）ビジネスロジックとUIを分離する。
（２）全体が固有のフレームワークやライブラリに依存しない。
（３）データ永続化の手段に依存しない(database,filesystem)。
（４）ユニットテストしやすくする※1。
※1ＡＰＩテストケースはそのままＡＰＩ利用のサンプルになるので、
ドキュメントの代わりになる。

6. クリーンアーキテクチャを取り入れよう
依存関係逆転の原則（DIP:the Dependency Inversion Principle）
interfaceを使って、オブジェクト間の依存関係を疎に保ち、IoCコンテナで結合する。
関心の分離（SoC: Separation Of Concerns）
UIとビジネスロジック - まぜるな危険！
ビジネスロジックとモデル - 特定のデータベースに依存しないように！
IoC(DI)って、何が便利なの？
・ユニットテストが簡単。
・モックオブジェクトでとりあえず、結合できるので、まだ未完成な部分の完成を待つことなく、開発できる。
・初期化のボイラープレートがなくなる。
開発は、様々なオープンソースライブラリを利用することになるが、開発中に急に使えないと判断せざるえない場合が
ある。
そんなときでも、代替のライブラリが利用できるようにしておくことが重要。
オープンソースを利用するなら、最悪は自分でソースコードを修正するぐらいの覚悟が必要。

7. 実際、どうやるの？
以下のようなレイヤーを構成する。
レイヤー
アクティビティ
ヴュー
プレゼンタ
インタラクション
リポジトリ
モデル/APIサービス

8. アクティビティ
Activityはアプリに一つだけ定義する。
各Viewを保持するコンテナとして利用する。
各画面はCustomViewまたはFragmentで実装する
（CustomViewなら画面遷移アニメーションも自力実装）。
画面遷移はアクティビティ内で管理する（バックボタン
等も）。

9. ヴュー
Fragment,CustomViewからビジネスロジックを追い出す。
Button button = (Button)v.findViewById(R.id.some_button);
button.setOnClickListener(new View.OnClickListener() {
@Override public void onClick(View v) {
ここにだらだら、ロジックを書かず、プレゼンタへまかせる。
操作中の状態を保持するような変数も全てプレゼンタで定義する(ViewModel)
presenter.doSomeAction();
}
}
);
// AndroidStudioなら、SAM(Single Abstract Method)型はlambdaで書ける。
// Retrolambda(backport tool)を使うとJava8のlambdaで書ける。

10. プレゼンタ
Ｖｉｅｗを保持したPOJOオブジェクト。
プレゼンタはユーザーの操作から、具体的なビジネスロジックを実行し、その結果をViewに反映する。
一時的な表示上のデータ（チェック状態、選択状態、編集状態）はViewModelに保持する。
オリエンテーションチェンジで保存しておきたいViewModelは、
ＡｃｔｉｖｉｔｙのonSaveInstanceStateでプレゼンタのsaveInstanceState()を呼び、
restoreInstanceState()で復元する。
Presenter
ViewInteraction
ViewModel

11. インタラクション
ビジネスロジックを実装するクラス。
設計(interface)と実装(implement)を分離し、DIできるようにしておく。
関連のあるユースケースをインタラクションクラスとして定義する。
インタラクションは、APIを呼び出してサーバからデータを取得し、必要
ならリポジトリを利用して、データを永続化する。
非同期実行インタラクションは終了ハンドラを実装するか、Rxのオブ
ザーバーや、Promiseのようなタスクを返す。
インタラクションはプレゼンタからコールされる。

12. リポジトリ
モデルの操作を受け持つ。
インタラクションから呼ばれて、ＡＰＩで取得したデータを
を永続化したり、永続化されているデータを取り出す。
状態は保持しない。
データの永続化に関しては、モデルの実装に依存する。
インタラクションがモデルの実装に依存しないように、モ
デルの実装を隠蔽する役目を持つ。

13. APIサービス
サーバサイドとの通信を受け持つ。
サーバサイドから提供される各APIごとにメソッドを実装する。
APIサービスは、Rxのオブザーバーや、Promiseのようなタスクを返す。
ＡＰＩサービスの下位にHTTPクライアントライブラリの実装をおいて、Ａ
ＰＩサービスのインタフェースはライブラリ実装に依存しない。
下位層のプロトコルがHTTPなら、メソッド(GET,POST)、ヘッダ（認証
キー、Cookieなど）を隠蔽する。

14. モデル
基本的にプレーンなオブジェクト(POAA:Plain
Old Android Object)で実装する。
具体的なデータベース実装に依存する部分を
少なくする。
永続化する必要がなくても、APIからの応答など
をモデルで定義する（JSONのままでもいいかも）。

15. ユニットテスト
インタラクション以下の層は、JUnitなどで簡単
にテストできる。
モデル、リポジトリ、APIサービス、インタラクショ
ンはGUIと結合するまでに、テストケースを記述
し、オールグリーンにしておく。