DroidKaigi2019 2日目に行ってみた感想とか
こんにちは、tkyです。
2日目も行ってきました。1日目と同じようにセッション参加したtkyの個人的感想を述べる内容となっております。
1日目のレポートはこちらをご覧ください
この日見た講演はなんと8講演。疲れた・・・けどとても濃い1日でした
- Dialogflowによる自然言語処理(NLP)を用いたボイスコマンド音声認識の精度向上(10:30~)
- Wi-Fi RTTによる屋内測位アプリを作ろう(11:20~)
- All About Test of Flutter(12:50~)
- Lifecycle, LiveData, ViewModels - The inner wiring(14:50~)
- multi-module Androidアプリケーション(15:40~)
- Navigation Architecture Component によるアプリ内遷移の管理(16:50~)
- Android Thingsでのプロダクト開発(17:40~)
- BLEアプリ設計パターン(18:30~)
最初は朝ごはん
会社に行くより早く電車に乗り、9:40くらいに会場到着。サンドイッチやコーヒー、紙パックジュースなどを堪能できました。
エキシビジョンルームにて朝食が配布されています。
Dialogflowによる自然言語処理(NLP)を用いたボイスコマンド音声認識の精度向上
Dialogflowはgooglehomeアプリを作成する際にも使われますので、興味アリアリです。
googlehomeのアプリをサンプルで作った時にDialogFlowを使ったことがあるのですが、Androidアプリからも使ってみたいですね！聞くところによるとv1のsdkは2019.9にDeplicatedになるので要注意だそうです。v2との使い勝手はどう異なるのだろうか。
DialogFlowについては本ブログでも別途触れてみたいなと思います。
やっぱり、固有名詞を検出するにはEntityを設定しまくるしかないのですね。音声認識の揺れを吸収するためのアノテーション作業などはやったことないので後ほど見てみたいと思います。
Wi-Fi RTTによる屋内測位アプリを作ろう
WiFi RTT(Round Trip Time IEEE 802.11mc)全然知らないから気になってました。
基本的にFusedLocationを使って位置情報を取得します。これを使うことでGooglePlayServicesを経由して位置情報を取得するようにできます。 WifiRTTは屋内でも使用できる位置測位用の規格であるため、アクセスポイントを4つ使うと精度は1mとかなり良くなる状況だそうです。
アクセスポイントからの距離はわかるが、アクセスポイントがどこにあるかは知っておく必要がある、なるほど 👀 測位方法はピタゴラスの定理と連立方程式を組み合わせて実現するようです。
少なくとも3点測位ポイントがあり、その3点のポイントを線で結んでできる空間内にいる必要があることが測位方法から見ても理解できるかと思われます。
API28からscanのAPIが色々変更担っているようでDeplicatedにもなっている模様
精度を出すための条件がなかなか厳しそうですね。アクセスポイントの設置場所や地図の選定など、やることは色々ありそうです。 他のセンサーも併用して使うとより精度の向上が図れそうと思いました。
ここでお昼ご飯
1日目のお弁当を撮影しそこねましたが、2日目はちゃんと撮影できました、この後のFlutterのセッションルームにて着席して昼食休憩です。
All About Test of Flutter
you brideという婚活支援サービスがFlutterで作成されているようです。
今回のgithubも要チェケです。
自分のコードに自身を持って確かなものにするためにテストを書く。いい話だ。
名言も飛び出ましたｗ
人間は超優秀全自動アサーション関数
自動テストにするか、人力テストどちらを取るかは、継続してコスト回収できるかどうかで判断すると良さそうです。
めちゃめちゃ良い発表スライドで、終わった後もガッツリ見てます！
質問時間にて、未実装部分についてはスキップ関数にするのか、Failさせるのが良いのか議論が最後に行われていました。 単純にFailした場合と未実装なのでFailなのかがパット見わからないので、メンバーのテストリテラシ状況に合わせて選択するのが良いのでは、という結論にいたりました。
また、テストレポートについては現状HTMLなどで見れるようなものはこのとき回答はありませんでした。コマンドライン上でもギリ見やすそう・・・？
小休憩
ちょっとだけ疲れたので小休憩です。
Clip Roomさんのブースでデザインガイドラインの一部を見せていただいたりしました。やっぱりデザイナーさんとエンジニアがコミュニケーションとれる状況良いですね。
そしてまたコーヒー・・・美味しいんですよね〜
Lifecycle, LiveData, ViewModels - The inner wiring
architecture componentの講演となります。英語のセッションですが、同時翻訳なので安心？して聞けます。 Architecture ComponentのLifecycleコンポーネントなどなどの解説となります。
LiveDataはデータホルダーであり、streamが終わるという考えはなく、ライフサイクルで使われるため、本質が異なるということですね。 しばしばLiveData vs RxJavaというように比較される事が多いのですが、そもそも本質が異なるためにLiveDataとRxJavaがともに存在する、という認識が出てきました。
翻訳が非常に聞き取りやすく個人的に理解が進みました。
multi-module Androidアプリケーション
https://speakerdeck.com/sansanbuildersbox/multi-module-android-application
なんとかマルチモジュールの講演入れました！
SanSanのEightではモジュール40個で構成されている、すごい分割数だ・・・
モジュールに分けることでプロジェクト内のコンパイル単位を分割できたり依存管理できるのか良いところですね。
- ビルドが高速化できる
- コードの依存関係を強制できる
- モジュールごとにテスト実行できる
- Kotlinのinternal修飾子でモジュール内で可視性を定義できる
- Dynamic Feature Moduleでインストール時の容量を下げる
色々メリットがありますね！
gradle plugin 3.0になってからのimplementation指定と過去のcompile指定の挙動の違いについてちゃんと理解していなかったのですが、解説を聞いてスッキリしました。
gradleのビルド結果は--scanオプションで見れる！へぇ！
incrimental buildの場合だと並列マルチモジュールだとビルドが早いですね。Annotation processingの実行をコストが抑えられることがポイントのようです。
realmを使用したマルチモジュール化の高速化例も紹介いただいて理解が進みました。チーム全体のマルチモジュールについての理解の底上げも重要ですね〜。
どうマルチモジュール化したら良いのか
モジュール分けする際にレイヤーで分けるのか機能で分けるのか、結構迷うのですが、
app → data → domain → ui → domain
という構成でまとめると良さそう！
機能ごとに分けるときも画面遷移のIntentをinterfaceとしてapp側で持ってあげて各画面にDIすることで依存関係をフラットにすることができるので、1対多(画面)の構成が作れそうだと思いました。
eightでは機能ごとにモジュールを分けているみたいですね。
すごくためになるセッションでした！
Navigation Architecture Component によるアプリ内遷移の管理
Architecture Componentに関する講演です。
画面遷移時の課題を解決できるようなライブラリとツール群のことですね。
Navigation Architectureにおいてはどの画面がスタート地点になる画面なのかをガイドラインとして定義されているようです。 deep linkについても「同じ画面にいるなら、同じ画面スタックが形成されているべき」というような原則が存在しています。
navigation を定義するxml内でfragmentを定義し、fragment layoutの中にapp:navやandroid:nameの記述を書くことでNavigationの遷移を実現できるみたいです。
あとはJavaとKotlinでSafeArgsの指定の仕方が異なるようですね。JavaはBuilderパターン、Kotlinはnamed argumentで指定、という具合です。
最近のAndroidの開発に触れていないので、結構新鮮でした。
Android Thingsでのプロダクト開発
DroidKaigi2019 AndroidThingsでのプロダクト開発 - Google スライド
Android Thingsはgoogleが提供するIoT向けプラットフォームのことです。 Androidなので既存のシステムを利用できるところは強いですね。ハードウェアレイヤもGoogleがサポートしているようなのでこういったところも強みになりそうです。
最初はmuiの製品紹介から入ります。スマートディスプレイの代替としての製品のようです。 muiプロダクトデモを実際に見せていただいて実感がわきます・・・！！！
AndroidThingsとAOSP,Linuxとの違いについては、カーネルのカスタマイズができるかどうか、SoCの選択肢があるかどうか、OTAができるかどうか、が選定のポイントとなりそうです。
メリットは以下。
一般のデベロッパーがさわれる領域にPeripherarl I/O APIの入出力をフレームワークに統合するためのUserDriver(Input Driver)というものが結構微妙(画面描画あたり、座標空間周り)らしいですね。UserDriver(InputDriver)とはI2CのIOをボタン押下イベントに変換するようなものらしいです。
基本カーネルやフレームワークはGoogleが完全に制御しているので一般デベロッパーは触ることができず。 先程まで強みだと思っていた点が回り回ってデメリットになってきました・・・カーネルをカスタマイズできない点については、ラズベリーパイで発生するclock stretching問題において重要な欠点のようです。というのもこの問題を暫定で解決するためにI2Cのボーレートを変更する必要があるそうですが、OTAでファームウェアを流し込んだ時にその編集部分のコードが上書きで消えてしまうそうです。事実上OTAできないじゃん！ということになるわけですね・・・闇が見えてきました
新規でThingsのプロダクト化が難しい状況で有ることがわかりました・・・ｗ セッションが悲しい雰囲気に包まれてしょんぼりだったのですが、トライ＆エラーの結果を共有していただけた非常にためになるセッションでした！！
BLEアプリ設計パターン
BLEのつらみについては触れず、設計ノウハウにフォーカスしたお話です。
BLEはHTTPSのようなプロトコルとどう違うのか、実際にどのように設計しているのかをノウハウ共有いただけるセッションでした。Qrio Lockはいわゆるスマートロックで、BLE通信を使って鍵の開け締めを行っているようです。
通信という意味ではWifiという選択肢もありますが、省電力や近接検知ができるという観点で、BLEの選択肢が出てくるということですね。
Webの世界はRetrofitのようなライブラリを使うと非常に楽になったしますが、BLEは20バイト制限があるので、 20バイト以上のデータを扱うときはパケットを分割して受け取った側でくっつけるような、HTTPのプロトコルが担保する領域を自分で担保する必要があるようです。なるほど・・・
BLEが仕様で搭載しているセキュリティではできない自前でセキュリティを担保する必要も出てくるとのこと。なかなかつらみが出てきましたね！！
「ロック(スマートロック機器)の名前」は情報をデバイスで持つべきか、サーバで持つべきか、という観点も非常に興味深いです。
→結論的にはwebサーバ側で情報を持って、デバイス側は極力シンプルな構成にすることが良さそうです。
登場人物がスマートロックデバイス、スマホ、webサーバが存在しており、この3者がうまく同期している必要があるのもなかなか難しい課題です。 この際の通信の整合性を担保するためにべき等なAPIにする必要があることも重要ですね。
実際にアプリはMVVMで作成されているようですが、テストに関するメリットは高く、 しかしながら責務分けに関するベストプラクティスを探すようなコストも高くなってしまうこともあるとのことです。
さいごに
2日間有休を使って参加しましたが、最高に楽しかったです。こういうの参加するとやる気出ますね。来年も行きたい。。。行けるようにがんばります。 色々と新しい単語もピックアップできたのでこれからも継続して勉強していきましょー
いただいたものたち
