はじめに

2019年2月7日(木)にAndroid アプリ開発者向けの大規模勉強会、
DroidKaigi2019に行ってきました!
この記事は1日目の感想記事になりますー。

DroidKaigiについて詳細はこちら。

droidkaigi.jp

感想と当日のメモ

セッションを聞いてる最中にメモした内容と感想です。
DroidKaigi2019は同時に複数のセッションが開催されるので、
一人で全ては見れません。
今回は私が生で見たものだけの感想ですー。

あとメモは聞きながら取ったので、正確な内容や詳細は資料を御覧ください。
(メモのフォーマットが毎回バラバラですいません…)

また、当日の様子はTwitterのハッシュタグから振り返ることができます。
各部屋ごとにハッシュタグが違うので、気になる方はそれぞれどうぞ!
例：#droidkaigi #room3 - Twitter Search

なお、タイムスケジュールはこちら。

ウェルカムトーク

資料。

1日目の最初は全員参加のウェルカムトークから。
DroidKaigiは今年で5回目。
開催目的はAndroid アプリ開発の技術情報共有とコミュニケーション。

スピーカー、参加者の合計は1000人。
87セッション。
100人の共同含むスピーカー。

LiveStreamingは実験的なもの。
一部のセッションのみ対応。

全てのセッションは録画されている。
あとで見れる(誰でも?)

会場は1階にある大きめのホールのほか、5Fの会議室をいくつか使う。
個人的に上下に移動する形式なのは初めて。
RSGTでは大きめのホールを区切ってセッションしていた。

昨年のアンケートでバリスタさんが忙しすぎてかわいそうという意見がw
マシンの数を2倍に増やした。
初日は500杯以上のコーヒーを入れたそう…。
なお、コーヒーはエスプレッソで、
7割くらいは牛乳だけどそれでもしっかりコーヒーの風味が感じられるほど。
非常に美味しい!

公式アプリの話。
iOSもあったのか…。
ダウンロードすればよかった。
(のちほどDLしたけどiOS版はアンケート機能がなかったのが残念…)

コントリビューターの数は145名ほど。
中学3年もいた。

2日目は朝ごはんもある。

10:20 マルチモジュールなプロジェクトでテストはどう変わる？

資料。

マルチモジュールとは?
複数のappsに分けるアーキテクチャ。
builde.gradleに依存関係を追加する。

差分ビルドによる時間短縮
Appバンドル　インスタントapp対応のため
影響範囲の限定

テストはシングルモジュールと基本同じ。

悩み

モジュール間の依存関係をクリーンにしたい
Activityはモジュール、ApplicationはappsのときにDIで困る
依存関係をモジュール内で完結したい

tkmnzmさんのGithubに今回のサンプルもある。
GitHub - tkmnzm/MultiModulePlayground

モジュール内で動作確認を完結したい

※ ITテストとは
インテグレーションテスト。
永続化とかプラットフォームが絡むもの

モジュール化の視点

テストの組み方はひとつじゃない
最上位はユニットテスト、そこから先はモック化するとか、
すべてITテストでやるとか
なにから手をつけるか
ユニットテストで十分なところは、ユニットテストで始める
テスタビリティは意識して実装する
じゃないとテストを書きたいときにリファクタリングが先になってしまう。
モジュール間テストの話
他モジュールの依存がDIできていれば今まで通りでOK

テストを書く際のポイント

自分のプロダクトではどんな不具合が起きやすいか?を考えるとよい
他にはカバレッジなどのメトリクスをとること。

テストメトリクス
Jacoco
JUnit
マルチモジュールではモジュールごとの結果をマージする必要がある
そこでPIT。
PIT結果をマージする仕組みがある。
MutationTestについて
PITはMutationTestも可能。
MutationTestとはテストコードを変更してテストしてみて、
テストコードがちゃんと失敗するか確認するテスト。
(テストコードのテストみたいなもの)
境界や異常系などが抜けてないか確認できる

感想

マルチモジュールという考えを知らなかったので、
非常に参考になりました。
意図せずに自分も知らないことが知れるのも勉強会の良いところ。

説明が非常にわかりやすくサンプルもあること、悩みや自らが得られたポイントなども丁寧に説明していただき、
素晴らしいセッションでした。

個人的に、ひとつ目から学びが多くて嬉しい。

