What is Core Data/Core Data & Swift Best Practices Part 1
Ah yes. Core Data. The novice developer’s bane and the senior developer’s headache. Just mention Core Data to a room full of developers and hear the symphony of groans. Nevertheless, to consider oneself a proper iOS Developer she must learn to tame this component of iOS Development. The goal of this series is several fold: (1) Help you understand the architecture of Core Data (2) Ultimately help you understand what is happening “under the hood” of core data and (3) Give you a simple example app written in Swift to get you started with Core Data whilst giving you an idea of best practices.
First, Core Data is a framework. If there’s anything you take away from this write up, it should be the previous sentence. Core data is an object graph management and persistence framework. It allows you to work with data as objects, regardless of how they might be persisted to disk. It’s an abstraction; a layer. Why is this useful to us as developers? I’d argue that Core Data’s greatest strength is that it’s already available for us to use as developers. Apple maintains it, it’s been around for more than a decade, and it’s been battle tested. Additionally, it’s easier to handle pure data as an object in this OOP world of ours.
To actually handle these — -conventionally known as Managed Objects — Core Data conveniently sits between your application and a persistent store. Don’t think too hard about what that means. The persistent store is just what fancy-pants engineers call any form of data that survives — or persists — through a hardware reset. This falls into one of the following categories: a SQLite database, XML File (which, while can be manipulated by iOS systems, can’t be used as a persistent store), and/or a binary store. There’s one last potential — and ironically named — persistent store available and that’s the In-Memory store, but for the sake of length I won’t delve too deeply into that.
When I first started developing in iOS all this confused me. I thought to myself, ‘Okay then, what the heck is Core Data?’ Unfortunately, like many tech terms, Core Data has become a ubiquitous catch all meant to capture a larger, complex system. But think of what the meaning of the words, Core Data mean. It may be tautological but the core definition — pun completely intended — is nothing more than that: data at the core of your system and, subsequently, your application.
The Core Data stack — in its most simplest form — contains four pieces:
(1) The Managed Object (NSManagedObject)
(2) The Managed Object Context (NSManagedObjectContext)
(3) The Persistence Store (NSPersistentStore) and
(4) The Persistence Store Coordinator (NSPersistenceStoreCoordinator)
Our objects — when created — are referred to as Managed Objects. Because they are managed by Core Data they live in a specific context. In this case that is the Managed Object Context. At this point you’re probably asking, ‘Okay Kacheflowe that’s all well and good, but what is the Managed Object Context?’
The managed object context keeps track of its managed objects and all the changes you make to them, i.e. insertions, deletions, and updates. And each managed object knows which context it belongs to. Core Data supports multiple contexts, but let us not get ahead of ourselves: for most simple setups, like the one in this series, we will only use one.
The context connects to a persistent store coordinator. It sits between the persistent store and the managed object context and takes a coordinating role between these two. As with the contexts, you can also use a combination of multiple persistent stores and store coordinators.
This all might sound like a jumble to you so I’ve created a chart to help you visualize. Below you’ll find a good visual overview of Core Data’s architecture:
Core Data’s greatest achievement perhaps is that it makes relationships between objects very simple. One to many or many to many. You’re essentially just manipulating sets. Without Core Data you’d have to communicate with SQLite directly; if that were the case you’d be forced to create a lookup table to relate your objects. And as anyone who’s bothered with such an endeavor might know, that can be a bit of a pain to maintain (coughs Not that I’d know anything about that).
That’s all for now. I don’t really like delving into code until I feel there’s sufficient understanding of what’s happening under the hood. In Part 2 we’ll actually begin writing the skeleton for our example app.
