heihei blog

Write once, recall anytime. 自分のために書く 📝

Notes - Android Jetpack how to smartly use Fragments in your UI (Google IO 18)

f:id:shaunkawano:20180512195201p:plain

はじめに

Notes記事では、英語のセッション動画やポッドキャストの内容を(雑に)英語でメモに書き残すことを行っています。本記事は、あくまで動画を見ながら、参考程度に読んでいただくことを想定しています。Notes記事には雑メモ程度のものだったり、書き起こしのようなものもあります。これから実際の動画を見る際には、本記事の内容が少しでもお役に立てば幸いです。(内容において不備、誤字脱字等ありましたらご連絡いただければと思います。)

本記事は、Android Jetpack how to smartly use Fragments in your UI (Google IO 18)に対するNotes記事です。

——

The Story so far

Everybody started writing Activity

  • Entry point to your application system
  • main() with lifecycle
  • Creates views
  • Binds view

Enter tables

  • Phone UI + Phone UI = Tablet UI
  • How do I stick two phone UIs together?
  • Enter tables

Fragments of an Activity

  • Design goal of fragments allow splitting up huge Activity classes
  • Requirement: anything an Activity can do, a Fragment can do
    • Lifecycle events
    • Managing view hierarchies
    • Saved instance state
    • Non-configuration instance object passing
    • Back stacks

Can we fix some other APIs?

  • onRetainNonConfigurationInstance
  • Activity#showDialog
  • TabHost/LocalActivityManager

Factoring Activities

  • Recipe for breaking up monoliths:
    • Move loosely related code to separate fragments
    • Repeat

Factoring Activities Fragments

  • Recipe for breaking up monoliths:
  • Move loosely related code to separate fragments
  • Repeat

Things Fragments do

  • Lifecycle hooks
  • Back stack management
  • Retain objects across configuration changes
  • (Instance:)Stateful presence in the FragmentManager
  • Manage a View subtree
  • inflatable, reusable components

Architecture Components

Focuses on doing one thing well

LifecycleObservers

  • Strict ordering callback: Last in, first out
  • Created by you, not recreated via reflection
  • NO stateful restoration by the system
  • Isolated, minimal component, easy to test, easy to inject

ViewModel

  • Instances are created by factory you provide
  • LiveData allows easy (lifecycle aware!) reconnection
  • Replace retained instance Fragments
  • Your Activities or Fragments do not have to know where the data comes from; ViewModel is responsible for getting and passing data

Navigation

Fragments are good to be owner of Lifecycle, ViewModel, and views, so Google wants to make it easy for developers to use.

  • Focusing on making "How you move one screen to another screen" better
  • Works well with Fragments
  • Replaces back stack transactions

Why Fragments in 2018?

Android layering

Package Managing

android.widget vs. android.app
  • android.widget - Mechanism

    • Shows state to the user
    • Reports user interaction events
  • android.app - Policy

    • Defines state to bind to widgets
    • Responds to user interaction and issues changes to model

Inflatable Components

ViewGroups that got too smart

  • Composed high-level controls
  • Self-sufficient
  • Lifecycle aware
  • Inflated attributes can become Fragment arguments

=> Cross-cutting UI policy

  • Self sufficient components
  • Ads
  • Independent info cards
  • Parent doesn't need to be involved in data routing from repository

App Screens

Tastes great with Navigation!

Use Activity just as an entry point, and Fragments for showing actual contents

  • Single-Activity apps
  • Common app chrome, decoupled destinations
  • Transitions and animations managed by Navigation, not by hand
  • Can inflate sub-components to help

DialogFragment

Managing another interaction

  • Interaction with another..
    • Floating UI
    • System interaction
  • Leverage instance state restoration
  • Dialogs, bottom sheets
  • Transient UIs you don't want to lose

Options Menus

We still don't have a great answer for this

Merging menus for your Toolbar

  • Fragments support options menus
  • Common use case: setSupportActionBar
    • Useful for fixed common chrome
    • FragmentPagerAdapter
  • Alternative:
    • Directory manage menus as Toolbar View data

Testing Fragments

Diving Fragment Lifecycles

  • FragmentController drives lifecycle
  • Test your larger components in greater isolation
  • Possible, if not the best interface

Loaders

Now decoupled from Fragments!

  • Rebuild on top of LiveData and ViewModel
  • use Loaders from any LifecycleOwner+ViewModelStoreOwner

Where are we going?

  • Separate desired behavior from incidental behavior
  • Reimplementing existing APIs on top of new primitives
    • e.g. LoaderManager on LiveData
  • Make primitive signals and Activity callbacks available to any interested component
  • If you don't like Fragments, write your own!
    • No more magic
    • Use the same composable hooks
  • Fragments + your components working together
  • android.app.Fragment is now official deprecated