11:20 マルチモジュールプロジェクトでのDagger2を用いたDependency Injection

資料。

サンプルコード。
github.com

DIはnewするか、コンストラクタで入れるか?みたいな感じ。

アプリケーションでDIを実現するには、「どこに」「なにを」注入するか把握する必要がある

型とインスタンスを紐づける。
Hoge型をください　← インスタンスはコレです　みたいな感じ。

「どこに」を知っている密結合になってしまうため、
DaggerAndroidを利用してそれを隠蔽する。

マルチモジュールでの辛さ
injectを複数回書くとあと勝ちになり、最初の方はクラッシュしてしまう。
ApplicationにはFragment用kinjecterしか持てないため。
なら、Injecterを複数持てるようにすればいいのでは?

というわけで、DaggerAndroidを拡張して複数持てるようにした。
(サンプルコードを参照のこと)

Dynamic Feature Moduleの時は注意が必要。
依存関係が逆になるのでinjectするタイミングが重要。

感想

マルチモジュールを知った後にこの話を聞いたのもあり、
やはり何も考えずに使えば良いものでは無いなと反省。

良さげなものを見つけると、ついついすぐそれを導入したくなるので…。
ちゃんと理解して、チームに合わせて検討する必要がありますね。

依存性注入については2日目の入門セッションを聞いて理解したい。

12:50 アプリをさらに成長させるための技術戦略（振り返りとこれから）

資料。

マッチングアプリ、たっぷる誕生のエンジニアさん。

Androidアプリの変遷。

　立ち上げ　　　　Java
　急成長　　　　　ライブラリ追加　CI導入
　改善　　　　　　状態管理の改善　Dialog周りなど
　スタンダード化　CleanArchitectureを意識したMVVM、Kotlinなど
　その後　　　　　技術を誇れる組織へ

技術を誇れる組織とは?
　チームで考えた
　現実から理想までのギャップを埋めていく
　　絶賛成長中のアプリをさらに成長させるための戦略

技術戦略について

　ネイティブ技術戦略
　　ユーザー体験にコミットできる環境構築
　　　仕様決めからリリースまで素早く行う
　　顧客価値を最速で届ける

　アプリ開発はジェンガに例えられる
　　下手に触ると崩れるような不安定さになりやすい

　Flux化
　　MVVMからの変更
　　　ViewModelの責務分割をしたかった(データ操作周りとViewの状態管理)
　　　ViewModelの肥大化防止
　　　マッチングアプリは状態管理が複雑なのでこれをFluxで1箇所にまとめたかった。

　テスタブル化
　　通信周りなどstaticで呼んでいるとmockにしづらい。
　　だから、外から渡すようにしてあげるようにする(依存性注入)

　テストカバレッジ化
　　エンジニア目線の仕様書として考える
　　　想定外の挙動を定義できる

　Kotlin化
　　みんな大好き

今後

　マルチモジュール化
　　差分ビルドが早い
　　internal modifierによるスコーブ極小化による見通しの良いコード
　　機能開発を安全化
　　　デバッキングモジュールを介すことでお試し機能などを安全に本番ソースから分割できる。

振り返って良かった点

　エンジニア全員での目標
　エンジニアからの課題感をチーム全体へ共有
　元から改善に前向きなメンバーに光を当てられた

改善

　目的を明確に
　0/1ではなくて段階的な評価にする
　進捗の計測、可視化
　ペアプロ/モブプロの目的の共有
　みんなで相談する用のリポジトリ
　　issueで相談事を共有する
　マルチモジュール化
　　この機能をfeatureに切り出すにはどうしたら良いのか?で考える
　技術推進戦略を推進する工夫
　　月に一回、技術推進Dayを設けて改善する。
　エンジニアから機能提案をする
　　ユーザー目線になるため

まとめ

　理想と現実のギャップの認識を合わせる
　やりはじめたら計測をする
　小さく始める。勢いに任せない
　小さな成功から、チームで喜ぶ

感想

個人的に技術そのものよりチームで上手く開発する工夫や、
取り組んでいることに興味があるので、非常に前のめりになって聞いていました。

アプリ開発はジェンガに例えられるのように、何もしなければどんどん不安定になっていきます。
そしてそれは誰かがやればいいではなく、
チームとして取り組んでいくべき課題だと思います。

その課題に対してチームで対応していき、
メトリクスを取りつつ前に進んでいることに非常に感動しました。
素晴らしい発表をありがとうございました!

