DroidKaigi 2018 まとめ #droidkaigi - @numa08　猫耳帽子の女の子

「ブログを書くまでが勉強会だ」って古い言葉もあったなとちょっと思い出しつつ。qiitaに書こうかとも思ったけどポエムっぽくなりそうだったのでこっちで。

自分が聞いたセッションのまとめと会場の雰囲気のまとめを作っていこうと思います。

セッションのまとめ

kotlinアンチパターン

感想

kotlinは便利で機能が多いので色々と使ってみたくなるが、あんまりやるとよろしくないよねって感じ。詳しい解説は資料を参照すればいいと思うので、ちょっと思い出したことを1つ。

late init を使うか lazy を使うか

プロパティをlateinit varにすることでインスタンス初期化時にプロパティを初期化できなくても、Nullableにすることなくプロパティをクラスの中で利用できて便利。例えばfindViewByIdなんかの結果得られたViewのインスタンスをlate varにしておくのはよくあるパターンだと思う。

その一方でval by lazyも便利で、kotlinのDelegated property を利用することで実現している遅延評価の機能なんだけど変数をvalで宣言できるのが嬉しい。

どっちを使うのが正しいのか判断に困ることもときどきあって、資料中にもあるようにfindViewByIdをby lazyのクロージャの中で実行した結果、Viewの再利用に対応できない地雷も踏んだ。

lazy valをどこで使うかと言えば、例えばRealmやRetrofitのような初期化にコストがかかるとされているオブジェクトの初期化だと思う。ただ、リソースの解放やFragmentの場合、再利用されることも考えなきゃいけない。

onStopでRealm.closeしたあとでActivityやFragmentが再利用されてclose済みのRealmにアクセスしてしまうなんてこともあった。このあたりを防ぐならスコープを広げるか狭めるかになるのでやっぱりby lazyを使うところじゃないかもしれない。

Applicationのライフサイクルで管理されるReamなどの場合は初期化のタイミングをアプリが起動したタイミングから適切にずらることは意味があると思う。

Androidの場合、UIのコンポーネント内でby lazyを使って初期化を行うパターンが使える部分は少ないかもしれない。

Inside Android Architecture Components

Inside Architecture Components // Speaker Deck

感想

昨年の Google I/O で公開されたけど、今のところ業務で利用をしたことは無かった Android Architecture Component の中身の解説。ありがたいありがたい。

Android のライフサイクルはかなり複雑だという感覚はみんな持っていると思うけど使いこなせないと「お前、そんなのもできないの？」みたいな空気感がある気がする（気のせい

Architecture Component の LifeCycle コンポーネントの導入で多少はマシになるかな？と思った。リソースの管理をActivityのライフサイクルに対応して行う必要がある場合、Activityから完全に分離したところで実現できるようになるためコードの複雑化を抑えられるだろう。

ちなみに、自分は以前はonCreateやonStopを定義したinterfaceを作り、その実装にリソースの管理を行わせてActivityのプロパティにもたせ、Activityのライフサイクルコールバックで呼び出していたりした。

interface LifecycleResource {
  fun onCreate()
  fun onStop()
}

class NetworkResource: LifecycleResource {
  lateinit var restService: RestService

  fun onCreate() {
    restService = //初期化
  }

  fun onStop() {}
}

class Activity: Activity() {
  val resource = MutableList<LifecycleResource>()
  
  fun onCreate(saved: Bandle) {
    resources.add(NetworkResource())
    resources.forEach { it.onCreate() }
  }
  
  fun onStop() {
    resource.forEach { it.onStop() }
    resource.clear()
  }
}

こういうのを自前でやる必要がなくなったことに意味がある。

また、ViewModelというコンポーネントがどうなっているのかは調査の必要性を感じた。Activityと一対一になるコンポーネントだけどActivityのライフサイクルより長い期間生存ができるので、画面回転のタイミングでデータが失われないということ（だと思う

あとで出てくるけど、MVIパターンによるアプリの設計実装を行うときにも重要なコンポーネントとなっている。ただ、Activityのライフサイクルよりも長い時間生存している部分についてはまだ自分の理解が足りていななって思った。画面回転のときでもActivityはonDestroyがコールバックされるけれど、それはActivityの「破棄」としては認識されないってことなんだろうな。ActivityThreadとかActivityManagerServiceと連携して難しいことをやってるのか？そのうち調べる。

Android における Model-View-Intent アーキテクチャ

Android における Model-View-Intent アーキテクチャ // Speaker Deck

感想

Androidでも、こんなReduxみたいなことができるようになってたのか〜（小並感

割と長い間、雰囲気でReactiveXというかRxJavaを使ってきたけどこういう風に使うのか〜ってちゃんと理解できたように思う。

データの流れが一方通行なこと
副作用が入り込む場所が少ないこと

という点でこのやり方は良いなと思った。で、ちょっとコードを書いてみたけど気になった点もあった

ちょっとしたことをやるのでも用意するものが増えて大変
画面遷移どうしようか
プロセス間通信とかBroadcastReceiverとかのことも考えると大変かもなぁ