所感・まとめ・個人的に印象に残ったことなど

  • 1つのエントリーポイントに対して1つのActivityを、画面にコンテンツを表示するにはFragmentを利用していこう
    • その際のFragmentのBack Stack管理や画面遷移時のアニメーションなどは全てNavigationに任せようという流れ
  • 使いまわし可能なコンポーネントとして、コンテンツを表示する役割をFragmentに完全に任せることで、再利用可能かつ"つらみ"のないアプリ開発ができるようになる => そのためのAAC、そして今回特にFragmentのために用意されたNavigation
  • Navigationを使うことでFragmentのつらみ、Animation周りボイラープレートコードを開発者が気にする必要がなくなる
  • 未だに"つらみ"のある既存のプラットフォームAPIやサポートライブラリのAPIはあるが、今後はAACなどの新しいAPIの上に乗せる形で作り直すような例も出てくる(LoaderManagerがLiveDataに依存する形で作りなおされたように)
  • 今後はAACを使ったアプリ開発は、より安全かつより早くアプリ開発をする上で必須になりそう

以上です!

Notes - Modern Android development: Android Jetpack, Kotlin, and more (Google I/O 2018)

f:id:shaunkawano:20180510191149p:plain

はじめに

Notes記事では、英語のセッション動画やポッドキャストの内容を(雑に)英語でメモに書き残すことを行っています。本記事は、あくまで動画を見ながら、参考程度に読んでいただくことを想定しています。Notes記事には雑メモ程度のものだったり、書き起こしのようなものもあります。これから実際の動画を見る際には、本記事の内容が少しでもお役に立てば幸いです。(内容において不備、誤字脱字等ありましたらご連絡いただければと思います。)

本Notes記事で取り上げている動画は下記です:

Modern Android development: Android Jetpack, Kotlin, and more (Google I/O 2018)

www.youtube.com

——

Android History

  • 2008 - Android 1.0
  • 2013 - Android Studio
  • 2014 - ART, RecyclerView
  • 2017 - ConstraintLayout, Kotlin, AAC, Studio Profilers
  • 2018 - ktx, Paging

Tools

  • Layout Inspector
  • Trace View -> Systrace
  • New Profiler Tab in Android Studio
  • Memory Tracking
  • Layout Design
    • ConstraintLayout

Runtime in Language

Dalvik

  • Optimized for Space
  • JIT optimizations not as powerful
  • Slow Allocation/collection
  • Heap fragmentation