こうなれるように自分にもできることをやっていこう。

14:00 PWAでここまで出来る

資料。

サンプルコード。
GitHub - SAMUKEI/droidkaigi2019-sample-pwa

PWAとは

　Webサイトをネイティブアプリっぽく提供するもの

特徴
　段階的
　　すべてのユーザーに利用してもらえる(環境の差異に依存しない)
　レスポンシブ
　ネットワーク接続に依存しない
　アプリ感覚
　常に最新
　安全
　　HTTPS
　発見しやすい
　　Webで検索可能
　再エンゲージメント
　　プッシュ通知可能
　インストール可能
　リンク可能

構成する技術要素
　ServiceWorker
　Webアプリマニフェスト
　 HTML5/API

ポイント
　マニフェストファイルやServiceWorkerの登録はルート配置でやった方がよい

TikTokっぽいアプリをPWAで作るサンプル

GitHub - SAMUKEI/droidkaigi2019-sample-pwa

Webで動画や音楽再生、録画など
　MediaRecorderAPIで簡単にできる

ローカルDB
　Indexed DataBase

オンラインストア
　firebase storage

通知
　WebNotificationApiにて可能

APK化してストアに公開可能
　PWA Builderというサイトで可能
　Trusted Web Activityという新しい仕組みもあるらしい
　 Google Play Store now open for Progressive Web Apps 😱
　日本語の要約記事があったので追加。
　Google Play StoreでPWAを配信できるらしい | Hypertext Candy

iOSでも可能
　注意点として、通知が対応していない

感想

近い将来、PWAをやるかもしれないので勉強のために聞かせて頂きました。

思っていたより簡単そうで、これならすぐにでも試せそうな印象を受けました。
ですが、おそらくこれから始める新しいサイトであること、
ほぼ静的なサイトであることが簡単そうな印象を受けたのだと思います。

実際に前職でやっていたPHP +PostgreSQL + jQueryなサイトでやろうと思ったら、
死ぬほど大変そうですね…。

要点がまとまっており、非常にわかりやすいセッションでした。
やはり動くものがあるとイメージが湧きやすくていいですね。

14:50 The good and bad of modern app architecture

資料は見つからず…。

ドイツでBMWなどに対してAndroid開発を行なっていたAndroidエンジニアさん。

現在はユニクロアプリの改修をされているとのこと。
Johannesさんが開発に参加した時、ネイティブとWebによって画面下部のフッターが違ったりした。

またユニクロだけでなくて、他のブランドでも使い回せるような構造にする必要にしたかった。
(GUとか)

そのため、キレイに分割できるようにCleanArchitectureで設計した

Repositoryパターンだけど、iOSと同じような構造にしたくて名前をDataManagerに変えた

ViewModelとModelの一部(Domain)をブランド間で使い回せるようにしている。

たくさんのライブラリ、コンポーネントがある
　ObjectBoxというライブラリ
　 https://objectbox.io/
　このように知らないものあるので、オンボード(新人が開発に慣れるまで)まで5ヶ月ほどかかる
　高すぎるほどではないがコストがかかる

上手くいかなかった事例として、
USECASEを意識してテストコードをより英語っぽく書けるような仕組みを導入した
　英語読めない人がこまった
　今まで違うのでめっちゃ学習コストと実装コストが増えた

メンテナンス性を意識して作るがリリースが迫るとメンテナンス性が下がる。
だから、メンテナンス性を意識してアーキテクチャを構築し、
それを守ることでリリース後もメンテナンス性を保つことが大事。

感想

DroidKaigi初の同時通訳セッション。
RSGTで経験してたけど、
やっぱり英語と日本語を同時に聞き取ろうとして上手く理解できませんでした。

内容としては特にアプリのアーキテクチャを示した図が非常に参考になったこと。
いま思えば写真を撮ればよかった…。
かなり考えて作られており、
基本ルールとして定義しているがあえて崩している部分もあったということ。

特に「他のブランドでも使い回せるような構造」はこのアーキテクチャによって実現していたっぽいので、
Twitterなどで画像があるかなーと思ったけどなかった。

せっかく確認したので検索結果を貼っておきますw
#droidkaigi #room3 since:2019-02-07 until:2019-02-08 - Twitter Search

