【kyobashi.dex】Android勉強会を開催しました！#3

はじめまして，16卒新卒Androidエンジニアの松田です．

5/27(金)に kyobashi.dex の第3回目を開催しました．

http://rmp-quipper.connpass.com/event/31744/

kyobashi.dex とは

kyobashi.dex とは，京橋付近のAndroidエンジニアやそうでないAndroidエンジニアが集まり，情報共有する場を作るために企画された勉強会です．
弊社リクルートマーケティングパートナーズとQuipper社のスペースで開催されており，今回第3回目を開催する運びとなりました．

また今回よりホストが変更になりまして，kyobashi.dex グループから RMP×Quipper グループが運営することとなりました．¹⁾ホスト変更に伴った内容，ポリシー等の変更はありません．またイベント名の変更もありません．

発表資料のまとめと会場の様子

今回は全7件の発表がありました．
勝手ながら，タイトル記載部分において，発表者の方々の敬称は略させていただきます．

今回は発表が始まる前からお酒等の飲み物を配り，軽食を用意するラフな形で開催しました．

お酒片手に語らう人や発表資料をエクストリーム作成する人がいる中，弊社の kgmyshin 氏の発表から始まりました．

Advanced Data Binding by kgmyshin

Google I/O 2016でも講演があったAdvanced Data Bindingについてです．
スライドにもある通り，Google I/Oの講演内容についての発表ではなく，実際に触ってみた所感や生成されるコードについて発表してくださいました．

kgmyshin 氏はGoogle I/Oで聞いた発表について別途記事にしているので，興味のある方はそちらも御覧ください．
[Google I/O 2016] より使いやすくなったDataBindingの新機能とTips紹介

Data Bindingにより生成されるJavaは意外と直感的というか愚直な印象を受けました．黒魔術じゃないのはありがたいですね．

紹介された中でも双方向Bindingは便利ですし，利用するケースも多くあることが予想されます．
しかしながら独自の双方向BindingAdapterを作った場合，その挙動をテストによってきちんと保証する必要がありそうです．

MediaControllerをカスタマイズするぞ by ogapants

API1から存在する最古のViewの一つ，MediaContollerをカスタマイズしたいという話．
~~あまりにも使い勝手が悪いので，個人的にこのViewはモックアップ用だと思ってました~~

結局カスタマイズ性は全くといっていいほどなく，カスタムViewの作成しか道はないとのことで，OSS化に向けて作成を行ったとのことです．

個人的な感想になりますが，こういったViewの書き直しライブラリ系は，カスタマイズ性の高さを求めすぎたが故にバグが発生しやすい印象があります．
基本的な構成要素と機能を維持し，カスタマイズできる部分を絞ってコンパクトにまとまっているとのことで，OSSとしての公開が期待されます．

What's new Firebase App Indexing by shihochan

SEO対策の一つとして普及しているApp Indexingについての発表です．
Google I/O 2016より，Google App IndexingからFirebase App Indexingという名前に変更されることが周知されました．
今回の発表では，特に今回追加されたDigital Asset Linksについて詳しく発表してくださいました．

対応ドメインとなるサーバーにjsonファイルを置くことによって，リンクからの自動起動を保証する仕組みなようです．
同時にCustom Scheme利用が非推奨になったとのことで，セキュリティ強化の流れを見ることができます．

嬉しいことに，今回の変更点については元々App Indexingに対応していれば何の追加対応もいらないとのこと．
ただ現状，Auto CompleteやNow on Tapからの流入をアプリ側から判断できないとのことで，その部分については今後に期待したいところです．

MockRetrofit by izumin5210

有名なAPIクライアントライブラリであるRetrofitの2系を用いたテストには複数の方式が存在します．
今回はそれぞれの方式の利点や欠点についての発表をしてくださいました．

テスト用Mockクラスを作るか，Mockライブラリに委ねるか，擬似サーバーを作るか，Retrofit自体をMockするか，それぞれ実装やできることが異なります．
また発表スライドでも結論として「どれが一番いい」といったものは出ていませんが，スライドp21の表の通り，テスト規模や柔軟性を加味するべきでしょう．

弊社のプロダクトでもRetrofit2を使うものがあります．
そのプロダクトでは私がテスト環境と方針の整備を行ったのですが，発表スライド中では4番に相当するMockRetrofitを利用し，2番のシンプルなMock方式と組み合わせています．
チームメンバーに対して，一番導入コストと学習コストが低いものを選択したつもりではいるのですが，本発表を受けて，プロダクトにとってもより良い方法を模索する必要があると感じました．

Introduce Build-in shrinker by daisukefuji

64k問題が発生してしまったとき，Multi dexを使わずにデバッグビルドを乗り越えたいときにどうするかという発表をしてくださいました．

Multi dexを使わないとなるとproguardが思い浮かびます．しかしながらproguardをデバッグビルドでも使うと非常にビルド時間を食ってしまいます．
そこで「ビルトインのShrink機能を用いれば解決できる」というお話しだったのですが，Shrink機能をONにしたからといってなんの問題もなく一発動作！とはいかなかったようです．
例えばテスト時のUsageを拾ってくれず，メソッドが削られてテストが失敗するといった問題に遭遇した，などが挙げられました．

弊社プロダクトでは時間もなかったため迷うことなくMulti dexを選択しましたが，やはりビルド時間がネックになっています．
Shrinkだけで64k問題を回避できるならそれに越したことはなく，試してみる価値はあると思いました．

MediaStore by KeithYokoma

こちらも古より存在するクラスについての発表をしてくださいました．
大したドキュメントもなければ各ベンダーの影響も受けるなどなど非常に闇を抱えていながら，メディアを扱う上では避けがたいクラス「MediaStore」．

やはりそのまま扱うには非常に難しいとのことですが，こちらはViewと違って新たに作りなおすといった行為はできないという問題があります．そこでFacadeパターンによる対応をとったとのこと．
また薄いラッパーという立ち位置であるため，Rxなどによりさらにラップすることも可能な構造になっています．
まだリリースはされていないとのことですが，すでにGithub上にホスティングされており，コントリビュート大歓迎とのことです．

以前，とある案件でこのクラスを触ったことがありますが，本当に資料もなく，場当たり的な検証になることもありました．
もうあのような検証工程は踏みたくないので，もし仮に万が一，このクラスを使わなければならないプロダクトに関わることになった場合，断るぜひとも採用したいと思いました．

Gradle PluginとCIと俺 by operandoOS

Android開発では切っても切り離せないGradle，そのPluginには非常に便利なものが多いです．
今回の発表では通知系のGradle Pluginについて，CI上で動かすことを踏まえた発表をしてくださいました．

CIで走った1個1個のGradle taskの出力を目で見るのは非常に苦労してしまうので，特定のtaskに紐付いた通知を仕込むことは非常に有意義です．
しかしながら，ローカルで動かすたびに通知が飛んできてしまうと今度は邪魔でしかありません．
そこで operandoOS さんはSlack通知用のGradle pluginを魔改造し，通知のon/offを設定できるようなインターフェースを追加するなどし，CIならoffにできるようにしているようです．

CIの設定ではなく，Gradleから選択的に通知ができるというのは非常に便利ですね．
今度いくつか通知タスクを差し込んでみようかと思います．