Core Data — The Simplified Version
Simple Persistence NSUserdefaults, iOS File System and Sandboxing
Comprehensive Persistence Core Data
Core Data — Data Layer Management framework i.e Data Modal + Related Code = Data Layer
Core Data has mainly 2 functions — Persistance or saving data to the device
Its tasks include
a. Modal Creation
b. Data Layer Management
Core Data is a framework for managing an app’s data layer.
This includes the app’s model (the data’s structure and relationships), as well as code for changing the model and updating the UI when the model changes.
When we say that Core Data is a framework, we mean that it is a library — or bundle of code — that can be included in an app and used to perform specific tasks. In the case of the Core Data framework, those tasks are model creation and data layer management.
You can begin using Core Data in your apps before you even get close to adding persistence — and will find it easier to add persistence later if you do!
Core Data != Persistence
Persistence is just one aspect of data layer management. But it is an important one!
So now that we’ve cleared up the common misconception, let’s explore why we might want to use Core Data for persistence.
How Does Core Data Save Data?
Persistent Stores
Core Data saves (or persists) data into something called a persistent store (think storage). The store is where the data lives.
Types of Stores
There are three different types of persistent stores Core Data supports on iOS:
- a SQLite store (the default)
- a binary store
- an in-memory store.
SQLite
SQLite is almost always the right choice for your persistent store; it means your data is stored in a SQL relational database, and there are a few handy features in Core Data (like model caching during migration) that only work with the SQLite store. And since you don’t interact with the persistent store directly, you don’t need to know any SQL to use the SQLite store.
In-memory
The in-memory and binary stores have different characteristics in terms of memory usage and performance. The in-memory store can be appropriate when you have a small data model that can fit in memory all at once and that doesn’t need to be saved to disk — for example a Cache.
Binary
The binary store can be appropriate when you always need the database to be read and written in its entirety — for example if you are using a file format such as CSV.
Abstracting the Store
Core Data abstracts the persistent store’s details. That means you won’t usually interact with the store directly. You can think of Core Data as a layer that sits between your code and the underlying store, making it easier for the two to communicate.
Core Data provides a common interface for saving and fetching data, no matter what kind of store sits below. Whatever type of store you choose, you’ll always use the same Core Data classes to access and manage your data. And you won’t need to learn a database-specific language to manage your data; you can do it all in Swift.
You can find more information about the different store types in the Persistent Store Features documentation.
Are There Other Ways to Save Data?
Yes. Although Core Data is a great solution for persisting data that has structure and relationships, other solutions are better suited for other types of data. For settings or small pieces of data, UserDefaults is most appropriate. If you want to store data directly on the file system, you can use the Foundation framework to serialize and write data to files. If you are familiar with SQLite, then you could use it directly instead of through Core Data. There are also ways of caching transient, downloaded data such as the result of a network request.
Third party databases and persistence frameworks like Realm and Firebase provide useful features like syncing local and remote data, and cross-platform support for iOS and Android. But, while powerful, these frameworks often lack UIKit integration, and they may not implement the full extent of Core Data features. It’s up to you to consider the tradeoffs.
If you’re curious about Firebase specifically, the Firebase in a Weekend free course we created with Google is a great starting point.
Two-sided Relationships
You might be wondering why Core Data created a two-sided relationship between the entities, since in our Swift code, we only modeled the relationship in one direction.
If you’ve worked with databases, you might even be wondering if it would be easier to just include an ID field instead of explicitly creating relationships.
Core Data uses two-sided relationships.
Think about what happens when a note or a notebook is deleted.
When a note is deleted, we don’t want to make any changes to the other notes — and we certainly wouldn’t want to delete the whole notebook.
But when a notebook is deleted, we’ll want to delete all of its notes.
If we were using an ID field, there would be a lot of bookkeeping to make sure we deleted all the notes that referenced a deleted notebook.
Core Data includes functionality to model deletion behavior. Modelling the relationship in both directions lets Core Data traverse the web of entity class instances (also known as the “object graph”) and make sure all affected references are updated. This is called referential integrity.
Let’s take a look at how this works.`
Deletion Rules
For our notes relationship, choosing the Cascade rule will mean that deleting a Notebook will cause all of its referenced notes to be deleted.
For our notebook relationship in Note, choosing Nullify means that the relationship will simply be removed, but the referenced Notebook remains.
That’s all that’s required to get the deletion behavior we want, and ensure that references between our objects never become invalid.
If you’d like to read more about deletion rules, scroll to the Relationship Delete Rules on the Creating Managed Object Relationships page of Apple’s Core Data Programming Guide.
Core Data Stack
The core data stack contains 4 separate segments
- Managed Object Context — NSManagedObjectContext
- Managed Object Model — NSManagedObjectModel
- Persistent Store Coordinator — NSPersistentStoreCoordinator
- Persistent Container- NSPersistentContainer
