アプリのデータをローカルのどこに保持するか（Shared Preferencesの話）
前回は、いよいよFlutterベースで開発しているアプリの画面と要素の配置が済んだので、処理を実装していくぞ！というところで、あれ？データはどこに格納したらいいのかな？というところで終わりました。
つきつめると、状態管理の設計にちゃんと時間を割いたほうがよさそうだぞ。という空気を感じてはいるのですが、状態管理については一旦目を背けます。（後で読む）
調べてみると、どうもShared Preferencesというプラグインを使うとそれに近いことができそう。GPT先生曰く「小さな量のデータ（ユーザー設定やフラグなど）を保存するのに適しています。」とのこと。
単純なデータ用のプラットフォーム固有の永続ストレージをラップします (iOS および macOS の NSUserDefaults、Android の SharedPreferences など)。データは非同期的にディスクに永続化される可能性があり、戻り後に書き込みがディスクに永続化される保証はないため、このプラグインは重要なデータの保存には使用しないでください。
重要なデータの保存に使うなよというのはローカルストレージ使う時にも書いてありましたね。無知でお恥ずかしいですが、SharedPreferencesというのはAndroidのデバイス内に保存する仕組みのことを指すみたいですね。
FlutterはGoogle謹製ですから、そちらの用語であることは納得です。（iOSだとNSUserDefaultsという領域？に保持されるみたいですね）ちなみに、具体的にはアプリ用ディレクトリ以下にある shared_prefs の下に保存されるとのこと。
SharedPreferencesとは情報をAndroidデバイス内に保存する仕組みです。
「わーじゃあSQLiteいらないやん」と一瞬なるかもしれませんが、キー・バリュー形式で1対1で保存されるだけなのでデータをオブジェクトとしてidで紐付けて管理するといったようなことは出来ません。
よって、主にユーザー設定や状態保存など、単純で少量の環境設定保存に用いられます。その実態はXML形式のテキストファイルです。保存できるデータの型はString, int, float, long, boolean, Set<String>です。
目標日数と経過日数と達成回数の保存に使うのはややグレーな気もしますが（何かあった時にもサーバー側ではなくてクライアント側の話なので復元できないし）、いったんMVPMVPをFlutterベースで再現すると言う目標に対しては同等の機能という位置付けで採用したいと思います。
ゆくゆくはFirebase Firestoreとかと同期させるみたいなことを考えていくのだろうな。そこまでできたら楽しいな。。。
次回はshared_preferencesを開発環境に追加してみる話と、データ設計というと大げさだけど、MVP版も紐解きながら、いくつデータ項目が必要なのか決める話みたいなのが2回の日記に分けてできそうですね。
その先はどうしようか。3本の基本的な処理を1個ずつ作る。まあ3回の日記に分けてもいいですね。そしたら一応動くものにはなっているはず。
初回立ち上げ時のチュートリアル部分の準備とかもいるが。ここはリリース直前でもいい感じがする。まあこれも1回分の日記。
やっぱり最後はデザイン整えるみたいなところが苦戦しそうですね・・・
すごく蟻（亀？）の進捗だけど、毎日何かしら手をつけるルーティンが浸透してきたので、一回今後のざっくり計画を見繕ってみてもいいかも。具体的な実装に入る前にまず次回は一回立ち止まってそれを書き出してみようかと思います。
ご覧いただきありがとうございます。とても嬉しいです。