いまどきの MVP 実装パターンを眺めるべし「Android Architecture Blueprints」

このような, 質問がありました.

こんにちは。

私はアプリの開発を2年ほどやっているものです。
しかし, いつも似たようなコードの繰り返しばかりで少しも進歩していないように思っています。

小さい会社なので, モバイルアプリ開発者は私だけで, だれも私のコードを見ることがないので, 私のコードの間違いを指摘されることはなく, 会社で開発されている他のコードを見ることもありません。

最新技術を利用しすばらしい実装を行っているオープンソースアプリのコードを勉強したいです。

そのようなアプリをどこで見つけたらよいか教えて下さい。

よろしくお願いいたします。

I would like to study some up-to-date open source apps, preferably with material design, do you have any suggestions? : androiddev

このような環境で日々を過ごし, 似たようなことを考えてる開発者は多いと思います。

以下のサイトはいかがでしょうか. よくある ToDo アプリでのサンプルとなっています.

Android Architecture Blueprints [beta] - A collection of samples to discuss and showcase different architectural tools and patterns for Android apps.

ここでフォーカスされているのは, 構造, 設計, テスト, メンテナンスのしやすさですが, リファレンスとして, または, アプリ開発のスタート地点として利用できます.

MVP (基本的な Model-View-Presenter)

googlesamples/android-architecture at todo-mvp

このサンプルはすべての基本となります. 構造を持つフレームワークを使わないシンプルな Model-View-Presenter パターンの実装例です. ローカル/リモートのデータソースである Repository を手作業で Dependency Injection しています. 非同期処理はコールバックを利用しています.

mvp

MVP + Loader

googlesamples/android-architecture at todo-mvp-loaders

Repository から Loader を使ってデータを取得します.

- コールバックなしで Repository 内のデータを非同期で読み込むことができる.
- データソースを監視しており, Repository の内容が変化すると新しい結果として配送できる.
- 画面回転のあと自動的に直近の Loader を再接続できる.

mvp-loaders

MVP + Loader + ContentProvider

googlesamples/android-architecture at todo-mvp-contentproviders

Repository からのデータ取得に ContentProvider を使います.

- 構造化されたデータへのアクセス操作可能.
- 別プロセスで稼働しているコードからデータへ接続できる標準的なインターフェースとなる.

mvp-contentproviders

MVP + DataBinding

googlesamples/android-architecture at todo-databinding

DataBiding ライブラリを利用して, UI要素にデータとアクションをバインドしています. 厳格には Model-View-ViewModel や Model-View-Presenter パターンではありません. ViewModel と Presenter 両方使用しています.

DataBinding ライブラリは, データとUI要素を連携する重複するコードを削減してくれます.

- レイアウトファイルがUI要素へのバインドに利用されている.
- 同時にイベントもアクションハンドラーと結合されている.
- データの監視が可能で必要であるときには自動で更新するようにセットすることができる.

mvp-databinding

MVP + Clean Architecture

googlesamples/android-architecture at todo-mvp-clean

Clean Architecture に基づいており, Presentation と Repository レイヤーの間に Domain レイヤーが存在して, アプリを3つのレイヤーに分けています.

Domain レイヤーでは, すべてのビジネスロジックを収納しており, Presenter に使われる use-case か interactor と命名されたクラスから始まる. これらの use-case は Presentation レイヤーから作ることができるすべての実装可能なアクションを提供します.

mvp-clean

その他

その他, 最近流行のフレームワークや考え方を考慮しての実装サンプルも続々と作成中のようです.

Architecture Blueprints の非同期処理実装にみる Android SDK の方向性

MVP + Dagger2
MVP + RxJava
MVP + Fragmentなし

非常に柔軟性のある使えるサンプルとなると思われます. ぜひご確認あれ.

Architecture Blueprints の非同期処理実装にみる Android SDK の方向性

Hacker News Radio (翻訳) - Google Play の Android アプリ


Gradle ビルド時にやると良い 8つのこと

Gradle のプログレスバーをじっと見てるのは嫌いですよね?

8_things_to_do_while_Gradle_builds_—_Medium

なので, ビルドが完了するまでにできること一覧を作成してみました.

大体, それぞれがいつでもどこでもできる細切れ作業なので, ビルドの間にやるにはちょうどいいと思います.

1. ボキャブラリを増やす.

2. 新しい外国語を学ぶ.

3. Hacker news, Github, ProductHunt, CodePen, StackOverflow, Reddit を徘徊する.

4. 運動をする: 腕立て伏せ, 足首を曲げたり伸ばしたり, スクワットなどたくさんの手軽で器具不要なエクササイズがありますよね.

5. コードを Lint に通す. (3543個も Warning がでたのですぐに止めました)

6. バグを整理する.

7. Android Performance Patterns の動画を見る.

8. Play Store で競合のアプリを見てみる.

あなたはビルドの間, 何をしていますか?

Hacker News Radio (翻訳) - Google Play の Android アプリ
8 things to do while Gradle builds : androiddev
8 things to do while Gradle builds — Medium


苦労した経験から学んだ Androidアプリを作る際の30のこと

Building Android Apps — 30 things that experience made me learn the hard way — Medium

