architecture

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

UI Layerはlib/ui 、 Domain Layerはlib/domain 、 Data Layerはlib/dataに配置しています

上記のState holdersはStateNotifierを使う運用にしています。
UI elementsは、Widgetになります。

実装メモ

各環境への切り替えはdart-define-from-fileを使って制御します PR
API KEYなどの秘匿情報は、Dart-define-from-file + 環境変数ファイルで管理する運用にしています。
- チームメンバーはローカル環境にてここの値を書き換えます。 より良い形を模索中....
ui layer
- シンプルなロジックであればStateNotifierで直接Repositoryを呼び出します。
- エラーハンドリング(try catch)はStateNotifierで行います。
- Threading
- StateNotifierはStateHolderに該当します。シンプルな画面であれば、StateNotifierなしで、setStateを使う手もありかもしれない。
- riverpodはflutter_riverpodを使う運用です
- hooks_riverpodはチームメンバ全員が完全に理解した上で適切に使わないと思わぬ副作用を招くと判断し導入していません
  - 細かい理由としては以下の画像の通り、Jetpack ComposeのLaunchedEffectの扱いの注意点と同じでhooks_riverpodは副作用を招きやすいパッケージのため最終手段として取っておきたい。link

domain layer
- Pure Dartのコードで実装する意識(努力目標としたい)
  - FlutterSDK(packageが'flutter/*'で始まるもの)に依存しない運用にしたいが現状のFlutterアプリ開発では3rdライブラリに頼ることは必須といって良い。
- Threading
- Model(data class)はこのレイヤで持つ.freezedを使う。
- StateNotifierで同じロジックを作成したり、複数のRepositoryを呼び出してStateNotifierの処理が肥大化する場合は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レイヤー側でチェック漏れを防げる。issue
- Threading
Proguard / R8 (For Android)
- Stableのライブラリを使わないと、本番リリース時に思わぬトラブルを招くので、alpha版のライブラリは極力使わない。
- Native Androidアプリの開発にて、Navigationライブラリのalpha版利用時に痛い思いをした。https://github.com/LeoAndo/AndroidAppTemplate/issues/40#issue-925121453