heihei blog

Blog icon by Unsplash https://unsplash.com/@virussinside

DroidKaigi 2018にて、Flux for Androidについて発表した

はじめに

DroidKaigi運営の方へ、本当にお疲れ様でした!!

たくさんの知見を共有する・してもらうだけではなく、初めて出会う方はもちろん、GitHubTwitterでは知っていたけどリアルで話したことはなかった他のエンジニアの方々や海外出身の方々とも交流することができて、本当に楽しかったです。

f:id:shaunkawano:20180210115329j:plain
こちらは@pside氏作の周辺の音を聞き取り画面に表示するビジュアライザ

発表に向けて

DroidKaigiでは、Fluxについての発表をしました。

もともとは、Fluxの概要+実務で感じているFluxのいいところやイケてないところをざっくり言語化して発表しようと考えていました。

しかし、たとえこちらが言語化できたとしても、ある程度の知識や共感してもらえる「前提」がなければ、メリットをよりうまく説明したりスッと実感してもらうことはできないのではないか、と準備期間後半あたりに気が付きました。さらに、下記は自分がプロポーザルに記載した内容なのですが、

In this talk, I'll talk about flux architecture as one of the solid solutions for managing states within Android application; by achieving unidirectional data flow, we aim to think less, focus more on feature development, and scale faster.

(Androidアプリ開発における状態管理問題を解決する設計の1つとしてFluxを紹介します。データの流れを単一方向にすることで、状態管理であったりロジック管理について無駄に考える・悩むことを減らし、代わりに素晴らしい機能について考えたり実装したりする時間をもっと作り、アプリを大きく(スケール)させましょう!)

このようなプロポーザルの内容を準備の途中からあまり意識できていませんでした。(事業部内の共有会にて途中までの資料を共有させていただいた際に気づかされました。。)

改めてどういう内容を発表しようか、作り初めていた資料を修正し、最後まで悩み、社内の後輩・同期・先輩エンジニアの方々にご相談させていただいたりしました。皆様改めてありがとうございました。特に@kaelaela氏については、発表練習を一緒に何度か行ってくれました。ありがとう!

最終的な発表内容

最終的には、プロポーザルの内容に沿った上で、自分が現時点で一番感じているAndroidアプリ開発にFluxのメリットや悩ましいところをそのまま発表したいと思いました。

ということで、アプリの中でのデータの流れを単一方向にすることと、Storeを唯一のデータを管理するコンポーネントと位置づけることが重要であるということを前提に、FluxをAndroidアプリ開発に採用することのメリット、悩ましいところは以下であると個人的に結論付け、共有したいと考えました:

メリット

  • Fluxの単一方向性という考え方やアーキテクチャの図式自体がシンプルであること
  • Fluxの各パーツの責務がはっきりと分かれているため、実装コードがある程度統一されること
  • 機能ベースでFluxのデータの流れを実装することで、一度実装したFluxのパーツや内部ロジックを、新しい機能や画面を追加する際に再利用できること
  • Kotlinのsealedクラスを用いたり、Actionのクラス名を分かりやすいものにすることで、Storeの内部ロジックを読むことでアプリの仕様が理解できること

これらのメリットを享受することで、Androidの開発におけるデータの管理方法や機能追加の際に考えたり悩んだりする時間を減らすことができます。さらに、コードを書く以外の部分において、たとえば新しいメンバーがチームにジョインした際にも、新しいメンバーが早い段階で実力を発揮でき、最終的にはスケールしやすいアプリになる、という発表をしようと思いました。

もちろんいいところばかりではなく、悩ましいところも紹介したいと考えました。

悩ましいところ

  • 本来のDispatcherの役割が、いわゆるEvent Busである(アプリ全体に対してデータを伝達する)
  • ActionCreatorStoreどちらに処理を記載したほうがいいのか、たまに悩む

これらを踏まえ、最終的にできたスライドは下記です

speakerdeck.com

