Droidkaigi2018 day2 参加メモ

詳解 ViewGroupのレイアウト内部実装

http://seto-hi.hatenablog.com/entry/2018/02/03/163035

各ViewGroupの内部実装がどうなっているのか理解できる素晴らしい発表でした。
内容が盛りだくさんでほとんどメモ取れていないので少しだけ。詳しくは資料で。補足も充実してる。

• MeasureSpecでどの程度でMeasureしてほしいか指定する
• ConstraintLayoutはCassowaryを使っている
• Cassowaryを使うほど複雑ではないViewの場合にOptimizerを使う実装になっている

Elastic Team Building

https://www.slideshare.net/YukiNanri/elastic-team-building

• 現場の生々しい話
• エラスティックリーダーシップは良い本
• フェーズ毎に取るべきリーダーシップは異なる
  • サバイバルフェーズ: チームに学習する時間が十分にない状態
  • 学習フェース: 十分なゆとり時間があり、その時間を使って学習や検証を行っている
  • 自己組織化フェーズ: 自分がいなくてもチームがある程度回る
• それぞれのフェーズでどのようなことがあったか紹介

サバイバルフェーズ

採用

• 採用に苦労した。コネがない、エンジニアのことがわからない、誰も来ない。
• グローバルの存在に気がつき、グローバルもターゲットにした。
• 面接効率が悪い。
• 面接を2段階にした。1段階目がダメならそこで終了し、効率良くした。

チャットコミュニケーション

• プライベートメッセージでコミュニケーションする人が多い。情報共有が一部だけになる。
• プライベートメッセージが来たらパブリックに促すようにする
• slackのAnalyticsでプライベートとパブリックの比率が見れるので定量的に傾向を分析できる

会議

• 会議が増えてきた。会議は何も生み出さない。
• アジェンダのない会議が多く、非効率
• アジェンダを事前共有してもらうように促していった。フォーマットも用意。
• ブレストはOK。だが、ブレストで何を決めるかまで明確にして効率的にする。

グローバルメンバーとのコミュニケーション

• 日本語で始まった会話でも英語になるように促してあげる
• コミュニケーションを定量化して評価することが難しい
• 英語を学んでいこうという雰囲気にはなった

学習フェーズ

ドメイン設計

• ドメイン知識がプランナーからエンジニア等に広がっておらず、認識のずれが大きくなってきた
• DDDのユビキタス言語の整備と分からないと発言しやすい環境にする

技術的負債

• 問題になっている箇所をメンバーで話し合う
• 定量化しずらいなのでどのように評価するかチームで話し合う必要がある

自己組織化フェーズ

• リモートワークで、自分がいない環境になった
• 自分がいなくても機能していた
• リモートワーク大変。解決できていない。

React Native Androidはなぜ動くのか

Reactとは

• Viewがツリー階層になる。propsもツリー要素になる。
• 再描画が強い

Reactではないもの

• React, React DOM, React Nativeに役割分担されている

React Native Andriodとは

• なぜjsで動くのか。JavaScriptCoreのおかげ。WebKitの中でJSを動かしてるやつ
• ReactInstanceはReact以外のJSにも使えるものなので混乱しないように注意
• Javaと繋がったJavaScriptインスタンスを保持する

JSとJavaのブリッジ機構

• JavaのクラスをJavaScriptの公開するイメージ
• @ReactMethodのメソッドは先程のスレッドなのでネイティブのUI処理はUIスレッドで行う必要がある
• jsとjava側の両方に仮想DOMがある

すばらしきGraphQLのSEKAIへようこそ

https://speakerdeck.com/gfx/subarasikigraphqlfalsesekaiheyoukoso

SSD Schema Driven Development

• schemaとロジックの開発を同時に進めること

• リソース取得系が非常に柔軟かつ強力

• リソース更新系はメリットは少ない
• GraphiQl
• リクエストからレスポンスがだいたいわかる
• 方は基本JSONと同じ。intとfloatの違いはある
• non nullも定義できる
• relay
  • ...
• クエリは手書き

GraphQLとAndroid

