DroidKaigi2017 Day1レポート 午後

僕が参加したセッションについて、レポートをします！

Android定期実行処理入門 @kazy

• 定期実行処理の用途
  • 定期的にフィード更新など
• 実装方法
  • AlarmManager
    • 知見が多くある
    • シンプルなAPI
    • イベントを受け取るBroadcastReceiverを作る
    • 欠点
      • OSによって挙動が違う
      • 再起動するとスケジュールが消える
        • リブート時に再度登録してあげる
      • 時間以外の制約には対応できない
      • 失敗時のリトライ処理がない
    • 用途
      • 時間に厳密なタスクの実装
    • 向いていない
      • 再起動時のサポート、リトライ機構がほしい場合
      • 電力を意識した、パファーマンスを意識したいとき
  • JobScheduler
    • os5以上から
    • Serviceを任意のタイミングで起動できる
    • さまざまな設定ができる
      • リトライ
      • 繰り返し
      • ネットワークの状態
    • adbコマンドでjobがみれる
      • 登録されているjob
      • ヒストリーがみれる
    • 良い点
      • 先どうしてもちゃんと保持さている
      • 高度な設定
    • 悪い点
      • os5.0以上でしかつかえない
      • 知見が少ない
    • 罠
      • 設定していたスケジュールが突然消える
        • ５系でOSのアップデートの際に消える
        • パッケージが更新されたときに再度設定
      • デットラインの時間があいまい
        • 即時性を求めない
      • 一度きりのスケジュールのはずが複数回起動する
        • N未満では発生するので気をつける
      • 想定以上に動く
        • 冪等性のある実行
    • 5.0未満で対応したい
      • GcmNetworkManager
  • GcmNetworkManager
    • Google Play Service 7.5以上
    • JobScheduler同じような使用感
    • 欠点
      • play-services-gcmに依存
      • 将来性がわからない
        • Firbase JobDispacher
          • GcmNetworkManagerの代替
  • Firbase JobDispacher
    • メンテナンスが微妙
    • play service
  • GCM NetworkManagerを使う（個人的な感想）

解剖 Kotlin ~バイトコードを読み解く~ @sys1yagi

• Android StudioにデコパイルボタンでJavaに変換する
• null許容型で何をしているか
  • null許容型
    • nullに代入できる。返り値がnullになるもの
  • Javaでみると
    • null許容型
      • 何もならない
    • 非null許容型
      • ifでnullチェックしてる
    • !!
      • throwを投げてるだけ
  • 単純にnullチェックしてるだけ
• 関数型ラムダ式
  • 関数型をJavaに戻す
    • ファンクションの引数のインタフェースが作られるだけ
  • ラムダ式をJavaに戻す
    • ラムダのクラスが作られる
  • JackやJava8のアプローチと同じ
• 拡張関数
  • Javaにもどす
    • 対象のクラスを第１引数になるUtilのstaticメソッドが作られるだけ
• プロパティ
  • Javaに戻すと
    • private変数が作られ、getter,setterが自動で作られる
• まとめる
  • Kotlinこわくない
    • ちょっとしたコードを完結にしてくれる
    • あるあるを簡単にかける
• 言語機能が設計にあたえる影響
  • なるべく非null型で動作する部分を増やす

変更に強いEspressoテストコードを効率良く書こう @外山純生

• モチベーション
  • 工数削減、確認漏れをなくす
    • しかし作成の時間がかかる
  • まずは、効率的に楽してテストを書く
• UIテストのボトルネック
  • 捜査対象をみつけるのが大変
• Espresso Test Recorder
  • まだでたばかりで、できないことも多い
    • まずは得意なところをやる
  • 変更に強いテスト
    • コードが修正した時にテストを修正する箇所の数が少ない
  • 共通操作を切り出し、共通処理にする
    • ページオブジェクトテストパターン
    • 共通部分の切り出しは手で切り出す
  • テクニック
    • Android Studio ショートカットキーを活用
    • Espresso Test Recorderの出力を知る
• Espresso
  • Androidの公式のUIテストフレームワーク
  • 開発者オプションでアニメーションを切る
  • API
    • チートシートがある
  • できること
    • 基本コンポーネントサポート
    • 基本コンポーネント以外は専用API
  • 不得意なこと
    • 非同期の待ち合わせ
    • viewプロパティの動的な取得
  • 動かし方
    • Run Espresso testを起動する
  • 欠点
    • 動作がもっさり
    • 非対応コンポーネントがある
    • 確認手段が限定されている
    • 遷移も苦手
• どこをテストするか考える
  • Activityをきめる
  • コンポーネントは得意な部分だけにする
• テストケース共通化するとテストも変更に強くなる
• Rxの場合はカスタムテストランナーを作ると便利
  • Scheduleをayncaskに差し替えるなど
• 経験して引き出しを広げる

全てSになる〜RxJavaとLWSを持ち込む楽しさ〜 @ryugoo

• すべてSteamになる
  • Java8でのAndroid開発はどうなるのか
• Java8の例
  • lambda式
  • メソッドリファレンス
• Java8を使うにはJackを使用する
  • Instant Runが使えない
  • ビルドが遅い
  • API Lv24以上が必要
  • 未来すぎる
• Java8を早く使用するために
  • RetroLambda
  • Jackは切る、Java8使用を記述
• Steam API
  • RxJava
    • Androidが提供しているAPIよりかゆいところに手が届く
  • RxBinding
    • Viewのイベントをストーム化
  • RxAndroid
    • RxJavaをAndroidで使いやすくするためのライブラリ
  • RxLifecycle
    • Androidのライフサイクルに合わせて、中断などをしてくれる
• Lightweight-Stream-API
  • Java8で提供されたStream APIのバックポート
  • RxJavaの組み合わせ
  • RxJavaよりコレクション操作が得意
  • Nullとの戦いに有利
    • Optional処理が出いる
  • メソッドチェーンで処理ができ、上から下に処理をかける
  • ネストが深くならない
  • 宣言的にコードをかける
• RxJava + Lightweight-Stream-API
  • エラーハンドリング問題
    • 一度エラーが起きると購読が終了してしまう
    • Either Typeを定義する
      • 本当置きてはいけないエラーと意図して起きるエラーをわけられる

まとめ

実践的な内容ばかりで月曜日が Lightweight-Stream-APIとRxJavaは同じものかなっと思っていたら全然ちがうものだった。いろいろ試してみたくなりました。