みたいなところ。画面遷移に関してはセッション中にも「これ！っていうやり方がない」って話だった。同時にプロセス間通信を使ってActivityとServiceで通信をするときや、BroadcastReceiverの通知を受け取る仕組みなんかをつくるときも、ActivityやViewModelで完結しないかなって思う。

こればっかりはしょうが無いのか。

でもやっぱり、設計としてはシンプルだし考えることが少なくなって良いと思った。積極的に取り入れていきたい。

はじめてのUnitテスト

Unit Testing in a Nutshell - DroidKaigi 2018 // Speaker Deck DroidKaigi 2018で登壇してきたので振り返りとか補足とか - 怠惰を求めて勤勉に行き着く

感想？

id: fushiroyama さんのハンズオンを手伝ってきた。 droidkaigi 登壇者デビュー！めでたい！！（本当はちゃんと登壇したい

人前に出て話す機会が割りと久しぶりだったのでちょっと緊張をしたけど、まあまあうまくできたんじゃないかと思った。良かったことはいっぱいあるけど、やっぱりコミュニケーションが取れたことだと思う。

ハンズオン形式で、課題に行き詰まった人のお手伝いをする以外にも実際の業務の中での困りを色々と聞くことができた。なかなか表に出てこないリアルな現場の声だと思うし、実はみんなが求めている課題ってそこにあるんだろうなぁって感想。ｲｼｷﾀｶｲセッションや勉強会はいっぱいあるけど、自分の困りにぴったりマッチできるものってあんまりないからね。

と言いつつ、当日挙げられた質問をメモったりしてたわけでもないのであんまり覚えてない。ただ、いくつかはあって（懇親会のときに聞かれたものも被ってるかも

Realm のテスト辛くないっすか？どうやってますか？
Realm やめた。気合でモック作ってもいいけどそうするとRealmそのもののテストをやる感じになるから意味ない
むっちゃマッチョなActivity、どうやってバラす？
絶対に忘れちゃいけないのは一発じゃバラせないってこと。少しずつやっていく。ネットワークやDBにアクセスをしているようなUIに関係のない部分は最初の方にやる。その次にまだActivityがマッチョなら、すこしずつViewのサブクラスにできないかを検討する。

そんなようなことを答えた。メモっときゃよかったなぁ。

Android Studio30分集中超絶技巧100選

Android Studio30分集中超絶技巧100選メモ DroidKaigi 2018 #DroidKaigi #DroidKaigi_room3

感想

便利

Elastic Team Building

Elastic Team Building // Speaker Deck

感想

成長していくチームの中でどうやってメンバーの増員やメンバー間のコミュニケーションを最適化していったのかの話。人が少ないときに人を取るため、国籍を問わず採用する戦略とか面接の時の基準の明確化で面接を効率化するとか確かにって感じ。

振り返ってみると自分のチームでも実践をしているところはあって、会議にアジェンダを作って共有をすることは必須だしダイレクトメッセージを利用しないとかは当たり前のことだと思っていたけど、ちょっと別のチームを眺めたりするとその限りでも無かったりするので世の中大変だなぁって思ってる。

自分たちのチームはここで言うところのサバイバルフェーズを脱したのかなって思ってはいる。学習フェーズをずっと続けている感じだろうな。コミュニケーションに関する障壁は自分たちのチームではかなり低い方で、会議でもアウトプットしやすい空気感があると思っている。あとは学習フェーズの突破方法か。

Elastic Leader Ship は読んでみようと思った。

エラスティックリーダーシップ ―自己組織化チームの育て方

作者: Roy Osherove,島田浩二
出版社/メーカー: オライリージャパン
発売日: 2017/05/13
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

アプリを成長させるためのログ取りとログ解析に必要なこと

感想

わりとなんとなくで取ってしまいがちなログをちゃんと目的とともに取るための方法の提案。何をどう増やせばビジネスが加速するのか、様々な指標が世の中にあるので、「何を計測」するためのログなのかをハッキリとさせることは重要。

バグ探しや動作の確認という意味でのログ取得ではない。

でっかい規模のチームでやっていて、実装する人とビジネスの人が完全に分かれている場合は分からないけど、自分たちのチームのように小さくてビジネスを考えることと実装を考えることがほぼイコールの場合、仮設を立てて計測して仮設と照らし合わせて・・・って流れになるのでログの取得一つに関してもしっかりとした設計が必要だと感じてる。

試料中には便利なロガーのラッパーを作った話もあるけれど、「何を回収したいのか」がビジネスによって違うことを考えると一概に一般化とかは難しいなってふと思った。

Android案件の見積もりに現れる要素、あるいは丁寧に埋設された地雷たち

Android案件見積りに現れる要素、あるいは丁寧に埋設された地雷たち

感想

わかる〜。

最近はスマホ案件の受託をあんまりやっていないのもあって、ご無沙汰なんだけど、やっぱり「iOSと同じようにして」って言うのはよく聞く。もう聞きたくない。