• Appolo Client。クエリからJavaコードを生成するライブラリ
• 本命はjavascriptかなという感じはある
• view componentとqueryを同じファイルに書く
• モデルや腐敗防止層は不要になりそう

gRPCとProtocol Buffersで作る、一味違う通信周り

https://speakerdeck.com/kmats/protobuf

RPC

• RPCは他のアドレス空間にある処理を実行すること
• REST:リソースを中心に考える
• RPC:アクションを中心に考える
• RESTが向いているサービス：ブログAPI(CRUD)
• RPCはURLにアクションが入ってくる（事が多い。仕様で決まっているわけではない）
• CRUDに収まるのであればRESTの方が良い
• RPCが向いているサービス：slackのようなチャットサービス 　　- チャンネルを去る leave 　　- チャンネルから強制的に退出させる kick 　　- 同じような処理だがちょっと違う 　　- RESTでは難しい。RPCにしてしまおう。 　　- 実際SlackのWebAPIはRPC

gRPC

• Googleが開発してRPCフレームワーク
• HTTP/2
• デフォルトではProtobuf
• json/xmlも技術的には可能だが
• grpc-gatewayを使ってJSONを使うことも可能

gRPC-Android的に

• 通信に必要なコードが自動生成される
• RPCフレームワークとして無難。Googleの安心感
• 双方向ストリーミング

デメリット

• 世の中の情報がまだ十分ではない
• セキュリティに不安
• Twitch
  • 内部実装の浮く雑さに起因する問題
  • HTTP/1.1を使えない
• TwitchがTwirpというフレームワークを使った 　　- シンプル 　　- HTTP/1.1化 　　- protobufだが、json mapping化(gRPCはない）prodobufにはある

protbuf

• IDL
• .protoファイルで定義
• .protoファイルをクラサバ間で共有
• .protoファイルからシリアライズ、デシリアライズクラスを生成できる

gRPC/protobuf

• リクエスト部分までコード生成される

開発の工夫

• 書く環境で.protoファイルをどのように同期するか
• github webfuck - google cloud functions - digdag

ウィンドウサイズの変更に強い堅牢な画面の構築

https://speakerdeck.com/nakamuuu/droidkaigi-2018

• 変更
  • 画面回転
  • マルチウィンドウ
• 弱い画面とは？
  • レイアウト崩れ
  • 画面の状態を適切に保持できない

レイアウトの構築

• マルチウィンドウ機能により
  • 幅高さともに狭い状態のレイアウトを考慮する必要がある
  • 通常と異なるシステムUIの配置
• ステータスバーの高さを取得するというアプローチはいったん疑うべき
• fitsSystemWindows問題
• fitsSystemWindowsは一つのViewにしか設定できないのか。そんなことはない
• View#onApplyWindowInsetsをオーバーライドしなくてもOnApplyWIんどｗInsetsListnerで横取りすることができる
• WindowInsetsの扱いを工夫する

画面の状態を適切に保持

• android:configChangesを指定して自前でも管理できるが基本的にはなし
• Handling COnfiguration Changeに詳しく書かれている
• toolargetool
• onSaveInstanceStas¥te or setRetainInstance
• 寿命が違うのでデータの保持
• 復元可能化どうかで使い分ける
• サーバから取得して復元可能なものはsetRetainInstance
• 入力途中の状態のものはonSaveInstanceState
• onSaveInstanceStateからの移行
  • retainer を作った
• 寿命が異なるものを用いたときの整合性を担保したい
  • AACのViewModelを使う

Gradleプラグインを作って開発効率を改善しよう

https://speakerdeck.com/tnj/guide-to-build-gradle-plugin-for-efficient-development

• build.gradle
  • 純然たるGroovyスクリプト
  • .gradleファイルはリモートにおける
• Projectはbuild.gradleと同義に考えて良い
• Extension
• 設定値を格納するオブジェクト
• 実態はJavaBean
• setting.gradleはルートを示すために必要なのでからで良い
• バージョン指定するだけ
• groupは先程のidの前半。 archivesBaseNameは先程のidの最後