flutter_setting_notify

これは，アプリの初期設定などを効率的に読み込ませる位置を，Clean Archtectureに従って考えた際のベストプラクティスに対する考察です．

この方法の特徴

まず，設定の保存先としてはSharedPreferencesを用いています．
クレデンシャルな内容などを保存する場合は，追加でFlutter Secure Storageを用いるべきだと考えます．

特徴は以下の通りです．

• ProviderScopeでのoverrideを用いることで，Storage操作クラスや，データクラス，Loggerクラスなどを外部から注入している
  • これにより，DIを実現し，テスト性向上
• 依存をProviderに集中させ，複雑な依存関係になることを避けている
• Storage操作クラスには自作のキャッシュ機構を設け，そのキャッシュを使うことで，Steram型でのデータ配信や，思いI/O処理を避けるようになっている
  • メモリリークなどに対しては対策をしていないため，使用量は考慮する必要がある
• AsyncNotifierを持ちいて，設定の初期値をロードするようにしている．
  • しかし，AsyncValueは使いづらいため，そのNotifierProvider自体を監視するProviderを一枚挟み，Settingクラスをそのまま扱えるようにしている

改善の余地

そもそも，設定値がAsycValueで管理されていることがおかしいので，これをmain関数に初期化処理を集中させ，Settingsを管理するNotifierには外部から初期値を注入するような方式にする方が，扱いやすくなるのではないか．

設定を見るためのProviderと，設定を書くためのNotifierProviderが分かれていることが使いにくさ，可読性の低下を招いていないか．
それとも，ロジックの分離を実現しており，読み込み不良などの状態を扱いやすくなるため，そのままでも良いか．

良かったところ

状態更新のコストが大きくなるとは言え，ユーザーが変更可能なアプリの内部状態をSettingsというimmutableクラスに分離させるのは，良い手法だと感じた．
また，Povider二枚重ねは，稼働性の低下以上に，操作性の向上があるため，かなり便利だと感じた（自動生成との相性も良い）．
Storageクラスに独自のキャッシュ機能を入れたのは，アクセス回数を最大で1回に削減できるため，かなり良いと感じた．
しかし，Riverpodでの状態管理というキャッシュもあるため，なんとも言えない（画面遷移などがあるプログラムになるとさらに効果を発揮するかも？，もう少し設定値が複雑になるまでは，無駄になることの方が多いと考えた）．
ただ，独自実装のキャッシュ機能のおかげでStream型でのデータ配信をSharedPreferences上で実装できるというのはかなり強みだと思う．
そいうかこれのためだけに実装してもいいと思う．