So

  • Avoid allocations(e.g. Don't use Enums!)
  • Primitive types are cool

ART

  • Optimized for performance
  • JIT + AOT
  • Faster allocation/collection
  • Heap defragmentation
  • Large object heap

So

  • Allocate as necessary(Yes, even enums)
  • Use appropriate types

But

  • Phones are still constrained
  • Buttery is important

Java

  • Started with Java 1.5
  • Extremely popular
  • Available great tools
  • Slow adoption of newer versions

Kotlin

  • Official support in 2017
  • Close collaboration with Jetbrains
  • Many great features that make code more enjoyable to write & read
  • Android project can contain both Kotlin & Java
  • Lint checks in Android Studio
  • Java -> Kotlin conversion
  • Android Kotlin Extension
  • Kotlin Style Guide
  • Kotlin Interop Guide

Benefits of Kotlin

  • Extensions
  • Inline functions
  • Operators
  • De-structuring assignments
  • Data classes
  • Lambdas

Now, new Java APIs in the platform starting with Android P will follow the code convention of Kotlin that when there is a SAM interface as parameter, it goes at the end of the list of parameters.

APIs

  • AbsoluteLayout => Deprecated
  • LinearLayout => Okay for simple cases
  • FrameLayout => Okay
  • GridLayout => Don't use
  • RelativeLayout => Don't use
  • ConstraintLayout => Use it. 2.0 Soon!
  • AdapterViews

Fragments

  • Complicated
  • Core platform bugs+fixes => Core Platform API @deprecated
  • Use Support Library Fragments
    • Improvements ongoing, plans for more
    • New Navigation component simplifies fragment transactions

Activities

  • Android apps consist of many activities
  • Navigating launches an activity
  • Use single activities when possible
    • One per entry point
  • Richer, more continuous use experience
  • Fragments are not necessary, but can help
    • Navigation component, too

Architecture

  • No recommendation for architecture before
    • Handling Android Lifecycle

Lifecycle

  • AAC: Lifecyle
    • Fragment implements LifecycleOwner
    • AppCompatActivity implements LifecycleOwner
    • Activity and Lifecycle-Dependent-Thing now gets seprated

Views and Data

  • Activity had too much stuff
    • Views
    • Data for Views
    • Lifecycle tracking
    • Data change tracking

Live Data and ViewModel

  • Activity now only contains Views and reference for ViewModel
  • Activity observes LiveData

Data

  • Do it your own! => Room

Room

  • Local data persistence via SQLite
  • Compile-time validation
  • LiveData integration
Idea from Repository Pattern
Activity/Fragment
↓
ViewModel(contains LiveData)
↓
Repository
-> Model(Room) -> SQLite
-> Remote Data(Retrofit) -> WebService

Data Paging

  • Paging Library 1.0
    • Works with RecyclerView
    • Fine-grained item changes, bindings
    • Uses background threads
    • Flexible data fetching options
    • Integration with Room
    • Boring name

Graphics

  • OpenGL ES 1.0 => OpenGL ES 3.1/3.2, Vulkan
  • Software rendering => Hardware accelerated rendering
  • Nine patches => Vector Drawables
  • TextureView vs SurfaceView => Use SurfaceView, not TextureView
  • Managing bitmaps by hand => Recommended Libraries: Glide, Picasso, Lottie

Final Thoughts

  • Profile your code => Profile your code
  • Avoid work when possible
  • Minimize memory consumption
  • Devices are still resource-constrained
  • Battery life is critical
  • Bandwidth is precious
  • User experience matters

所感、個人的に特に印象に残ったことなど

  • 可能であれば1 Activityに極力しよう、というのを公式として今回方針を明言しているのは大きいなと感じました
  • Java APIの作りもKotlinを意識した形にする、というのは最高そうですね!
  • Navigation Component、AAC LifecycleによってFragmentも扱いやすくなった、というようなわりとFragmentが肯定される内容だったのかなと
  • サードーパーティー製のライブラリも良いものは使っていこう(Retrofit, Glide, Picassoなどが本動画には登場しています)という姿勢も、全て結果的には良いUXを提供しようというところにつながっていて、説得力というか納得感もあり実際それによって開発者も悩み少なく良いアプリを作れる、というWin-Winな形があるなぁと感じました

以上です!

2018年4月を振り返る

2018年も約35%が終わったようです。( ゚∀゚)・∵. グハッ!!(洒落にならない) ※5/3(木)時点

先月に引き続き、振り返ります。

4月やったこと

Google I/O 2018 Pre-Partyに参加した

昨年度参加した経験から絞り出したTipsを紹介しました。内容は下記です

  • Office Hourを有効活用してGooglerに質問したりニーズを伝えたりしよう
  • Sandboxでの展示などを見よう
  • 「お土産」があるかもしれないので荷物の空きスペースには余裕を持とう
  • パーカーなど会場でのお土産は早めに買おう

Tips for Google I/O 2018 // Speaker Deck

去年Twitter上でOffice HourにGooglerに質問する内容をください、という旨のツイートをしたら会社の後輩や同期からメンションいただけて少しだけでも役に立てたかなと感じたので今年も同じように質問を集めています。今のところ試しにGoogle SpreadSheetを使っています。どなたでもお気軽に記載していただいて構いません。質問はあるけどここに書くのは気が引ける、こんな質問していいのかな?と悩んでいる方はDMでもくださればと思います。

docs.google.com

初技術書典

技術書典にて、Coupling Union Android愛好会というサークル名で本を出しました。Coupling Unionについては下記を御覧ください。

CyberAgent COUPLING UNION - CAグループが運営するマッチングサービスの情報メディア

Google Tasks APIやAccount Hold, Okioについて3人でそれぞれ執筆しました。

初めての技術書典で反省ばかりでしたが、控えめの部数だったとはいえ完売できて嬉しかったのと、もっと早く、かつきれいで分かりやすい文章を書けるようになりたい、と改めて思いました。貴重な経験でした!仕事の時期などはもちろん見極める必要はありそうですが、ぜひまた参加したいです。完売後の日本酒は本当に最高だった。(飲みすぎました。)

その他

  • 新しいプロジェクト

今、新しいプロジェクトで数年運用されているAndroidアプリケーションの開発を担当しています。色々もっと良くしていきたいことがあるので、頑張るぞ!

  • Ready Player Oneを観た

4.6 / 5!面白かったです。2Dで観たので、3Dでもう一度観たい。

www.youtube.com

以上になります。4月もお疲れ様でした!

Android関連のユティリティークラスやヘルパークラスの命名などについてざっくり調べてみた

TL;DR

  • ユティリティーとヘルパーの違いは曖昧
  • ユティリティークラスはプライベートコンストラクタを持ちstaticメソッドを公開しているパターンが多そう
  • ユティリティーパッケージ、ユティリティークラスやヘルパークラスの命名には単数形(~Util / Helper)を用いるパターンと複数形(~Utils / ~Helpers)を用いるパターンがある
  • ヘルパークラスはutilパッケージ内部に定義されているパターンが多そう
  • とはいえ、ユティリティークラスやヘルパークラス、またはそのパッケージの命名に関してはチームの中で統一された考え方がありみんな納得感あればそれで良さそう
  • うちのチームだとこうしているよ、というような知見の共有などいただけると幸いですm(__)m

ユティリティークラスとヘルパークラスの違いって曖昧だな、と、最近モヤモヤと感じています。

よくよく考えてみると、「ユティリティークラスとはこういうクラス」、「ヘルパークラスとはこういうクラス」というふうに深く意識したことがあまりなかったです。それはそれでどうなのよ、という意見もあるかもしれません。なぜ意識しようと思ったかというと、最近担当しているプロジェクトのユティリティークラスのコードを読んでいた時に「この関数はユティリティークラスにあるべき関数なのかな?」とふと疑問に思っている自分がいたりしたからです。なのでまずは自分なりの考えをまとめてよう、と思った次第です。

先に書いておくと、言語、プラットフォーム、もしかしたら時代によってもユティリティークラスとヘルパークラスの違いや考え方が異なるかもしれないです。今回はAndroidアプリケーション開発にフォーカスしています。

  • 別に困らないからそこまで違いを意識する必要ないのでは?
  • ユティリティークラス、ヘルパークラスは悪だ!
  • 拡張関数でええやん
  • 不毛だな(゚∀゚)

という意見もあるかもしれませんが、ここではあまり意識していません。コメントでもTwitterにてメンションやDMでも良いので、勘違いやご意見、うちのチームだとこうしているよ、というような知見の共有などもしありましたらいただけると本当に嬉しいです!

そもそも

以前、一人で開発を担当していたプロジェクトでは、ユティリティークラスはアプリケーション独自の仕様への依存がなく、どのアプリケーションにも転用できるようなstaticなメソッド群を定義したクラス、ヘルパークラスはアプリケーション独自の仕様だったり特定のライブラリに依存したstaticなメソッド群を定義したクラスと定義していたつもりでした。改めて見返してみると、常にこの定義に沿っているわけではありませんでした。。

改めて、ユティリティークラス、ヘルパークラスとはなんだろう、ということで検索してみました。

まずはユティリティークラスから見ていきます。たくさんの記事がヒットしましたが、Quoraの記事の回答を引用します。

What is a utility class? - Quora

A utility class is one which:

  • Has no state (fields) of its own, so all the methods can be class methods (static) rather than object methods (requiring an instantiation of an object)
  • Provides methods for multiple other classes (shared code)

上記Quoraの回答によると、

ユティリティークラスは、下記に該当するクラスだそうです:

  • 独自のstateを管理せず全てのメソッドがクラスメソッド(static)にできるクラス
  • 他複数クラスへメソッドを提供するクラス(shared code)

ヘルパークラスのほうも検索してみます。

stackoverflow.com

上記stackoverflowの質問では、helper "objects"という単語が使われています。もしかしたらヘルパークラスはインスタンス化して利用するクラスという認識が、質問を記載した方にはあるのかもしれないです。

stackoverflowの回答の1つを引用します。

These are objects that "sit to the side" of the main body of code, and do some of the work for the object. They "help" the object to do it's job.

ヘルパーオブジェクトは中心となるコードの隣で特定のオブジェクトのために仕事を肩代わりするオブジェクト。特定のオブジェクトの仕事の"手助けをする"オブジェクトである

というようなことが書いてありそうです。ヘルパークラスがなぜ"ヘルパー"なのかはなんとなく理由がつきそうです。この記事ではヘルパークラスという呼び方をしていますが、もしかしたらヘルパーオブジェクトという呼び方がより一般的なのかもしれないです。

Androidフレームワークのコードを参考にしてみる

ここでAndroidフレームワークのユティリティークラス、ヘルパークラスをそれぞれ参考にしてみます。

Util / Utils

Search results for "util"   |   Android Developers

ユティリティークラスに関してAndroid Developerサイト上で検索してみると、java.utilパッケージ内のクラスがたくさんヒットします。代わりに、GitHub上のAOSP mirrorのほうを見てみます。utilパッケージを覗いてみます。

github.com

クラス群の命名に注目してみると、下記に気づきました。

  • Utils接尾語がついているクラスがちらほら
  • Helpersクラスも一つだけ(ContainerHelpers.java)
  • JsonWriter、Logなど、UtilsやHelpers接尾語がついていないクラスがほとんど
  • プライベートコンストラクタが定義されていてstaticクラスとして利用するものが多いですが、インスタンス化して利用するクラスも含まれている

次はSupportライブラリのcore-utilsを見てみます。

github.com

NavUtilsColorUtilsMathUtilsのようにUtils接尾語が付与されているクラス名もあれば、そうではないクラス名もあります。また、AOSP mirror同様、Helperクラス(PrintHelper)も内包されています。

Square社のOSSのコードを参考にしてみる

次はAndroid界隈では有名なSquare社のOSSのコードを参考にしてみます。(ここでは取り上げているライブラリについての説明などは記載していません。)

OkHttp 3

OkHttp 3にはinternalパッケージ配下にUtilという名前のクラスが存在します。

github.com

プライベートコンストラクタが定義されています。internalパッケージ配下に存在しますが、定数やメソッドはpublicスコープなのでアプリケーション側からも呼び出しができそうです。

/** Junk drawer of utility methods. */
public final class Util {
...

というコメントがあります。個人的にはユティリティーメソッド群を寄せ集めしただけのクラスなのかなという解釈をしています。

Picasso 3

Picasso 3にもユティリティークラスが存在します。こちらはUtilsという名前です。

github.com

Picasso 3のUtilsクラスにもプライベートコンストラクタが定義されているため、staticメソッド呼び出しのみの利用が想定されています。Picasso 3のUtilsクラスは、クラス自体やメソッドが全てパッケージスコープとなっているようです。余談ですが、もともと依存があったかどうかは調べきれていませんが、Picasso 3のUtilsクラス内部ではOkioのクラスが利用されていることがわかります

Okio

Okioにもユティリティークラスが存在します。Okio 2に向けてKotlin化作業が進み、UtilクラスはKotlinで書き直されています。OkioはOkHttpと同様、Utilというクラス名が採用されています。

github.com

まとめ

もうまとめなの!?ヘルパークラスはどうした!?と思われるかもしれませんが、体力が尽きそうなのでこのあたりで身勝手にもまとめさせていただきます。

Androidフレームワークや著名なOSSライブラリを複数開発するSquare社のソースコードを参考にと思い読んでみた結果、個人的には下記のことが分かりました

  • ユティリティーとヘルパーの違いは曖昧
  • ユティリティークラスやヘルパークラス、またはそのパッケージの命名に関してはチームごとに統一された考え方があれば良さそう
  • ユティリティークラスはプライベートコンストラクタを持ちstaticメソッドを公開しているパターンが多そう
  • ユティリティーパッケージ、ユティリティークラスやヘルパークラスの命名には単数形(~Util / Helper)を用いるパターンと複数形(~Utils / ~Helpers)を用いるパターンがある
  • ヘルパークラスはutilパッケージ内部に定義されているパターンが多そう

前プロジェクトではhelpersパッケージ内に~Helperクラスを定義していましたが、AOSPの場合、utilパッケージ内部にヘルパークラスを内包するパターンが多く見られたのが意外でした。きっとユティリティーという概念の中にヘルパーという概念が存在するのだろうな、というふんわりとした印象を覚えました。

とはいえ、調べてきた上で「けどやっぱりutilパッケージとhelperパッケージわけたほうがよくないか」という考えだったり「クラス名の単数形、複数形は統一したい」「パッケージ名に関しては複数形にしたい」というようないわゆるエゴのようなこだわりのようなものは消えていないので、これからもチームの他のメンバーさんたちと議論しながら納得感持って開発していきまっす。

改めて、うちのチームだとこうしているよ、というような知見の共有などもしありましたらいただけると嬉しいです。

以上です!

2018年3月を振り返る

2018年も約27%が終わったようです。( ゚∀゚)・∵. グハッ!!(洒落にならない) ※4/7(土)時点

先月に引き続き、振り返ります。

3月やったこと

Droidcon Bostonに登壇者として参加した

3月はこれが自分にとっては一番大きなイベントでした。海外で登壇することも初めてだし、Droidcon Bostonへの参加も初めてだったので不安もありましたが、カンファレンスの登壇者や参加者、ボランティアの方々がみんな優しく、カンファレンス自体に関しても、大規模というよりはどちらかというとアットホーム感が漂う感じでそれもまた良かったです。現地のエンジニアの話(技術・生活周りなど)の話もできたことも、改めて振り返ってみてとても良かったと思います。

肝心の発表に関しては振り返るともちろんあーもっとこうしておけばよかった、とか掘り出せばきりがないのですが、DroidKaigiのときよりも落ち着いて発表できたことと、しっかりと参加者の方々から質問をしていただけたことは振り返ってみても嬉しいです。とはいえ、もちろんもっとうまくプレゼンできるようになりたいのは変わりないので、こればっかりは引き続き色々な上手な方々のプレゼンを聞いたり見たり、アドバイス頂いたりして精進したい所存です。

Droidcon Boston参加に至るまでの経緯や細かい振り返り等に関しては下記記事に記載していますので興味ある方はどうぞ:

blog.shaunkawano.com

技術書典

ウッ…だいぶ遅れ気味ではありますが、、CU Android愛好会、初めての技術書典、頑張るぞー!楽しむぞー!(オー!)(ユルイ)

その他

  • ゆるキャン△した

「手ぶら温泉キャンプ」ということで、埼玉県神川町にあるロハスガルデンキャンプ場にいってきました。会社の同期3人と自分の男4人でゆる〜く。カレー麺もちゃんと食べました(๑•̀ㅂ•́)و✧

埼玉県神川町の手ぶら温泉キャンプ・ロハスガルテンキャンプ場

  • 映画「さよならの朝に約束の花をかざろう」を観た

壮大なストーリーで、時間もわりと長かった気がする。いろいろな意味でリアルだな、と感じた。良かった。(雑)

sayoasa.jp

まとめ

その他、業務では新しいチャレンジをさせてもらえることになったり、いろいろな変化があった3月でした。

エンジニアとして技術力をもっと伸ばさねばとは常々思っていますが、改めてインプットを増やしていかないと、と感じました。4月も精進します。

以上です!3月もおつかれさまでした!

Droidcon Boston 2018に登壇者として参加した

3/26(月)、3/27(火)の2日間、ボストンにてDroidcon Boston 2018というAndroidエンジニアのカンファレンスがあり、登壇者として参加してきました。

  • 3キーノートスピーチ
  • 24セッション
  • 6ライトニングトーク
  • 5ワークショップ

がありました。

自分が発表した内容は、まとめの内容や細かい変更を除いて、着地ほとんどDroidKaigiにて発表した内容と同じものでした。スライドはこちらです。

TL;DR

ざっくりと本記事の内容を箇条書きでまとめています。

  • 初めての海外カンファレンスでの登壇は難しかったし反省もあるけどそれ以上にみんな親切だしまた行きたいと思えた
  • 発表を聞いている際、誰もTwitterみたり書いたりしていない・発表後めちゃめちゃ質問する
  • 海外の方々は素敵な、喜びあふれる言葉をまんべんなく使って本気で褒めてくれる

他人に質問して答えてもらったこと・聞いた話

  • MVVM, MVPなどが主流
  • FlutterはまだHello Worldしたけどー程度の人が多かった
  • MVIに興味がある人が増えている印象(個人の感想)

以降では、CFPを出すまでのきっかけ、だしたあと出発、そして登壇までの流れを時系列にまとめています。後はカンファレンスを通して感じたことなどをつらつらと書いています。

🔦きっかけ

AndroidStudyGroup/conferences

AndroidStudyGroup/conferencesのレポジトリには、世界中のAndroidに関するカンファレンス情報が一覧化されて掲載されています。DroidKaigiのCFPを出して少し経った頃、この一覧をふと眺めていた時にDroidcon Bostonを見つけました。

もともと「海外カンファレンスで登壇してみたい」という思いはありつつも、「きっと倍率は高いし通らないだろうなぁ」という気持ちしかありませんでした。

が、DroidKaigiでは、Fluxについて英語で発表する予定でしたので、ダメ元で同じCFPで応募してみよう、という流れでCFPを出しました。

⏰待っていても何も来ない連絡

案の定、カンファレンスの運営の方から特に何も連絡がこなかったときは「やはりダメだったか」と思いました。しかし、いくら待っても運営からは何の連絡もありません。自分のCFPが採択されなかった場合も、そのうち連絡が来るだろうと思っていたので、待っていても何も連絡がこないので「おや?」という気持ちになり始めました。

🐦来ないなら自分から突っついてみる

「おや?」「もしかして、何らかの理由で自分のCFPが閲覧されていないのでは?」という気持ちを払拭するために、カンファレンス側に連絡をしてみることにしました。カンファレンスのウェブサイトにお問い合わせフォームがあったのでそこから問い合わせをしてみました。

2営業日ほど経っても連絡が来なかったので、今度はOrganizerの方にTwitterで個別で連絡してみることにしました。カンファレンスのウェブサイトにはOrganizerやVolunteerの方々の情報が掲載されていたので、ダメ元で連絡。

f:id:shaunkawano:20180402193028p:plain

個別に連絡した結果、以下の内容のような返事をもらうことができました:

「もう発表しようと思っている内容の少し詳細を教えてくれる? 発表内容の詳細を理解した上で採択するかどうかを改めて考えたい。」

検討してくれるらしい。

そして、登壇したら話そうと思っている発表内容についてや自分なりの思いをぶつけて、最終的には採択されることになりました。

🎒準備

採択された後は、渡米の準備を少しずつ行っていきました。下記にざっと記載します。

  • 飛行機の予約(Expediaでゆるく調べ、直行便を選びました)
  • ESTAの取得(前回取得済みのESTAがまだ有効だったため、今回は不要でした)
  • Airbnbの予約(初めてのAirbnb。結構楽しみでした)
  • そのほか現地の情報について調べる

また、この準備期間中にDroidcon BostonのOrganizerの方からDroidcon BostonのSlackチームへの招待があり、Slack上で他のSpeakerの方々とお互い自己紹介しあったりしました。

f:id:shaunkawano:20180402115046p:plain

運営の方々もこのSlackを使って連絡し合ったり準備をすすめていて、カンファレンス開催のギリギリまでウェブサイトの情報更新だったり、「Wifiが今のままだとキャパオーバーしそうだ、どうしよう!?」「録画って今の準備で問題ないよね? もう少しボランティアの人増やす!?」みたいな慌ただしい報告が飛び交っていて、カンファレンス運営というのは本当に大変なことなのだなと感じました。(DroidKaigiの皆様改めてありがとうございました!今も動画の確認やアップロード作業お疲れ様です。m(__)m)

一方で、「Tシャツ届いたよー!! YEAH! AWESOME!!」という報告だったりカンファレンス前日は「Speaker Partyやるよー!!」という盛り上がる内容のメッセージもたくさんありそのたびにスピーカーや運営の方々がリアクションを飛ばし合っていて、リアルタイムでカンファレンスが構築されていく様を目の当たりにできて、気分が高揚してきていました。

✈️出発

いよいよ日本から出発。と言っても、1日早めに出発をし、まずは観光目的で日本→ニューヨークの飛行機でニューヨークへ行きました。友人宅にお邪魔をさせてもらい、観光をしました。

その後、Amtrackという新幹線のようなものに乗って3-4時間ほどかけて、ニューヨーク→ボストンへと移動しました。

ボストンのホテルに着いたその日に、Speaker Partyに参加しました。

Speaker Party

f:id:shaunkawano:20180402115126j:plain

f:id:shaunkawano:20180402115133j:plain

Speaker Partyには登壇者、Organizer、Co-Organizerの方々、そして運営ボランティアの方々が参加しました。

日本人の登壇者は自分だけだったため、Speaker Partyではぼっちになるかもととっても不安でした。が、一人のボランティアの方がすぐに声をかけてくれて、その人がまた別の人を呼んできてくれて、と、すぐに数名の方々と喋ることができ、最後までいろいろな人とコミュニケーションすることができました。

運営ボランティアの方々はやはり現地の方が多いようで、Speaker Partyで喋った方のほとんどの方が現地ボストンに住んでいました。(住みたいなぁ、ボストン。)

me: Flutterって流行っている?

ボストンエンジニア: Hello World!くらいは書いたけど、それ以上はやれていないな〜

me: 日本だと転職するとエンジニアの給与が上がりやすい傾向にあるのだけど、海外でも同じ?それが理由で転職するということってよくある?

ボストンエンジニア: みんながみんな、というわけではないけど、一定数いるのはたしかだね。

というような会話もしてきました。以外とアメリカだからこう、というはっきりとした違いがあるのではないのかも、と感じました。

カンファレンス

会場

会場は、The Calderwood Pavilion at the Boston Center for the Artsという、普段は芸術舞台に使われている、趣のあるような場所でした。

f:id:shaunkawano:20180402115139j:plain

セッション

いずれセッション動画が公開されると思いますが、個人的には下記のセッションをききました:

  • Tips for Library development(Keynote)
  • Design + Develop + Test(Keynote)
  • Common Poor Coding Patterns and How to avoid Them - Pinterest
  • Why MVI? - Fueled
  • Optimization Strategies at Instagram - Instagram

個々のセッションを振り返ることはしませんが、個人的にはKeynoteはエモいものが多く(iOSと同じデザインにしてくれ!と言われたらどうする?という話など)、 あとはMVP+Event busの既存プロジェクトにてデータの不整合などが発生し状態管理がうまくいっていないことがわかった。ここからどのように改善したか、もしくはどのようにこれを防ぐように改善したか、という話、またはMVIに関する話もありました。

MVIについての発表はDroidKaigiでも発表がありましたが、Droidcon Bostonにおいてもオーディエンスの数が多く、認知度が高くなっていて気になる人も増えてきているアーキテクチャなのだな、という印象でした。

とはいえ、MVIの発表後数名に話を聞いたところによると、現状としてはMVVMやMVPが主流である印象でした。

気づき

ここでは海外カンファレンスで登壇してみて、海外カンファレンスそのものやアメリカの文化とも言える部分について、気付いたことをいくつか、つらつらと書きます。

能動的オーディエンス

まず、海外カンファレンスでは殆どの人はスマートフォンやMacを開いたり、見ていたりしません。殆どの人が登壇者の目を見て話を聞いている印象でした。これはもしかしたらカンファレンスの規模にもよるかもしれませんが、明らかにスピーカーの目を見て聞いている人が日本のカンファレンスとくらべて多かったことは確かだと思います。

そして、Q&Aの時間では、必ず一人は質問をします。だいたい2−3人は質問していました。これももしかしたら、規模が小さいからだったのかもしれませんが、それでも多くの方が、時には鋭い質問をしていて、しっかりと聞いているなと思ったことと、決して自分の疑問は質問するに値しない、とは思ったりしていないと感じました。そして実際に、多くの質問が参考になる、自分も質問したいなと思っていた内容でした。

オーディエンスの登壇者に対する姿勢や質問をみんながどんどんしていくあの感じというのは、日本ではなかなかないものだと感じました。

f:id:shaunkawano:20180402194225j:plain

素敵な言葉をまんべんなく使い尽くす

先程オーディエンスの方は時には鋭い質問をする、と書きましたが、とはいえQ&Aセッションが終わると、ものすごく褒めてくれます。

You are awesome!(君は最高!)

You are more than awesome!(君は最高以上!)

You changed my life!(君は僕の人生を変えてくれた!)

など、日本語では恥ずかしくて言えなそうなことでも、沢山の人が声をかけて本気で伝えてくれます。これは自分が日本人で、遠くからわざわざ来てくれたから、という気持ちもあったのかもしれませんが、他の登壇者の方々にももちろん同じようなかたちで伝えている方が多くいたため、僕だけではないはず。笑

こんな素敵な言葉を浴びせられたら、誰でも嬉しいです。ぼくもかなり嬉しかったです。お世辞でも嬉しい。

また最後には下記のようなカードをいただきました:

f:id:shaunkawano:20180402203355j:plain

まとめ

初めての海外カンファレンスでの登壇でしたが、想像以上に楽しかったしみんな優しくて最高でした。ここらへんは個人の印象ですが、Droidcon BostonはDroidcon NYCなどのより大きいカンファレンスとくらべて特にアットホーム感があり運営者との距離も近かったかもと思います。

英語での登壇はいつも反省だらけでもちろん今回ももっとうまくやれれば、、と反省し始めればキリがないですが、実際に質問したり話すことが上達への一番の近道いだと信じて改めて精進していきたいと思います。できればみんなで一緒にワイワイ精進できたら最高だなー何かいい方法ないかなーともんもんと考えていますが、こればっかりは場数を踏むのが一番良いのかな、とも思っていて何とも言えない感じです。

以上です!

2018年2月を振り返る

2018年も17%がすでに終わったようです。(恐ろしい)

先月に引き続き、やったことベースで振り返ります。

2月やったこと

DroidKaigiに初めて登壇者として参加した

僭越ながら、DroidKaigiにてFluxについて発表させていただきました。

登壇やDroidKaigi自体の振り返りについては、下記ブログ記事に記載しています。

blog.shaunkawano.com

登壇以外にも、上記記事には書いていませんが、1日目が終了したあとの懇親会にて@hakさんとお話できたのが個人的には良い思い出になりました。いつもhakさんの回をメインに聴いていることや、マッチングアプリ作ってます、お〜どんな感じのなんですか、というような会話をしました。またお話したいです。

他にもKaigiを通して色々な、普段はお話できない方々と新しい交流があったことが何より良かったなと感じています。

改めて、運営の皆様に感謝いたします。m(__)m


DroidKaigiでFluxについて発表したのでここでFluxについて余談ですが、先日、@magiepoohと宅飲みをしているとき(9割は「日村がゆく」を観てゲラゲラ笑っていました)にFluxの話になり、

ぷ「Flux人気になってきたよね」

hei「たしかに」

ぷ「Fluxにはいくつか(δ´ω`)カユイところあるよね」

hei「たしかに」

ぷ「今模索中なんだよね〜」

というような会話をしました。(「たしかに」しか言ってない自分)

(δ´ω`)カユイところの例としては、たとえば

  • 「Viewの状態」を管理したくなった場合にどこで管理するのか(Store?それ以外?)
  • Action/EventをDispatchしないけどActionCreator等に任せたい処理をどこに書くのか

などがあるかも、という話を2人でさらっとですがしました。

今後はそれを解決する形でまた新しい設計が出てくるのかなーと思いました。(「コレで行けるっしょ!」という方はぜひお話したいです〜)

余談以上!次。

DroidKaigi Reject ConferenceにてOkio & OkHttpについて発表した

DroidKaigiから一週間後、DroidKaigi Reject Conferenceがありました。そこで@stsn_jpさんと2人で登壇しました。

こちらについての振り返りブログ記事は下記です。

blog.shaunkawano.com

本記事にも記載していますが、資料準備が間に合わず、会場設営後、最後の最後まで資料作りをおこなっていました。

登壇はノリで決まり、もともと「OkHttpとかOkioとかの有名ライブラリの内部実装しっかり読みたいですよね!?」というところからでしたが、いつの間にか応募して登壇することが決まり、いつのまにかDroidKaigiが終わって「あれ、内部実装まだぜんぜん読めてないぞ!?」となり冷や汗しか出ていませんでした。ですが、登壇後は会場にいらした方々から「面白い」とツイートいただけて、どうにか楽しんで頂けてよかったかなという印象でした。

DroidKaigi Reject Conferenceに関しては最後の懇親会でも多くの方が残ってワイワイお話して楽しかったので来年もぜひ開催したいです。

技術書典のための執筆を始めた

今年の4月に初めて技術書典にて本を出します。職場の同じフロアで働くAndroidエンジニア数名で一冊、有志で出します。

書典では、Okioの内部実装について、15ページ〜20ページほど記載する予定です。 DroidKaigi Reject Conferenceで発表した内容は本当に一部分なので、枚数の許す限りガッツリ書こうと思います。執筆を始めた、といってもはじめたばかりですので、これから頑張ります。

ほかメンバー含めみんな初書典なので、お手柔らかにお願いできればと思います。m(__)m

その他

  • お金2.0を読んだ
  • CloudStudyJam行って初めてGCP, Kubernetesあたりを触った

最後に

今月末、Droidcon BostonにてFluxについて発表してきます。内容の大半はDroidKaigiで発表したものと重なるかもしれませんが、DroiconではDroidKaigiと比べ10分ほど発表時間が長そうなので、資料も更新しDroidKaigiで発表しきれなかった部分についても頑張って発表してこようと思います。リベンジ!

終わったら、経緯や振り返り系のブログを書こうと思います。不安もありますが、初Airbnbも楽しみですのでマイペースにやっていけたらと思います。 今月の振り返りは以上です!

2月もお疲れ様でした〜!