登壇が決まってから登壇するまでざっくり

登壇が決まった:

2017年の末からすでに緊張しているのを感じる:

そして登壇直前の最後のツイートで緊張しすぎて誤字のfoe:

英語での発表だったため、海外出身の方がたくさんいるのでは、と予想していたのですが実際は5人程度とかで残りは日本人の方でした。笑

反省

1日目終了後の懇親会にて、@wasabeef氏に「日本を楽しんでもらいたいなら何か紹介しなよ、ラーメンとか」、と勧められたため、ラーメンのお店はどこが良いのか自分の中でも一番が決まっていなかったため、海外出身の方にとって珍しい日本のコンビニエンスストアの便利さと、数あるコンビニエンスストアの中で僕が一番大好きなセブンイレブンの「ななチキ」について、登壇前に紹介をしました。これができたのは大きな自信になりました。 ただ、@wasabeef氏にはラーメンのほうがよかったな〜と言われたので、そこは反省です。

発表は、案の定練習の時のようにうまくはいかず、カミカミだったり、最後、時間的にはほぼぴったりだったのですが、タイマーの音に驚いて「Enjoy Japan!」と叫んで終了しました( ゚∀゚)・∵. グハッ!! 恐怖でYoutube動画がUPされても自分のだけは絶対に見れない形になりました。ですが、お褒めのツイートを頂けたり、オフィスアワーで初めて声をかけてくださった方がいたり、会社の後輩氏のツイートからスライドの改善すべき点が見えたり、良かったことも失敗したことも含め、発表できてよかったと改めて痛感しました。

反省としては、設計周りの発表をする際には前提がないと、ただただ簡単なサンプルの一例を紹介するだけでは旨味が伝わらない、ということに最初の方で気づけなかったことです。50分枠のほうが適切だったかも、と感じました。

時間配分に関しては、早めに終わる分には問題ないので早めに終わるように時間配分するくらいが良いのかもと思いました。自分の場合は本番中、まだ時間あると思って詳細を話していたらすぎてしまったので、「時間ある」と思わずさらっと終わればよかったな、と反省しました。

ぜひまた発表したいです。

あとは、これはイベント全体を通してですが、他登壇者の方々ともっとお話できればよかったな、と思いました。ここが一番反省。来年はもっとたくさんの方と仲良くなるぞー!!!

ツイート

終わってからfoeに気付いた自分と、それにいいねをくださるDroidKaigi公式の優しさ:

皆様ありがとうございます!!

最後に、いくつか撮った写真を共有します。

f:id:shaunkawano:20180210122218j:plain:w360
DroidKaigi208いよいよ感

f:id:shaunkawano:20180210124218j:plain:w480
ウェルカムトーク会場

f:id:shaunkawano:20180210121001j:plain:w480
Androidで動画コンテンツを扱うTipsについて発表している@takusemba氏(ブレてる...)

f:id:shaunkawano:20180210121116j:plain:w360
登壇前、緊張がピークに達している@kaelaela氏

f:id:shaunkawano:20180210121714j:plain:w360
ProGuardについて発表している@stsn_jp氏

f:id:shaunkawano:20180210122255j:plain:w360
PrePartyにて出てきたDroidくん🍻

f:id:shaunkawano:20180210122248j:plain:w360
2日目同じ時間帯にInstant Appsについて発表した@_a_akira

f:id:shaunkawano:20180210122250j:plain:w360
会社同じだけど初めて喋って仲良くなったEoinさんと@takusemba

f:id:shaunkawano:20180210122223j:plainf:id:shaunkawano:20180210122227j:plain
懇親会会場はキラキラしてた


f:id:shaunkawano:20180210124521j:plain:w480
2日目終了後、@stsn_jp氏と2人でやよい軒で打ち上げ〜(DroidKaigi Rejectonも頑張るぞ!)

改めて、運営の皆様、本当にありがとうございました!!

以上です!