fresh digitable

めんどくさかったなってことを振り返ったり振り返らなかったりするための記録

今どんな感じでアプリ開発を進めているかまとめてみる

仕事でAndroidアプリ開発をやって行く中で、自分のスタイルができつつあるので整理してみる。今作っているアプリによるところが大きいと思うので別のケースに対応できるかどうかはわからない。いろいろありそうなのでいくつかに分けてまとめることにする。続くかどうかはわからない。

作っているアプリのこと

  • SNSアプリ
  • phoneオンリー
  • 画像をダウンロードして表示する処理は無い
  • アナリティクス用のイベント取得や送信をする処理は無い
  • minimum sdk level: 19
  • ジャバ

最初の目標:Activityの状態と画面遷移のルールをActivityのViewModelに落とし込む

  • トップレベルメニューの画面をActivityにし、それ以外の画面はいずれかのActivityの中にさしこむFragmentとする
    • ActivityにToolbarとFragment用のコンテナになるViewGroupを持たせ、Activity内の画面遷移はタイトルの変更とFragmentの差し替えで実現する
  • Activityの状態をViewModelで管理する
    • Activity内で表示するFragmentやダイアログをActivityの状態と考える。便宜的に遷移中の状態を定義してもよいことにする
    • ViewModelの中でLiveDataに状態をsetして、Activityでobserveして状態に対応する画面を作る(FragmentManager.beginTransaction()やstartActivity()を呼ぶ)
  • 状態と遷移のルールを洗い出してViewModelのテストを書く
    • PlantUMLを使って状態遷移図を描いている
    • Repository(またはUseCase)はモックする
    • 状態ごとに内部クラスに分ける
    • TestRuleで初期化処理などを共通化しておくと便利

JetpackのNavigationでやってくれるようなことを自分で実装しているだけなのかもしれない。仕事のコードを乗せることはできないが、似たようなことを別の自分の趣味アプリでやって公開できれば説明しやすくなるだろうか。

RobolectricでDialogのOKとかCancelとかのボタンを押す

AlartDialogに付いてるOKとかCancelみたいなデフォルトのボタンを押したくなったので調べた。

dialog.findViewById(android.R.id.button1).performClick()

  • positive: android.R.id.button1
  • negative: android.R.id.button2
  • neutral: android.R.id.button3

:thinking_face:

要はidで探してclickするっていうことなのでEspressoでも同じような感じでできるんだろうか。もうちょっと気の利いたメソッドがありそう。

実行環境でうまく表示できないVectorDrawableについてのメモ

レイアウトエディタのプレビューだと何ともないのに実行環境だと表示が崩れてしまうVectorDrawableのファイルがあったので状況整理のためにメモしておく。

もとのSVGはデザイナさんが作成したものを受け取ったあとSvgToVectorDrawableConverterというツールで変換した。

github.com

 

件のSVGのデータは平たくいうと目のアイコンなんだけど、ノードがものすごく近い間隔でいっぱい置いてあって、「パスが長すぎる」という旨の警告がAndroidstudioに出ていた。ただ、VectorDrawableのプレビューでもレイアウトエディタのプレビューでも問題なく表示できていたので大丈夫かと思ってエミュレータで動かしてみたところ、塗りつぶしの領域を決めそこなった感じの目のアイコンが表示された。

参考: VectorDrawableの穴を塞がないようにする

最初はfillTypeの問題かなと思ってパスをざっくりと読んでみたが、回転の方向はあっているように見えた。また、そのようなツールが公開されていたので確かめてみたが、特に問題はなさそうであった。

 

次に、VectorDrawableが読み込まれてPathオブジェクトに変換されるあたりの処理を眺めることにした。

http://tools.oesf.biz/android-7.1.1_r1.0/xref/frameworks/support/graphics/drawable/static/src/android/support/graphics/drawable/PathParser.java

 

AndroidのPathParserではA命令をいくつかのC命令に変換・分割している様子。A命令をベジエ曲線で近似した時の誤差については次のページが詳しい。

zellij.hatenablog.com

 

いくらか調べて、ノードの間隔が詰まりすぎていると近似したときの誤差でパスが重なってしまい、塗りつぶしの領域が意図しないものに変わってしまうのではないかという仮説を立てた。ちゃんと検証するかどうかは未定。

 

いずれにせよ、近い間隔でノードを置かない、ツールなどでクリンナップする、A命令を予めCやSなどのベジエ曲線の命令に置き換えておくなどしてみると安心かもしれない。