基本的にリモートの場所からJSONをフェッチし、それを解析して、いくつかの要素のクラスをインスタンス化するiOSアプリを開発しています。いくつかの視覚化のために、これは私のjsonがどのように見えるかの基本的な考えをあなたに与えるはずです:
{
"match": [
{
"id": 1,
"date": "1960-01-01",
"team 1": 1,
"team 2": 2
},
{
"id": 2,
"date": "1960-01-02",
"team 1": 1,
"team 2": 3
}
],
"team": [
{
"id": 1,
"name": "Team Red"
},
{
"id": 2,
"name": "Team Green"
},
{
"id": 3,
"name": "Team Yellow"
}
]
}
このJSONは、完全にいっぱいになるとかなり重くなる可能性があります。私の現在のデモシステムでは、4万行と約2 MBのファイルサイズについて話していますが、実際のデータではそれを簡単に超えることができます。明らかに、一度にすべてをロードするのではなく、必要なIDのカップルを含む基本をロードするので、APIリクエストを作成して、やりたいことに必要なIDだけをフェッチできます。
Swiftでは、さらに処理するために各JSON配列を実装しました。
class Match
- id
- date
- teams
class Team
- id
- name
トラフィックを節約し、各ユーザーがアプリを起動するたびにすべてをリロードしないようにするには、結果をキャッシュしたいのです。具体的には、どこかに保存します。しかし、ここがトリッキーになる場所であり、私の質問はどこにあるのですか?
各要素のCoreData表現を作成して、Core Dataを介してそれらを保存し、それらを介してクエリを実行する必要がありますか、または結果のJSONをファイルシステムに保存し、アプリが起動したらロードして、その時点で再解析する必要があります?
Core Dataの主な利点は、エントリを実際に照会してリンクできることを理解しているため、より簡単に質問できます"マッチ#1のチームの名前は何ですか?"。私がコアデータを使用する他の利点はありますか?また、ディスクにJSONファイルを書き込む際にどの(不利な)利点がありますか?
アドホックソリューションよりもCoreDataを強くお勧めします。
1)情報が必要になるたびにraw NSData
を読み込んで解析するよりも高速です。 CoreDataは暗黙的に一部のキャッシュを実行し、ユーザーに関連する情報を保存するだけで済みます(このため、ファイルサイズも小さくなります)。
2)これはコアフレームワークであるため、発生した問題に対して非常に多くのサポートを利用できます。一方、カスタムファイルストレージでは、ユースケースに固有の問題が発生し、サポートが非常に困難になります。
3)必要なボイラープレートコードのほぼすべてを削除するCoreDataサードパーティライブラリがいくつかあります。ほぼNSManagedObject
クラスは他のオブジェクトと同じように扱うことができます。 (注意:NSManagedObjectContext
NSPersistentStoreCoordinator
とNSManagedObjectModel
はまだ設定する必要がありますが、それぞれにコードテンプレートがあります)。
クエリ可能な側面はプラスであり、関係があれば、オブジェクトから別の関連オブジェクトにジャンプするのが非常に簡単です。
結局のところ、学習曲線は急ですが、適切に機能するプロトタイプが得られれば、それは非常に価値があるものだとわかりました。