のぶLab.

流しのソフトウェアエンジニアの雑記帳. Android, Scala, Clojure, Ruby on Railsなど

DroidKaigi 2017に参加しました [Day2]

DroidKaigi 2017の2日目(3/10)に(途中から)参加しました。 (1日目の記録はこちら)

ここでは私が聴いた講演のメモやら感想やらを載せます。

位置情報を正確にトラッキングする技術

※ 資料が公開されたらリンク貼ります。

位置情報トラッキングするノウハウの紹介。

コードから位置情報取得設定が可能。基地局情報を使用しないトラッキング方法だと精度が落ちるのでなるべく使うべき。

位置情報トラッキング中に障害物の遮蔽により精度が出なかったりAndroid OSでキャッシュした古い位置情報が返却されたりする。そのようなノイズを抑えるためにある閾値を超えた返却値は無視したり、KalmanFilterというFilteringを通すと上手く位置情報がトラッキングできる。品質もよく使われているアプリと遜色ない。

Error Handling in RxJava

speakerdeck.com

アプリ開発時によくあるユースケースをRxJavaのエラーハンドリングでどのように扱うかの紹介。講演の大半がエラーハンドリング系のAPIの説明に費やされてしまってたので"うーん。。。"と思ったのが正直なところ。

Rxは鉄道思考プログラミングのような表現が可能だと考えている。このように表現できるとユースケース単位で成功Pathと失敗Pathに分離され、それぞれのPathに集中できるので例外設計がやりやすくなったりするのかなーと思っている。そのあたりのヒントがあればと期待していたので少し残念。

テスト0から目指すクラッシュフリー率99%

speakerdeck.com

テストのない状況からソフトウェアを安定動作させるためにCrashlyticsやFirebase Crash Reportingを導入。クラッシュの原因を探ることができるようになる。Firebase Crash Reportingはクラッシュのコンテキスト(どの画面から遷移したか、どのような操作をしたか)を追うことも可能になる。

テストを書けない典型的なケースはFat Activity。責務を分離していってActivityを薄く持っていく。

DIするぞ->Dagger使うぞ!みたいな感じだと慣れていない人にとっては抵抗を感じる。まずはコンストラクタから注入する形から始める。

ContractorにPresenterとViewの責務を表現。Activity/Fragment/CustomViewでViewを実装、PresenterでAPIアクセスやDBアクセスの結果をViewに伝えるような仕組みにしてFat Activityを避ける。

非同期処理のコールバックには注意。FragmentのonResume ~ onPause以外でFragmentTransaction#commitするとクラッシュする。DialogFragment#show内部でもFragmentTransaction#commitを呼んでいるので要注意。

感想

契約による設計やDIなど特別新しいこともないノウハウでも丁寧にやっていけば良いソフトウェアになる。昨日の講演にあったDDDや単一責任原則などもそう。

今回DroidKaigiに参加してもっと古きを温めたい気持ちになった。

発表者の方々の培ってきたノウハウや苦労話など聴けてとても刺激を受けました。また来年も参加したい!