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
- Firbase JobDispacher
- メンテナンスが微妙
- play service
- GCM NetworkManagerを使う(個人的な感想)
- AlarmManager
解剖 Kotlin ~バイトコードを読み解く~ @sys1yagi
- Android StudioにデコパイルボタンでJavaに変換する
- null許容型で何をしているか
- null許容型
- nullに代入できる。返り値がnullになるもの
- Javaでみると
- null許容型
- 何もならない
- 非null許容型
- ifでnullチェックしてる
- !!
- throwを投げてるだけ
- null許容型
- 単純にnullチェックしてるだけ
- null許容型
- 関数型ラムダ式
- 関数型をJavaに戻す
- ファンクションの引数のインタフェースが作られるだけ
- ラムダ式をJavaに戻す
- ラムダのクラスが作られる
- JackやJava8のアプローチと同じ
- 関数型をJavaに戻す
- 拡張関数
- Javaにもどす
- 対象のクラスを第1引数になるUtilのstaticメソッドが作られるだけ
- Javaにもどす
- プロパティ
- Javaに戻すと
- private変数が作られ、getter,setterが自動で作られる
- Javaに戻すと
- まとめる
- Kotlinこわくない
- ちょっとしたコードを完結にしてくれる
- あるあるを簡単にかける
- 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のライフサイクルに合わせて、中断などをしてくれる
- RxJava
- Lightweight-Stream-API
- Java8で提供されたStream APIのバックポート
- RxJavaの組み合わせ
- RxJavaよりコレクション操作が得意
- Nullとの戦いに有利
- Optional処理が出いる
- メソッドチェーンで処理ができ、上から下に処理をかける
- ネストが深くならない
- 宣言的にコードをかける
- RxJava + Lightweight-Stream-API
- エラーハンドリング問題
- 一度エラーが起きると購読が終了してしまう
- Either Typeを定義する
- 本当置きてはいけないエラーと意図して起きるエラーをわけられる
- エラーハンドリング問題
まとめ
実践的な内容ばかりで月曜日が Lightweight-Stream-APIとRxJavaは同じものかなっと思っていたら全然ちがうものだった。いろいろ試してみたくなりました。