他にも失敗事例をちゃんと共有してくれていたのが、
非常にありがたいと思いました。

15:40 Understanding Kotlin Coroutines: コルーチンで進化するアプリケーション開発

資料。

コルーチン。
　どうやって使う?
　いつ使うべきか?

コルーチン
　・軽量なスレッド
　・スレッドを管理するバックグラウンドスレッド

スレッドはブロック、コルーチンは中断するもの
　中断はsuspendが指定されたメソッドでのみ中断できる
　スレッドはそのスレッドの処理が全て終わらないと次に行けない(中断できない)
　コルーチンは途中で中断して別のコルーチンを呼べる

コルーチンのコは複数のルーチンが強調して処理すること
　コプロセッサのコっぽい。

コルーチンの中止
　コルーチンスコープが提供するジョブが必要
　launch関数はコルーチンを作るビルダーである

GlobalScopeとは
　シングルトンのようなアプリ全体のスコープ
　スコープができすぎるので普通は使わない
　明示的に適切な小さいスコープを自身で定義すること

キャンセルはlaunch関数の戻り値.cansel()で止められる
join関数で待つことを忘れないこと

並行性と並列性
　並列性はCPUがふたつあること
　並行性はリソースを共有して複数の処理やっていく感じ?
　AAAA　　　　AAAA のような感じ
　　　　BBB
　　　　　　CC
　1個しかない部分で複数の処理をやるのが並行性。
　複数で同時に作業するのが並列性。

構造化コンカレンシー
　CorutineScopeの元となる考え方
　並行性を簡単に実現するための仕組み

処理の待ち合わせ　async{}とawait()で、async定義した処理が終わるまで、awaitの部分で待てる。
　これによりコルーチン内部で処理の待ち合わせをする。

現在のアプリ開発の課題
　理想はすばやく、品質よく、価値のあるものを
　課題
　規模が大きくなる
　高い効率化と拡張性が求められる
　Androidの大きな制限
　メインスレッドを止めるな

モジュールの原則
　関心の分離
　モジュール構造

サンプルで見るコルーチン
GitHub - googlesamples/android-sunflower: A gardening app illustrating Android development best practices with Android Jetpack.

テスト
　launch関数の代わりにrunBloking関数で実現する

コルーチンが使いやすくなるライブラリがある
　RxJavaとの置き換えを楽にするものとか

コルーチンによってAndroid独自の処理を簡単に扱うようにする
　たしかにRxJavaより簡単に扱えそう

今日のセッションで話さなかったこと
　例外の伝搬、コルーチン間の通信など

感想

kotlinをやっていないのにコルーチンの話を聞いて良いのかな?と思いつつ聞きましたが、大正解でした。
さすが羊の人。
メチャメチャわかりやすい話し方、テンポ、資料で、
ただただ素晴らしいセッションでした。

実際に使ってみるといろいろと壁はありそうですが、
俺、コルーチン、チョット分かるから試しに使ってみるかーと思えるようになれたのがスゴイです。

仕事で使う予定がないので、kotlinをやるつもりがなかったのですが、
個人的に勉強してもいいかなーと思えました。
ありがたい!

16:50 クロスプラットフォームモバイルアプリ開発ツール総ざらい2019 〜Titanium MobileからKotlin/Nativeまで〜

資料。

今日話さないこと
　ベストプラクティス
　ゲーム系
　静的ライブラリ

なぜクロスプラットフォーム開発ツールを使うのか?
　無限のお金があるわけじゃないから。
　ただし、クロスプラットフォームは必要悪(の側面も)

C向けでモバイル担当が少ない悲哀
　モバイルファーストじゃない
　要求に応じてプロとを作らなきゃいけない
　 iOS?Android?両方?
　一人で保守するときに両方見る?
　うーん・・・
　個人開発でも同様

クロスプラットフォームだけど特定のプラットフォームだけもある
　それは開発ツールだけでなく、効率よく開発できるツールとしての側面もあるから
　おまじないやお作法が共通APIに実装済みのため

流行の歴史(独断と偏見)
　Titanium　2011年〜
　　iOSでしか動かないAPIが多い
　　動作が重いなど

　AIR for Mobile
　　Flashっぽい
　　良くも悪くもFlashぽい
　　重い
　　中華フォント

　RubyMotion
　　あまりはやらず・・・

　Delphi/C++Builder
　　2013年〜
　　これもマニアに人気なだけ

