Coding iOS Databases Module 5 : Core Data

iOS Databases, M5L1-2 : Core Data

by |Published

Lesson 1: Core Data Basics

This introduction to Core Data Basics, cleared up a few things for me. I had heard the phrase “Core Data” before but I had completely the wrong idea in my head.

‘Core Data’ is apparently “local data” – i.e., “database data” held locally on the device, not remotely on a database server like Firebase. This should prove very enlightening.

Lesson 2: Core Data Setup in Xcode

In Lesson 2 from Module 5 of the CWC+ iOS Databases course, Chris takes us through the principle steps of setting up Core Data in Xcode. He covers a lot here, so I’m going to try and sumarise it for future reference.

When starting an Xcode project, we make sure that Use Core Data is selected in the options box.

This causes Xcode to create a .xcdatamodelId file, which will contain our attributes, and a Persistence.swift file which contains the PerstenceController() struct, plus other elements that we get to later in the video.

An attribute can have its class code generated in one of three ways:

  1. Manual / None
    • Xcode will generate two files when we click Editor > Create NSManagedObject Subclass:
      • entityname+CoreDataProperties
        • may be regenerated if modifying entities, so we leave it alone
      • entityname+CoreDataClass
        • this is where we add our own code / methods / etc
  2. Class Definition
    • Xcode handles everything internally and no files will be generated.
      • This is great for simple situations whereby we don’t need to add any custome code of our own.
  3. Category / Extension
    • This is a compromise between the above two options.
      • entityname+CoreDataProperties
        • will be handled internally
      • entityname+CoreDataClass
        • will be generated in Xcode

To get a reference to the Persistent Container, we create an instance of PersistenceController (the struct that is in the Persistence.swift file) and then accessing the container method.

To return an instance of PersistenceController, we use:

let ref = PersistenceController.shared

We could just create the instance, thus –

let ref = PersistenceController()

But, if we did that in several places throughout our code, we’d have several instances which could make it difficult to debug or to track what’s happening.

PersistenceController includes the static property shared. We would call up the instance, thus –

let ref = PersistenceController.shared

This ensures that we’re always referencing the same instance of PersistenceController throughout our code. This is called a “Singleton” – defined as “a design pattern that ensures a class can only have one object”. The class is called a “singleton class”.

PersistenceController has a property called container which is an NSPersistentContainer which simplifies the creation and management of the Core Data stack.

This is how we access the container in order to work with Core Data:

let ref = PersistenceController.shared.container.viewContext

This covers a whole lot of stuff that feels like layer upon layer of complexity but, when written down as I have done here, it becomes apparent that it’s all really about trying to make it as simple as possible.

We can:

  • Create / Edit our entities,
  • Generate our code files (depending upon which Codegen we use),
  • Call a reference to the PersistenceController‘s container, which will allow us to manipulate our Core Data.

A lot of words to think about, but I think it’s sinking in well enough for me to move to the next lesson.

You may also like