書籍情報保管アプリ #17 『firestoreのデータ構造を考える』

2024年5月26日 16:58

前回はアプリの次のリリースに向けたGitの整理などを実施しました。

今回は書籍データの保管方法について検討しました。

Xcodeのバージョン、ビルド番号をFlutterと同期させる

初回にアプリを公開した際は、下記のページに従ってXcode上でビルド番号を設定していたのですが、Flutterのpubspec.yamlで設定した情報が反映されるようにしました。

下記の２つのサイトが参考になります。

まず、pubspec.yamlに下記のようにバージョン番号＋ビルド番号を記載します。

version: 1.0.1+1

次に、先の参照サイトを参考にして以下の２つを確認します。

info.plistの記載：これは修正不要でした。

<key>CFBundleShortVersionString</key>
<string>$(FLUTTER_BUILD_NAME)</string>
<key>CFBundleVersion</key>
<string>$(FLUTTER_BUILD_NUMBER)</string>

次にproject.pbxprojの記載：これは複数箇所（３−６箇所）修正しました。

CURRENT_PROJECT_VERSION = "$(FLUTTER_BUILD_NUMBER)";
MARKETING_VERSION = "$(FLUTTER_BUILD_NAME)";

これでXcodeでビルドした時に、pubspec.yamlに記載のバージョン番号・ビルド番号と同期されました。

現在公開しているアプリは、各documentに書籍情報（タイトル、著者）とユーザー情報（ユーザーID）を保存している形にしています。

しかし、これでは登録書籍数とユーザー数が増えていったときに、MxNでデータが増えていってしまいます。ということに、自分でテスト用に複数ユーザーを作成して、手元にある同じ本を登録していて気がつきました。

そこで各DocumentにSubcollectionを持たせて、ユーザー関係の情報をSubcollectionに保存するようにデータ構造を変更しようとしました。

データの保存・読み込みの部分はすぐに改修できたのですが、書籍の一覧を改修しようとしたところで、うまくいかなくて困ってしまいました。

以下のサイトなどを参考にしたのですが、どうもうまくいきません。

問題は、書籍の情報のCollectionにユーザーの情報がないため、「あるユーザーの登録した書籍」と言う検索（query）が作れないことでした。

結論を言うと、Firestoreのqueryは１階層のCollectionしか検索できないので（これはレスポンスという意味ではメリット）、ユーザー情報がsubcollectionにあると２回検索しないといけなくなるという仕様によるものでした。

うーん、と色々調べていたところ、下記のサイトに辿り着きました。少し古い記事ですが、オリジナルのFirestoreのYoutubeへのリンクがあり大変参考になりました。

このYouTubeのおすすめは、元のまま本＋ユーザーの情報を一つのCollectionに保存することでした。データの量は増えますが、管理・検索の面ではメリットがありそうです。

ただし、Firestoreの無料枠の限界（１G）があるので少し試算しました。このアプリの目標ユーザー数を１万人、一人当たりの本の数を1000冊とすると、一人当たり100バイト（！！）になってしまいました。1バイトで大体（英数）一文字なので、あまりリッチな情報は保管できなそうです。

とはいえ、１万ユーザー数も、1000冊の登録書籍もまだ先なので一旦このまま進めていくことに決めました。

今回Devブランチで改修を行ったのですが、Mergeについて少しだけ。
当たり前のことかもしれないのですが、少し戸惑ったので記載しておきます。

Devブランチで作業していて、作業の内容をMainにマージしたい場合、まずカレントブランチをMainに戻しましょう。

下記のサイトを参考にしていたのですが、意外と（初歩的すぎて？）記載がありませんでした。

まだまだやりたいことありますね。。

多言語にはできていないですが、ひとまず日本語のメールが飛ぶように設定しました。