[WIP] architecture

アプリのアーキテクチャは以下のガイドラインを意識しています。
https://developer.android.com/topic/architecture

実装メモ

• 各環境への切り替えはproduct flavorを使って制御します PR

• stub環境でのテスト PR

• API KEYなどの秘匿情報は、 local.propertiesで管理する運用にしています。

• ui layer

  • ComposeのPreviewを行いやすくするために、StatelessなComposableを作成しています。
  • Composableの引数にListなどの不安定な型の値を渡さない設計にする 理由はここ
  • XXXEffect関数内で直接ラムダ式を呼び出すのは安全でないため、必ずrememberUpdatedStateを使う
    • https://github.com/LeoAndo/android-jetpack-compose-training/issues/69#issuecomment-1289922905
  • シンプルなロジックであればViewModelで直接Repositoryを呼び出します。
  • エラーハンドリング(try catch)はViewModelで行います。
  • Threading
  • ViewModel はStateHolderに該当します。シンプルな画面であれば、ViewModelなしで、androidx.compose.runtime.saveable.rememberSaveableを使う手もありかもしれない。

• domain layer

  • Android Platform API(packageがandroid.xxで始まるもの)に依存しない運用にしています。
  • Threading
  • Usecaseは、Dispatchersに(Default Thread)を使う運用にします。
  • Model(必要に応じてSerialize)はこのレイヤで持つ. Parcelable使う場合、Android APIに依存するので..。
  • ViewModelで同じロジックを作成したり、複数のRepositoryを呼び出してViewModelの処理が肥大化する場合はXXXUseCaseクラスを作成し処理を切り分ける運用にする。
    • https://www.youtube.com/watch?v=gIhjCh3U88I

• data layer

  • 小規模アプリでは、domain entity と mapperは不要かもしれない。data entityを直接UIレイヤーで使う。
    • https://www.youtube.com/watch?t=79&v=cfak1jDKM_4&feature=youtu.be
  • 異常系は、シールドクラスで作成したカスタムExceptionをthrowさせる。シールドにしておくとUIレイヤー側でチェック漏れを防げる。
    • link
  • Threading
  • Repository or DataSourceには、Dispatchersに(IO Thread)を使う運用にするが、RoomやKtorなどのメジャーなライブラリには不要。詳しくは上記Threadingに詳しく書かれていて、Roomで実験済みPR

• Proguard / R8

  • Stableのライブラリを使わないと、本番リリース時に思わぬトラブルを招くので、alpha版のライブラリは極力使わない。
  • 以前、Navigationライブラリのalpha版利用時に痛い思いをした。https://github.com/LeoAndo/AndroidAppTemplate/issues/40#issue-925121453