なぜこの本を書こうとしたのか

　昨今のAndroidの設計はMVPやMVVMといわれてますが、実際には多くのプロジェクトでのプログラムはそのような構造化がなされていません。ActivityにViewの操作、通信ライブラリーの呼び出し、トラッキングログなどを詰め込むといった、いわゆるマッチョなActivity化したプロジェクトがほとんどではないでしょうか？そのようなプロジェクトをいきなりMVP化して、通信ライブラリーにRetrofitとRxを組み合わせ、Dagger2によるDIを導入するのは大変です。

　一方、筆者が所属する組織でも歴史のあるプロダクトを扱っていますが、本書で紹介するパターンを当てはめることにより、ほぼPresenterにテストを書ける状態になっています。

　最初からいきなりモダンな作りにしなくても、モダンな作りを行う前の準備段階として、いかにソースコードをテスタブルな状態にして将来的にDagger2に置き換えられるかについて、本書でレガシーパターンのリファクタリング例を紹介することで、少しでも皆さんのプロジェクトの助けになれば幸いです。

対象読者

　この本は次のような悩みを抱えている方にとって助けになるでしょう

　・Androidのソースコードがレガシー化していて今時のMVPに置き換えたいけど、何から手を付ければいいのかわからない人

　・MVPにしてみたけどPresenterにView側の処理が入り込んだりして、何が変わったのかわからない人

　・MVPにしてみたけど、結局テストコードが書けない人

　・Dagger2とかRxJavaを使わないとテストは書けないと思っている人

なぜMVPなのか

　まず、なぜMVPなのでしょうか。それは、肥大化したActivityを分割する最初のステップとして「ちょうどいい」からです。また、MVP化が成功すればその時点で適切にViewとModelによる処理を分割できているということなので、楽にMVVMに移行できるでしょう。その意味で、MVP化はおすすめなのです。

　また、適切にコードが分割されているMVPは特別なライブラリーの知識を必要としないので、素早くキャッチアップできます。コードレビューに関しても、何をどこに書けばいいのかがはっきりしているので、レビューがスムーズになるはずです。

お問い合わせ

　本書に関するお問い合わせは https://twitter.com/masahide318 にお願いします。

ソースコード

　本書で紹介したソースコードは、次のリポジトリで公開しています。実際にテストコードを実行することが可能なので、あわせてごらんください。

　・https://github.com/masahide318/AndroidTestMVP

免責事項

　本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。

表記関係について

　本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。

底本について

　本書籍は、技術系同人誌即売会「技術書典5」で頒布されたものを底本としています。