DroidKaigi2017 Day1レポート 午後

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

Android定期実行処理入門 @kazy

  • 定期実行処理の用途
    • 定期的にフィード更新など
  • 実装方法
    • AlarmManager
      • 知見が多くある
      • シンプルなAPI
      • イベントを受け取るBroadcastReceiverを作る
      • 欠点
        • OSによって挙動が違う
        • 再起動するとスケジュールが消える
          • リブート時に再度登録してあげる
        • 時間以外の制約には対応できない
        • 失敗時のリトライ処理がない
      • 用途
        • 時間に厳密なタスクの実装
      • 向いていない
        • 再起動時のサポート、リトライ機構がほしい場合
        • 電力を意識した、パファーマンスを意識したいとき
    • JobScheduler
      • os5以上から
      • Serviceを任意のタイミングで起動できる
      • さまざまな設定ができる
        • リトライ
        • 繰り返し
        • ネットワークの状態
      • adbコマンドでjobがみれる
        • 登録されているjob
        • ヒストリーがみれる
      • 良い点
        • 先どうしてもちゃんと保持さている
        • 高度な設定
      • 悪い点
        • os5.0以上でしかつかえない
        • 知見が少ない
        • 設定していたスケジュールが突然消える
          • 5系で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にもどす
      • 対象のクラスを第1引数になる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の例
    • lambada式
    • メソッドリファレンス
  • 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は同じものかなっと思っていたら全然ちがうものだった。いろいろ試してみたくなりました。