hamburger

主に日記

Bonfire Android #6 参加メモ

Yahoo Japanさんが主催しているBonfire Androidに参加してきました。

yj-meetup.connpass.com

目的

  • キャッシュレス × Android のトピックのテーマってなかなか見かけないなと思ったので
  • この辺は流石ヤフーって感じ

内容

新 Kyash Card を支える技術

  • Kyashは人数が少ないので標準に寄せて学習コストを抑えてる
  • カードの描画でConstraintLayoutを使用していて、GuideLineで位置を調整している
    • SpaceやRatioを駆使すれば大概のViewは実現できる
    • ただし、Previewで一見して分からないView( = 可読性が低くて保守できない)は避ける
  • 自前ViewModelからandroidxのviewModelに統一した
    • 複数の画面で共有したいデータはSharedViewModelを活用
  • 以前から導入要望があったNavigatonも利用している
  • SharedVIewModelはデータアクセスを制限するために、interfaceを作成して、それをFragmentごとにInjectしている
  • SharedViewModelの注意点
    • ロジックを持つと複雑になるので、責務は制限すべき
    • まずは使わなくても良いようにすべき
  • SpringAnimation
    • viewにバネのような動きを与えるもの
    • SpringAnimationのほうがバウンスより簡単に自然なアニメーションを作れる
  • UIテストではKakaoを利用
    • EspressoのDSL
    • UIテストを書きやすくなり、時間も短縮できる
    • Espressoから書き換えたときにタイミングやDelayは調整する必要があるかもしれない

Q viewmodel、プロセスkillは?

A savedState使ってる

Q kakaoの他に選定した?

A kaspresso。機能が大きすぎるので依存しそうで避けた

UIテストに関する取り組み

  • 複数の画面サイズ・複数OSバージョン・ライブラリのアップデートの影響調査・minsdkversionの更新の影響調査などを対応したかった
  • アプリサイズが大きくなるに連れ、QAの手動テストが長くなっていった。
    • QAの手動テストを少なくする(なくすのではない)のが目的で導入した -小さく始めてall greenを優先する
  • firebase test labを活用するので、appiumではなくespresso
  • スクリーンショットテスト
    • 画面確認のためにやるので、通信部分はmock化
    • pros 画面開いてスクショ取るだけなので、メンテナンスコストが低い
    • cons そのままだとダイアログが映らない・結局目視が必要
  • ダイアログの問題は自分でダイアログのviewを明示的に取得しに行くか、Falconというライブラリを使う
  • スクショ目視確認問題
    • Facebookは期待値/実際のスクショの比較ライブラリを出している
    • wasabeefさんがブログを出していた
  • インスタルメンテーションテスト
    • 通信部分をmock化しないでテスト。とりあえずハッピーパスを通す
    • 複数端末の確認、初回起動時のみ発生するパターンの確認とかで助かっている ー UIテストはビジネスロジックをそれほど書かないので、慣れると時間がかからなくなる

API通信の状態をsealed classを使って表現する

  • アプリで管理すべき通信状況は主に以下の4種類
    • 初期状態
    • 通信中
    • 通信完了
    • 通信エラー
  • メルカリでは RemoteDataK というライブラリを使用している
    • 内部用のライブラリをOSS化したもの
  • 以下のようなよくある通信状態と意味を変数に持つデータクラスは状態を更新するために必要なロジックが多い
  • いっぽうRemoteDataKだと・・・
    • 拡張関数を使うことで更新ロジックを減らせる
    • そのままだとあまり変わらない
    • 状態をseald classで表現し、値だけ管理することで管理対象を減らせる
  • ただし、Errorは原因に応じたクラスを作成したほうが良いかもしれない

PayPay Androidアプリについて

  • 開発スピードが早いから色々大変
    • 週1のスプリント
    • 月から開発し、水〜金でQA
    • 2019年はios/android合わせて120回のリリース
  • SingleActivityかつFragmentは未使用
    • Fragmentはライフサイクルが複雑
  • lyft/Scoopというライブラリを使っている
    • viewベースに画面遷移を実現する。ライフサイクルがシンプルでわかりやすい
    • ただし、バックグラウンド時などの制御は注意
    • 現在はDeprecated

QA

Androidアプリ開発者の人数は?

  • PayPayが一番多い(2桁)
    • 書いていいのかわからないので具体的な人数は伏せておきます

PayPayはScoopはこれからも使い続けるのか?

  • 剥がすコストが大きいのと今の状態で困っていないのでこのままの予定
  • 新しいメンバーは皆驚くのが悩み
  • scoop利用後に、fragmentTransaction.commitNow()ができたので、Fragmentの辛みが減っているのは理解している。

感想・あとから調査したいこと

  • 全体的に、PayPayの戦略は人数が少なくて学習コストを抑えたいKyashさんと間逆だなぁと感じた
    • 登壇者の方もYahoo本体からの出向らしいので、採用が難しい状況でリソースの融通がきくのは強そう
  • GuideLine はすごく便利そうだと感じた。今まではLinerLayoutのほうが読みやすそうだと思っていたが、複雑なUIになればなるほどメリットが大きそう
    • ちょうどDroidKaigiのアプリで見かけて自分の中のホットトピックだったので、急に興味が湧いてきた
    • ConstraintLayoutを日頃使っている人の中では常識かもしれないが・・・
  • 会社では現在ユニットテストの対応段階なので、UIテストのイメージが少し湧いてきてやる気も出てきた
  • あまり〇〇Payならではの内容はなかったけど、競争が激しいからこそ開発スピードと品質をいかに上げるかを各社頑張っているような印象だった
    • みな自動テストは常識のような顔をしていたのにびっくり
  • 今日一番のパワーワードシュレディンガーのFragment