I’m developing an iOS app which basically fetches a JSON from a remote location, parses it and instantiates classes for a couple of its elements. For some visualization, this should give you a basic idea of what my json looks like:
{
"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"
}
]
}
This JSON can get quite heavy, once it’s completely filled. For my current demo-system I’m talking of 40k lines and ~2 MB file size, but it could easily get way beyond that with my live data. Obviously I’m not loading everything at once, but instead loading the bare basics, that include a couple of required IDs, so I can then make API requests to fetch just the IDs I need for whatever I want to do.
In Swift I’ve implemented each of the JSONs arrays for further processing:
class Match
- id
- date
- teams
class Team
- id
- name
To save traffic and not have each user to reload everything every time they start the app I want to cache the results, more specifically save them somewhere. But here is where it gets tricky, and where my question lies:
Should I rather create a CoreData representation of each element in order to save them via Core Data and query through them, or could I just save the resulting JSON to the file system, load it once the app starts and re-parse it at that point?
The main advantage of Core Data is from my understanding that I can actually query through my entries and link them, so I could more easily ask “What’s the name of the teams from match #1?”. Are there any other advantages for me to use Core Data, and which (dis)advantages could you see in writing the JSON file to the disk?
I would highly recommend CoreData over an ad hoc solution.
1) It’s faster than loading and parsing raw NSData every time you need information. CoreData does some caching implicitly and you only have to store the information that’s relevant to you (thus smaller file size too).
2) It is a core framework so there is a tremendous amount of support available for any issues you encounter. Whereas, a custom file storage is going to have problems very specific to your use case and be very difficult to get help with.
3) There are a number of CoreData 3rd party libraries that remove nearly all of the boilerplate code that it requires; almost to the point that NSManagedObject classes can be treated like any object. (caveat: NSManagedObjectContext NSPersistentStoreCoordinator and NSManagedObjectModel still need to be set up, but there are code templates for each).
The query-able aspect is a plus and with relationships it’s tremendously easy to jump from object to another related object.
Ultimately, the learning curve is steep, but I found it very worthwhile once I got a good working prototype.
1