DroidKaigi 2018最高でした!!
スタッフの皆様や登壇された皆様お疲れ様でした!!
ここ最近参加したカンファレンスの中では最高に楽しかったので珍しく感想エントリを書いてみました。
会場・スポンサーブースの様子
自分ではほとんど写真を撮っていなかったので雰囲気はこちらからどうぞ。 https://twitter.com/droidkaigi/status/963254146013872128
個人的には最近参加した他のカンファレンスよりもスポンサーブースで自分が普段使っているサービスをお見かけして驚きました。Androidだからか。
コーヒーとお菓子片手に、いつもサービス使ってます!と感謝を伝えまくってきました。
あと印象的だったのはQRコード。ブースでは主催している勉強会のURLや技術同人誌の配布のためのQRコードなど、いたるところでQRコードが使われていました。 やっぱり便利ですよね。
セッション
発表を聞いて印象深かったセッションの感想をいくつか紹介します。
ちなみに自分のバックグラウンドとしてはここ1-2年はjsを追っかけていて、業務の内容が変わったのでiOSとAndroidを触り始めてそろそろ半年という感じです。
なのでjsから見たAndroidという感じで読んでもらえればと思います。
アーキテクチャ系
Flux for Android by Shohei Kawano
ここ2-3年ぐらいjs界隈を賑やかしていたFluxをAndroidに適用したという発表。とても素直にFluxをAndroidに適用している感じでした。
jsとの違いはDispatcherやStoreといったFluxの構造上各所に引き回されるオブジェクトをDIで渡しているところと、
ReactのVirtualDOMの代わりにStateの更新をデータバインディングに接続しているところぐらいでした。
Android における Model-View-Intent アーキテクチャ by Benoît Quenaudon
Model-View-Intentという単語は初めて聞きましたが、内容としてはFlux(より正確にはRedux)をRxJavaで実装してActionとStore(Reducer)間にビジネスロジックを挟むというアーキテクチャだと理解しました。
ボタンなどをクリックしたときにIntentというものを発行するところが、Actionを発行するFluxとそっくりですね。
RxJavaもガッツリ使ってるので、FluxとRxJavaの両方を知らないと難易度が高かったのではないかと思います。
Kotlin版CleanArchitectureのテンプレート作ったら爆速開発になった話+α by Keisuke kiuchi
こちらもFlux同様、ここ最近話題となっているClean ArchitectureをAndroidに適用する + クラス数が多くなる問題を解決しましたという発表。
これも先程のFluxと同じくAndroidに素直に適用したという感じで、jsとの差異はあまりないかなという感じでした。
Clean Architectureみたいな設計にするとどうしてもクラス数は増えてしまうのですが、だいたい前に作ったクラスをコピペして必要なところだけ書き換えるということを繰り返しがちです。
テンプレを作ってIDEから呼び出せるようにしておくのは地味に生産性に効いてくると思いました。
アーキテクチャの話まとめ
自分はjsで既にFluxやClean Architectureを使ったことがあったので、Androidにもその波が来ているのだなーというのが全体的な感想です。
個人的にはFlux(Redux)のアーキテクチャは非常に好みでして、良い点が2つあります。
1つ目は、例えばボタンを押したときにイベントリスナーから状態を直接更新するのではなくて一度Actionというものを発行する仕組み。これにより状態の更新フローがView層から疎結合になります。
2つ目は、更新フローがAction -> Store(ReduxだとReducer) -> Viewという必ずこの単方向のフローを通るように強制できる(これがFluxにおけるDispatcherの役割)ためデバッグがしやすいという点です。実際、jsの方ではFluxが流行った初期からActionが発行されるごとにログ出力されるプラグイン(ミドルウェアとも呼ばれてます)が存在していたと思います。
Clean ArchitectureのメリットもFlux同様にView層と状態の更新ロジックが疎結合になるところで、こちらはFluxよりもさらに各層を疎結合にしていてDDD的な思想なのでビジネスロジックをどこに入れるかがハッキリしています。
ビジネスロジックに関してFluxの場合は特に非同期処理をActionでやるかStoreでやるか、はたまたActionとStoreの間にミドルウェアという層をおいてそこでやるか(redux-sageとか)でずっと議論しているのでみんなの悩みどころだと思ってます。
FluxでもClean Architectureにおいても個人的に重要だと思っているメリットは、更新フローがView層から疎結合になるという点です。これはAndroidにおいては状態の更新ロジックとUIコンポーネントが完全に切り離されるということを意味します。
これにより、アプリのロジックのユニットテストをJVM上で行うためにUIパーツをモックしなくて済む点が大きいです。
もはやボタンというパーツをモックする必要はなくて、ボタンを押したという動作の代わりに本来発行されるActionを発行するだけで更新ロジックのテストを書くことが可能となります。
想定しうる更新フローと最終的な状態(リストに表示するためのオブジェクトなど)を先に決めてしまえばテストをしっかり書きながらロジックを実装することで、ボタンをぽちぽち押して様々なケースの動作確認をするという必要も減らせるはずです。なにせView層はただActionを発行するだけなので。
というわけで、FluxやClean Architectureはテストが書きやすくなるアーキテクチャなので来年はこれらに対してテストをどうやって書くかというセッションが増えるのではないかな(増えて欲しい)と思ってます。
ちなみにFluxにしてもClean Architectureにしてもクラス数が多くなるというデメリットがよく言われるのですが、それに対する自分の見解はこちらです。
クラスが多いところは辛いけど、Presentation, Domain, Dataに分かれて疎結合になっているので、テストが書きやすくてテストを書くことで正しく動いていることが担保しやすいアーキテクチャだと思ってる #droidkaigi_room3
— Kesin (@Kesin11) 2018年2月8日
ReactNative系
React Native Androidはなぜ動くのか
最近流行り始めているReactNativeのAndroid側から見たディープな話。ReactNativeは趣味で最近触り始めたので深い話が聞けてよかったです。
ReactNativeは今年ぐらいから新しいプロダクトを作るときに選択肢の候補に上がってくるのではないかなーと個人的には予想しています。
自分みたいなjsを書いてきたエンジニアもネイティブアプリの戦力としてカウントできるようになるものの、ReactNativeコンポーネントを自作したりだとかそもそもビルド環境を整えることは今までネイティブを触り続けてきた人達の方が圧倒的に強いと感じています。
ReactNativeで作るにしてもネイティブ未経験者オンリーなチームでは大変だろうなという気がしています。特にiOSの証明書とか・・・。
コードで見るFlutterアプリの実装 by konifar
Flutterって全く聞いたことなかったのですが、発表を聞いた限りではDartで書くGoogle公式のReactNativeに近いフレームワークという印象でした。
公式でUIパーツが一通りそろってるのはよさそうですね。ReactNativeはググるとサードパーティのコンポーネントの記事がたくさん出てくるので・・・
Dartって表舞台には出てきていないと思っているのですが、Googleの一部でずっと生き続けているっぽいのでもしかすると今後盛り返してくる可能性も?
ReactNativeとFlutterの話まとめ
ReactNativeってネイティブ開発者からすると「昔から存在するjsでネイティブが書けるって吹聴してる一派でしょ?」と思われている気がします。
個人的にはjsで書けるという点はSwiftやKotlinの登場によってそれほどメリットではなくなってきていると思いますが、1つ大きなメリットだと感じているのはコードを編集すると再コンパイル無しでUIを更新できるところです。実際にkonifarさんも発表中にDartのコードを書き換えると自動的にUIが変わっていく様子をデモしていました。
これってWeb界隈でlive reloadやhot reloadができるようになったことでUIのコードを編集するたびにブラウザの更新ボタンをぽちぽち押していた時代から開放されたのと同じだなと思いました。
このデザインをWeb開発のようにガンガン変えていけるというスピード感は普通のネイティブ開発では難しいはず。SwiftやKotlinによるネイティブ開発ではちょっとUIを変更するだけでもコンパイルが必要なので自分は非常にめんどくさいと感じてます。
ちなみにTitaniumとかは知らないので、もしかしてFlutterみたいなことは昔から可能だったのかもしれませんがもしそうだったらすみません。
DroidKaigi 2018のアプリについて
DroidKaigiでは毎年カンファレンスのタイムテーブルを閲覧したり、アンケートを送るためのアプリをOSSで開発していて毎年ナウい構成で作り直されているので名物となっているようです。
https://github.com/DroidKaigi/conference-app-2018
自分もKotlinの勉強のために小さいバグの修正でしたがPRを送ってContributorsに名を連ねさせていただきました。:pray:
多分これぐらいの規模でちゃんと作られてるプロダクションのソースコードを見ることができるのは珍しいと思うので、AndroidやKotlinに興味がある人は良い勉強材料になるのではないかなと思います。
というわけでDroidKaigi 2018の感想エントリでした!来年も絶対行きます!