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。だが、ブレストで何を決めるかまで明確にして効率的にする。
グローバルメンバーとのコミュニケーション
- 日本語で始まった会話でも英語になるように促してあげる
- コミュニケーションを定量化して評価することが難しい
- 英語を学んでいこうという雰囲気にはなった
学習フェーズ
ドメイン設計
技術的負債
- 問題になっている箇所をメンバーで話し合う
- 定量化しずらいなのでどのように評価するかチームで話し合う必要がある
自己組織化フェーズ
- リモートワークで、自分がいない環境になった
- 自分がいなくても機能していた
- リモートワーク大変。解決できていない。
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
gRPC-Android的に
デメリット
- 世の中の情報がまだ十分ではない
- セキュリティに不安
- Twitch
- 内部実装の浮く雑さに起因する問題
- HTTP/1.1を使えない
- TwitchがTwirpというフレームワークを使った - シンプル - HTTP/1.1化 - protobufだが、json mapping化(gRPCはない)prodobufにはある
protbuf
gRPC/protobuf
- リクエスト部分までコード生成される
開発の工夫
ウィンドウサイズの変更に強い堅牢な画面の構築
https://speakerdeck.com/nakamuuu/droidkaigi-2018
- 変更
- 画面回転
- マルチウィンドウ
- 弱い画面とは?
- レイアウト崩れ
- 画面の状態を適切に保持できない
レイアウトの構築
- マルチウィンドウ機能により
- 幅高さともに狭い状態のレイアウトを考慮する必要がある
- 通常と異なるシステムUIの配置
- ステータスバーの高さを取得するというアプローチはいったん疑うべき
- fitsSystemWindows問題
- fitsSystemWindowsは一つのViewにしか設定できないのか。そんなことはない
- View#onApplyWindowInsetsをオーバーライドしなくてもOnApplyWIんどwInsetsListnerで横取りすることができる
- 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の最後