この記事はMonstar Lab, Inc. Advent Calendar 2016 2日目の記事です。
前日は @shanonim の Philips Hue x Johnny-Five x 温度センサ(LM35)でオフィスIoTやってみた - Qiita でした。
自宅用にHueがほしいですね。最近、金使いすぎなのでもうちょっと後でにはなりますが。。
Johnny-Fiveはお手軽にデバイスを操作出来て良いですね。
概要
とあるプロジェクトで、Androidアプリにログ系のライブラリを導入してみました。
その中で感じたことをまとめたメモがあったので、その焼き直しです。（新しい記事を書く時間が無かった。。。）
また、経緯に関しては記憶を辿って書いているので、フィクションの可能性があります。技術的な部分は大丈夫なはずです。
先に結論
Timber はいいぞ。
いままで
android.util.Log を使っていました。
また、本番リリース時にはproguardによって、削除していました。
理由としては、秘匿情報を知られてしまう可能性、パフォーマンス劣化を防ぐためですね。
参考： Yukiの枝折: Android:ログコードをProguardで削除する
ただこのLogクラス、常にtagが必要になり、下記のようなボイラープレートコードが量産されました。
private static final String TAG = HogeFragment.class.getSimpleName();
これもAndroid StudioのSnippet（だったかな？）を使えば、簡単に追加できますが、やっぱりコードは少ないに越したことはないので、微妙でした。
とあるプロジェクトでの話
そんな経緯があったので、「なんか無いかなー」と探したところ、zserge/logというものを見つけました。
その時のプロジェクトでは、すでに実装が始まっており、android.util.Logを利用していたので、「Log.d(TAG, "hogehoge");って書いているところそのままで、とりあえずimport文だけ変えれば簡単に導入できるやん！」ということで、導入してみました。
実際導入するときには、android.util.Logをgrepして、trikita.log.Logに変換するだけで、一旦は置き換えが完了し、順次TAG定数の削除、引数のTAGの削除をするだけでした。
※ 今確認すると、 https://github.com/zserge/log#migration-from-androidutillog ここに移行コマンドがあったんですね。
細かいところですが、「ここでログ出力したほうがいいかな？」と考えたところで、TAG定数の有無を確認→定義→やっと実装となっていたところが、頭を使わずにログを出せるようになったのは良かったです。
徐々に辛くなってきた話
クラス名が同じため、移行が簡単だったのは良かったのですが、実装中はちょっと邪魔でした。
Logと書いたときの候補として、2つ出てきてしまいます。
コード書くときに気をつけなければならないことが増えてしまいました。
特に、何も考えずにEnterを押してしまって、android.utilをimportしてしまったときは、Ctrl+zで戻ったりが面倒でした。
別のプロジェクトの話
そのプロジェクトはそのままですが、別のプロジェクト始めるときに、再度ログ系ライブラリを探してみました。
すると、Jake神がTimberというのを作っているではありませんか。
こちらも勝手にTAGに設定する文字列を作ってくれるみたいです。
また、READMEに記載されている通り、Android Studioでコード書いてるそばから、warningを出してくれるので、文字列連結をしてしまうことも無く、パフォーマンス的にも劣化が少なそうです。
また、Timber.plantによって、Logcat以外の場所に出力することも容易です。
AndroidのTimber(ログ系)とFabric/Crashlytics(クラッシュレポート)を使ってみた。 - さまよえる、Android にあるように、本番ビルドのときには別のTreeをplantしておけば、WARNのログをcrashlytics上で見れたり出来て便利です。
同様に、Treeを自分で書けば、FirebaseのCrash Reportingに飛ばすことも出来ます。
https://github.com/noboru-i/kyouen-android/blob/16eed54/app/src/main/java/hm/orz/chaos114/android/tumekyouen/App.java#L53
今後
新しいAndroidアプリのプロジェクトがあれば、とりあえずTimberを入れて、Timber.DebugTreeをplantしておけば良いと思ってます。
開発がある程度進んできた段階で、FirebaseやFabricを導入して、必要なTreeをplantする感じで。
明日は、、、誰も入ってないですね。気力があれば、連続で書こうかな。無いかも。
気力が無ければ、次は5日目の @aratafuji さんです。楽しみですね。