読んでみましたが, 納得できることばかりです.

一読の価値はあると思います.

実際は, 35個ありました.

1. サード・パーティのライブラリを追加する前に2度考えよう. それは本当に重要な決意なのです.

2. ユーザーがそれを見ることができないならば, 描画してはならない.

見えないところは塗りつぶすな – 不要なオーバードロー削除で高速化

3. 本当に必要でなければデータベースは使うな.

4. メソッド数 65000個はすぐに到達するが MultiDex が助けてくれる.

[DEX] Sky’s the limit? No, 65K methods is — Medium

5. AsyncTask のベストな代替は RxJava でこれのほうがかなりよい.

Party tricks with RxJava, RxAndroid & Retrolambda — The Startup — Medium

6. Retrofit がベストなネットワークライブラリである.

Retrofit

7. Retrolambda でコードを短縮しよう.

Retrolambda on Android — Android & Tech — Medium

8. RxJava と Retrofit と Retrolambda を一緒につかうと最強.

Party tricks with RxJava, RxAndroid & Retrolambda — The Startup — Medium

9. EventBus は素晴らしいが, コードが乱雑になるので多用するのは控えている.

greenrobot/EventBus: Android optimized event bus that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.

10. レイヤーでなく機能によって構成する.

ソースディレクトリの構成時にもっておくべき「会社別」のイメージ

11. アプリケーションスレッドのすべてをOFFにしろ.

12. レイアウトとそのヒエラルヒーを最適化するために lint するべし. 削除できる不要なレイアウトを特定できる.

layoutopt | Android Developers

13. Gradle を使っているなら, いろんな方法でスピードアップしよう.

Android お手軽なビルド時間の短縮メモ

14. ビルド時には プロファイルレポートを使え, それぞれのビルドにかかった時間が分かる.

オプションに「–profile」をつけて Run時間が1分から2秒になった話

15. 有名なアーキテクチャーを使え.

Architecting Android…The evolution – Fernando Cejas

16. テストは時間がかかるが, 一度コツを掴むとテストしないときより高速で堅牢となる.

Is Unit Testing worth the effort? - Stack Overflow

17. Dependency Injection を使え. よりモジュール化されテストしやすくなる.

Tasting Dagger 2 on Android – Fernando Cejas

18. Fragmented の podcast を聞け. きっとあなたにとって素晴らしいものとなる.

Fragmented_–_An_Android_Developer_Podcast

Fragmented – An Android Developer Podcast

19. 個人的メールアドレスは Android Market の公開アカウントに使うな.

Google Play - Only one strike is needed to ruin you : Android

20. 常に適切な入力タイプを使え.

Specifying the Input Method Type | Android Developers

21. (Google) Analytics を使って利用パターンを見つけバグを隔離すべし.

22. 新しいライブラリの人気のあるやつを使え. (dryrun を使って出力をより速く)

【AndroidStudio 不要】サンプルアプリは「dryrun」で試してすぐ捨てよう

cesarferreira/dryrun: Try the demo project of any Android Library

23. Service はできるだけ素早く処理して終了しろ.

24. ユーザ名やメールアドレスのサジェストにアカウントマネージャーを使え.

AccountManager | Android Developers

25. ビルドやベータ版の配布や apk の作成にはCIを使え.

26. 自分の CIサーバは使うな. サーバーのメンテに時間を使う. ディスク容量・セキュリテイの問題・SSL攻撃防御のサーバの更新なども. Circle CI や travis, shippabele を使え. これらは 安価で手間も少ない.

27. PlayStore へのデプロイは自動化しよう.

Triple-T/gradle-play-publisher: Gradle Plugin to upload your APK and metadata to the Google Play Store

28. ライブラリが巨大でその一部しか使ってない場合は, より小さくなる方法を探せ(例えば プロガードを利用する)

Shrink Your Code and Resources | Android Developers

29. 実際に必要以上なモジュールを使うな. もしそのモジュールを頻繁に更新していないのなら, コードからそれらをコンパイルする時間や, 以前のそれぞれのモジュールのビルドが最新版であるかチェックも必要となることについて考えることが重要です. バイナリ .jar/.aar の簡単な読込みにすると4倍くらい向上できます.

30. PNGを捨ててSVG化することを考え始めよう.

Vector Asset Studio | Android Developers

31. ライブラリの抽象化クラスを作れ. ライブラリを変更するときに一箇所の変更で簡単に行うことができる.

JakeWharton/timber: A logger with a small, extensible API which provides utility on top of Android's normal Log class.

32. Connectivity とその種類を監視しろ. (WiFi のときにより多くのデータを更新しているか?)

33. 電源とバッテリーを監視しろ. (充電中に更新データを多くしているか, バッテリーが少ないときには更新を停止しているか?)

34. UIとはジョークのようなものだ. 説明が必要であればそれは良くない.

35. テストのパフォーマンスは偉大です. テストで何も壊れないか確認し、その後ゆっくりと正しい実装を記述する → 最適化

Dan LewさんはTwitterを使っています: "Tests are great for performance: Write slow (but correct) implementation then verify optimizations don't break anything with tests."

しかし, Medium ていい記事ばかりあるけどなぜなのかな.