An Introduction to Core Data, Part 1

You may bes asking these questions if you are new to iOS programming, or programming in general.

Let’s define those terms: “framework” — this is a group of pre-defined methods, classes, and modules we can use at a high level to work with Core Data, without without worrying about building it entirely on our own.

In iOS programming, Apple provides a framework.

In object oriented programming, “model layer objects” refers to components of the application that encapsulate data into models.

For example, a user model that has a name, id, email, and password property.

Essentially, Core Data provides us with a collection of predefined modules that we can use to create, read, update, and delete objects in a persistence layer.

SQLite and Core DataBear in mind that Core Data is not in itself a database such as MongoDB or SQL.

Instead it uses the built in database system, SQLite, that comes with each iOS device.

Core Data is a framework to manage an object graph, whereas SQLite is the actual relational database.

You can read more on this here.

Now let’s dive into the main components of the Core Data framework.

The EntityAn entity is a class represented in the object graph.

It has a name, properties, and (optionally) relationships.

Each entity created is an instance of the NSEntityDescription class, which we will look at more closely in part 2.

For example, look at the following class declaration:We want to use core data to store every Restaurant and Owner object locally for offline use.

To do this we have to create them in the object graph like this:A representation of the Restaurant entity in the object graph.

That’s the bare minimum you need to know about entities in Core Data.

In part two of this article, we will look at how to create a fully functional Core Data application.

Now let’s see how we can manipulate those entities in code.

We can, for example, show a table view full of items and stores.

The Object GraphXcode provides an interface for developers to view each entity and its relationships in a database-like view.

This is called the object graph and can be seen when you click on the “xcdatamodeld” file.

The object graph is useful for many things, including viewing and editing your entities, creating relationships among your entities, and many other functionalities that we will investigate in part 2 of this piece.

An Xcode representation of an object graph.

The Core Data StackThink of the Core Data Stack as a team of main players that run the game.

There are 4 main components we must be aware of : persistent container, managed object model, managed object context, and store coordinator.

Each component has a specific task and coordinates with others to support Core Data.

Let’s take a look at each of them.

The Persistent containerThe persistent container is the higher level abstraction class that encapsulates the most important components of the core data stack.

Creating your core data stack with the persistent container makes it easy for you to interact with Core Data.

This is the framework’s declaration of the persistent container :The NSPersistentContainer interface from Apple.

We will look at each of these in detail but here are the general concepts :name : whatever you named your “.

xcdatamodeld”.

viewContext : this allows us to save, delete, and fetch data.

managedObjectModel : represents our created entities in-memory.

persistentStoreCoordinator : helps the context and store communicate.

“NSPersistentContainer simplifies the creation and management of the Core Data stack by handling the creation of the managed object model , persistent store coordinator, and the managed object context.

” — AppleThe Managed Object ModelNext we have the managed object model(NSManagedObjectModel).

This is a programmatic representation of the .

xcdatamodeld file.

This is because when you fetch data (after being created and saved) from the store, Core Data needs a way to represent it in code so you can display, update, or delete it.

“A managed object model allows Core Data to map from records in a persistent store to managed objects that you use in your application.

” — AppleThe big picture here is that all the entities, along with their properties and relationships, are represented by the managed object model.

You can read here for more information.

The Managed Object ContextThere are different types of operations when dealing with data storage.

We can create, read, update, save, and delete data.

Here is where the managed object context comes in play.

The business layer of your application interacts with the Core Data Stack through the object context, which in turn keeps a reference to the persistent store coordinator every time we need to make changes to the data in the store.

We will look at how to perform CRUD operation using the object context in part 2 of this article.

The Persistent Store CoordinatorLast but not least is the persistent coordinator.

This acts as the bridge between the core data stack and the store(database).

When an object context makes a request to fetch all the items in the database, the persistent coordinator is the that loads them up from the SQLite store and passes it back to the object context.

The persistent store coordinator is the link between the core data stack and the store(SQLite).

ConclusionWe have already learned a lot about the core data framework.

This will help us tremendously when we create a core data application in part 2, since we will already know what each class and component does.

Core Data is the most complex framework that iOS Engineers have to understand and work with it.

Be patient, soon you will be connecting the dots!.. More details

Leave a Reply