　Xamarin
　　.NET界隈では使わざるをおえない

　ReactNative
　　Skypeもそうらしい

　Flutter
　　2017年
　　Google製
　　Dart

　Kotlin/Native with MPP
　　GoogleやAppleに買収されたりしたら中立性が崩れそうで怖い…。

クロスプラットフォームの基本
1. なるべくプラットフォームの標準API、クラスを使う
2. ツール用の共通APIを使う
3. 自作する

1番のほうが良い。

クロスプラットフォームツールによって依存する部分の言語が違う
　Reactはkotlinやswiftだが、
　XamarinやKotlinNativeはそのツールの言語のみでOK
　良し悪しがあるので一概に楽とも言えない

Webアプリ(ガワネイティブ)
　CrodovaやMonacaはガワネイティブ用。
　Nintendo Switch Onlineはガワネイティブらしい

感想

聞きかじった知識でクロスプラットフォームは遅いと思ってましたが、
よくよく思い返してみればそれはTitaniumの話だったので、
ちゃんと新しい情報を確認すればそうでもないのかなと思い直しました。

Flutterのエンジニア募集というスピーカーの方も何人か見たので、
アプリの内容が合致するならクロスプラットフォームも良さそうですね。
(あまりネイティブな部分を使わないとか)

現状の業務ではiOS、Androidはどちらもネイティブですが、
Kotlin/Nativeに置き換えても良さそうだなぁと思ったり。

多分、そんな日は来ないでしょうが…w

パーティ(懇親会)

1日目の全セッション終了後、
パーティという名前の懇親会がありました。

正直Android界隈に知り合いはいないし、ちょっと悩みましたが、
こんな機会はめったにないので参加しました。

適当に一人っぽい人を見つけて、DroidKaigiは何回目ですか?
どんな開発されてるんですか?と聞いて行く感じ。
RSGTでの経験が生きていて良い感じw

だいたい10人弱くらいとは話しましたが、
お寿司の行列で話かけた人がYahooの方で知り合いも多く、
いろんな人と話せたのが非常にありがたかったです。

印象に残っているのはAndroidエンジニアが少ないという話と、
しがないラジオのリスナーさんに会ったこと。

DroidKaigi自体は1000人ほど人がいたわけですが、
それでも人が足りないという事を仰っている方が多い印象でした。

まあAndoirdに限った話では無いのかもしれないですが…。

しがないラジオのリスナーさんは、最近はRebuildくらいしか聞いてないと言っていたので、
しがないラジオの最新回のゲスト、僕ですよ(ドヤァ)とさせていただきました。
この場を借りてgamiさんとzukkeyさんにお礼をw

名刺渡した人にはPodcastやってますというと「へー!」というリアクションを貰えるので、
もっとアピールしても良かったかなぁと思いつつ。
技術書典に本を出しますも一人だけ言ったけど、こっちのほうが受けは良かったかも。

なんか…あんまりAndroidの話をした記憶が無いなw

おわりに

というわけで、DroidKaigi1日目の感想でした。
メッチャ楽しかったので既に来年も行きたい!

Android自体はITエンジニアとして何か新しいことをやりたいという思いだけ、
たまたま学べる機会があったから始めたんだけど、
Androidエンジニアの方はいい人ばかりでありがたい…。

ガジェットとしても開発としてものんびりAndroid開発はやっていきたいなぁと思いました。
正直、10年以上やってきたWebと同じか、Webよりもちょっと上かも?
Kotlinとかまだまだ勉強したことたくさんあるし、しばらくお世話になります。

まぁスマホはiPhoneなんですがw

最後に宣伝です!
平成の情シスおかしんさんのご厚意により、
技術書典6は委託という形で技術書の頒布ができることになりました。ありがたい!
私は「はじめる技術つづける技術」というタイトルで、
何かを始める時、続ける時の工夫や事例などを書いたノウハウ本を出します。

おかしんさんはゼロトラストアーキテクチャについての本ということなので、
こちらもぜひよろしくお願いします!

ブース番号などの詳細は決まり次第、告知していきます。
またハッシュタグ#はじめる技つづける技術でもいろいろ呟いていきますので、よろしくお願いします!

青空な日々

ITエンジニア関連で興味あることをアウトプットして共有したいブログ

#DroidKaigi 2019 1日目の感想。