ButterKnife 8.0 に更新で @Bind → @BindView など

更新されています.

Butter_Knife

Version 8.0.0 (2016-04-25)

- @Bind becomes @BindView and @BindViews (one view and multiple views, respectively).
- Calls to bind now return an Unbinder instance which can be used to null references. - This replaces the unbind API and adds support for being able to clear listeners.
- New: @BindArray binds String, CharSequence, and int arrays and TypeArray to fields.
- New: @BindBitmap binds Bitmap instances from resources to fields.
- @BindDrawable now supports a tint field which accepts a theme attribute.

-The runtime and compiler are now split into two artifacts.

compile 'com.jakewharton:butterknife:8.0.0'
apt 'com.jakewharton:butterknife-compiler:8.0.0'

- New: apply overloads which accept a single view and arrays of views.
- ProGuard rules now ship inside of the library and are included automatically.
- @Optional annotation is back to mark methods as being optional.

butterknife/CHANGELOG.md at master · JakeWharton/butterknife

明示することで, バインドできるリソース範囲を広げながら処理速度は落とさない.

あと, proguard 記述は不要なのだとさ.

Butter Knife

苦労した経験から学んだ 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 ていい記事ばかりあるけどなぜなのかな.

res ディレクトリは小分けにしたほうがいいのではないか

java ディレクトリ以下は, お好みで小分けして素早くたどりつけるのに,

1-A-m20R0Qve-eB4ishqZc_Q

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

res ディレクトリ以下ときたら, なんの整理もしなくて, 該当ファイルになかなか辿りつけない.

res ディレクトリ以下も, 共用/画面別に分けたりするのはどうでしょうか, と GoogleDeveloperExperts の方が言っておられます.

Android_Project_Structure_—_alternative_way_—_Google_Developer_Experts_—_Medium

小分けにしても, マージして読み取ってくれるんですね.


sourceSets {
    main {
        res.srcDirs = [
                'src/main/res-main',
                'src/main/res-screen/about',
                'src/main/res-screen/chat',
                'src/main/res-screen/home',
                'src/main/res-screen/login',
                ....
        ]
    }
}

「Project View」でしか利用できないそうですが.

Android Project Structure — alternative way — Google Developer Experts — Medium

In this case, both resource folders have the same priority. This means that if a resource is declared in both folders, the merge will fail and an error will be reported.

Resource Merging - Android Studio Project Site

マージ後に重複するファイルがあればエラーとなり, 各ディレクトリ同士の優先順位はなしのフラット扱いらしいです.

IDE自体にどんな便利なショートカットや検索機能があったとしても, 直感的にわかりやすい構成にしておきたいですよね!