アプリを作っていれば、必ずデータが作成されます。閲覧だけのアプリであっても、元になるデータはどこかに存在するはずです。そうしたデータをどこに置くべきでしょうか。
今回はデータの置き場所と、そのメリットデメリットについて紹介します。
アプリ内
アプリ内に静的データとして置く方法です。メリットはネットワークを使わないので、オフラインでも問題なくデータが扱えることでしょう。画像や動画などのリソースはもちろん、ちょっとしたJSONデータなどであれば十分です。データベースであればSQLite3が使えるでしょう。
デメリットはアプリのサイズが肥大化するので、ダウンロードに時間がかかることです。また、データを更新するためにはアプリをアップデートすることになります。データを追加する度にアプリを更新するというのは若干面倒です。
クラウドストレージ（ユーザ単位）
iCloudやDropbox、Google Driveといったクラウドサービスを使う方法です。ユーザ自身のストレージを使いますので、アプリ提供側として特別なストレージを用意する必要がありません。ユーザ数が増えても大きなストレージが必要にはなりませんので安心です。ユーザ毎のデータになるので、アプリ共通のリソースを保存するのには向きません。
ユーザ側のデメリットとしては、専用のサービスを使っている必要があります。アプリ開発側のデメリットとしては、複数のサービスをサポートする場合は、それらにすべて対応するコードを書く必要があります。
クラウドストレージ（アプリ単位）
ニフクラ mobile backendのようなmBaaS、Amazon S3のようなストレージを使う方法です。アプリ側で用意しますので、ユーザの操作は不要で使えます。SDKを使えば実装工数は大きくありません。もちろんユーザが作成したデータを保存することもできます。
デメリットはネットワークが必須になることです。アプリによっては、クラウドストレージを使うことで初期ダウンロードサイズを抑えられます。そして、初期のチュートリアル中にダウンロードを実行するといった方法も考えられます。
ハイブリッド
クラウドストレージからデータをダウンロードし、キャッシュをアプリ内に保存しておくのがハイブリッドです。オフラインであればキャッシュを使います。また、最新データがあるかどうかサーバに問い合わせ、なければキャッシュを最優先で利用できます。この方法であれば、毎回ダウンロードする必要はなく、ユーザはすぐにアプリを使えます。
欠点は若干開発工数が増えることです。最新データがあるかどうかの確認と、ある場合のダウンロード処理といった実装が必要です。
まとめ
多くのアプリではハイブリッドな設計になっています。初期ダウンロード時からサイズの大きなアプリもありますが、ゲームなどサイズが大きいのも納得されるようなジャンルでない限り、あまり好まれません。また、データの更新のためだけにアプリ自体をアップデートしなければならないのは不便です。
ニフクラ mobile backendを使った場合、データをキャッシュする仕組みは独自に実装する必要があります。その場合はネットワークのキャッシュ、または取得したデータをデータベースなどに保存する方法のどちらかが考えられます。アプリの特性に合わせて選択してください。