スプラッシュスクリーンなんかもActivityのライフサイクルを考えるとなかなか難しい。iOSと全く同じエクスペリエンスの提供は難しいってことをちゃんと分かってもらわないと辛いよなって。

人間の管理についても難しい。っていうか、こういうのって失敗しても成功してもよっぽどのことがないと後に残らないからあんまり共有されない気がするので有り難い。

エンジニアだって人間なんだから、新しい何かに挑戦をするようなワクワクする刺激がないとモチベーションが下がっちゃうのはしょうが無い。あと、コードレビューは本当に難しい。簡単に相手の人格を破壊できるしされる。自分の心がここまで弱いのかって驚く。

本当に些細な事だけど「レビューのときは必ず褒める」とかのルールを作っておかないと人間の心は簡単に死ぬ。

All you need is isolating the domain

Y.A.M の雑記帳: Android アプリの開発でドメイン駆動設計に取り組む話

感想

Droid Kaigi に2年間連続物で登壇するの、すごいなぁって思いました。

難しいことで有名なエリック・エヴァンスのDDDをまとめて、現場で使った内容にして頂いた形式になっていて本当に有り難い。かなり実践的というか、実際に利用をする場合を想定したコードや事例の紹介がメインとなっていて、自分たちの現場でも使いたい気持ちが高まる。

値オブジェクトの活用や、ドメイン部分を別のモジュールにすることなどできることは多いように思った。そう言えば自分も以前ドメイン部分っぽい部分を別のモジュールにしていたことがあって、結局設計が別の部分がだめだったのでやめちゃったけれどそんなに悪くはなかったと思ってる。

次にアプリ作ることがあればもう一回実践してもいいかなー？

マルチログインの実装方法

DroidKaigi 2018にて「マルチログインの実装方法」という発表をしてきた - Just for Fun

感想

アカウントごとにデータを取得するRepositoryやメモリ、スレッドなどを管理する仕組みを分けようという提案。やり方の1つで面白いなと思った。ただし、これだと同時にログインをしている状態を作り出すことは難しいなって思った。

メモリの管理については、可変でグローバルな変数はまあ怖いから使いたくないけど、非同期のコールバックが別のアカウントの物が来てしまう現象なんかはあり得るなと思った。Daggerを利用すればスコープのアノテーションを活用していい感じにすることはできそう。

あとは、アカウントを管理するものにライフサイクルのような仕組みを導入してログアウトや非アクティブ化するときにコールバックメソッドの中で非同期処理のキャンセル処理やコールバックの無効化なんかをやるのかな？って考えている。

UIテストの実行時間を短縮させる方法

感想

実機やエミュレータで動作する上に実際のアプリを描画するUIテストを高速化させる話。

Espressoでsleep多用しないとかのコードレベルの話から実行時オプションの話まであって詳しい。本当によく調べられている。助かる、助かる・・・。

DroidKaigi の公式アプリで espresso のsleepを多用したのは私です#droidkaigi #droidkaigi_room2
— numa (@numa08) 2018年2月9日

DroidKaigi の公式アプリについて言い訳をするなら、ViewMatcherが大変だったからってかんじになる。いい感じに目的のViewをみつけるための公文を探すのに疲れ果てて「あとはなんとかしてくれ〜」って気持ちでPR投げたら誰もなんとかしてくれなかった。

テスト関連の話はちょっとニッチ感が高い気がしていて、個人的にはテストに関して酸いも甘いもしっかりと知っておけば正しい状態で「テストをしない」ということも選択できていいかなって思っている。今後もテストに関しての情報収集をしっかりとやっていきたい。

全体の感想

今年はちゃんと公式アプリのコントリビューターになることができたし、登壇者の権利を手に入れたので少なくとも去年参加をしたときよりも何かが成長したように感じた。来年こそはセッション登壇を狙いたい。

セッション会場が去年よりも広くなったのは良かったし、車椅子のスペースがもしっかりとあって「やるじゃん、DroidKaigi！」って感じだった。

お昼ごはんの量もちょうどよかった。新宿にあるから足りなくてもすぐに近くのお店とかで補充ができるっていう安心感もあったかな。個人的なことだけど、朝ブラックサンダーを何個かかってから会場に行くようにしたのが良かった。脳のカロリー補充は大事やで。

空気感も穏やかなものだし、去年の課題だったと思う入場に関する部分もかなり改善されたようだった。やるじゃん、DroidKaigi。

その一方で会場が狭いかなーって気持ちもある。主に廊下とか。セッション間の混雑具合が本当にすごかった印象。もし可能なら廊下を一方通行にできたりすると改善されるのかな・・・？

今年のテーマは「ニッチ」が1つあったと思うけれど、それならもっとセッションの数を増やしてもっともっとニッチなやつがあっても良いな！って思った。

国内のカンファレンスではかなり規模があるものだと思うし、この規模をしっかりと運営して毎年改善しているスタッフは本当にすごい。それに、セッションの資料を作って登壇した方々もすごい。感謝の気持ちしかない。

1年後にまた会いたい。