Before we can understand how this stack works together, we need to understand some other concepts. A few times throughout this chapter, I've mentioned something known as the object graph, and how Core Data is used to manage it. We've also spent a good amount of time learning about the data model, which Core Data is also responsible for. So before we move forward, let's look at how the two are related.

The data model is a description of a piece of data. The data model tells us that a Person must have a name and an age, and can have a resident relationship with a House. The data model is effectively a blueprint.

The object graph is a set of real data. It tells us that we have three actual people named Emma, Tyler, and Natasha, along with their ages and what House they each live in. The object graph is an implementation of a data set that follows the rules set by the data model. This is actually what is being loaded and saved by Core Data.

Armed with this information, let's now take a look at what is going on in the Core Data stack. The NSManagedObjectModel (usually abbreviated to mom) loads in a data model that we created in the data model editor. The mom is pretty much only used as a way for the NSPersistentStoreCoordinator to know what kind of data is being loaded. To create an instance of the NSManagedObjectModel, we need to load in the model from a file. While a bit counterintuitive, we are not actually going to load in the .xcdatamodeld file, but a file with the same name but a different extension: momd.

Navigate to your AppDelegate.swift file and add an import CoreData command to the top of the file. Then, scroll to the bottom of the class, and add the following code to create our NSManagedObjectModel:

// MARK: - Core Data stack
lazy var managedObjectModel: NSManagedObjectModel = {
    let modelURL = Bundle.main.url(forResource: "SnippetData", withExtension: "momd")!
    return NSManagedObjectModel(contentsOf: modelURL)!

}()

First, we get the location of our data model file from our application's resources using Bundle.main.url(forResource:), again using the filename from our .xcdatamodeld file, but with the momd extension instead. From there we can just instantiate the NSManagedObjectModel using that URL, and return it.

The next part of the Core Data stack is the NSPersistentStoreCoordinator. This object uses the managed object model to actually read and instantiate instances of objects from the persistent store based on the blueprints of the mom (the managed object model, not the mother). A simple way to think about the persistent store is that it is the saved data that exists on disk (it's not always that simple, but don't worry about that for now).

So, essentially, the NSPersistentStoreCoordinator uses the data model to know what the data should look like, and then coordinates creating new data and saving data to the disk. In practice, the managed context (which we will cover next) will do most of the heavy lifting with the persistent store coordinator, but we still need to set it up. Let's do that now:

llazy var persistentStoreCoordinator: NSPersistentStoreCoordinator = {
    let coordinator = NSPersistentStoreCoordinator( managedObjectModel: self.managedObjectModel)
    let urls = FileManager.default.urls( for: .documentDirectory, in: .userDomainMask)
    let url = urls.last!.appendingPathComponent("SingleViewCoreData.sqlite")
    do {
        try coordinator.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: url, options: nil)
    } catch {
        // Replace this to handle the error appropriately.
        let nserror = error as NSError
        print ("Unresolved error (nserror), (nserror.userInfo)")
        abort()
    }
    return coordinator
}()

First, we instantiate a new NSPersistentStoreCoordinator by passing in the managed object model. Again, this is so that the persistent store coordinator knows what the data will look like.

Next, we play around in the file system for a few lines of code in order to get the location of the database (the actual persistent store) that will be coordinated. Once we have that URL, we use a do/try/catch block to load the database from the URL. If it fails, we'll catch the error and need to handle it, but otherwise our NSPersistentStoreCoordinator is set up and ready to go!

Lastly, we have our NSManagedObjectContext, which is mainly what we'll be working with in our code. The purpose of the managed context is to provide an area to play with our data. It is here that we will edit data and create new instances of data; Apple describes the managed context as an intelligent scratchpad. When we are done creating, editing, and deleting data, the managed context can be used to tell the system to save our data, which flushes it through the persistent store and down onto the disk.

Let's set up our managed context now:

lazy var managedObjectContext: NSManagedObjectContext = {
    let coordinator = self.persistentStoreCoordinator
    var managedObjectContext = NSManagedObjectContext( concurrencyType: .mainQueueConcurrencyType)
    managedObjectContext.persistentStoreCoordinator = coordinator
    return managedObjectContext
}()

First, we get a reference to our persistent store coordinator. Then we create a new instance of the NSManagedObjectContext class and pass in the concurrency type. Don't worry about this for now, but we're passing in .mainQueueConcurrencyType. Finally, after initializing the managedObjectContext, we assign its persistentStoreCoordinator to be our instance that we grabbed in the first line. This lets the managed object context know what database it is working with. Now we can return the fully set up context.

We've now completely set up the Core Data stack in our AppDelegate. The managed object model describes our data, the persistent store coordinator interfaces with the database, and the managed object context lets us create, edit, and save data.

However, we can still do a little more in our AppDelegate to make using the stack a bit easier. Let's create a helper function at the bottom of our AppDelegate class that makes it really simple to save our data:

// MARK: - Core Data Saving support
func saveContext () {
    if managedObjectContext.hasChanges {
        do {
            try managedObjectContext.save()
        } catch {
            // Replace this to handle the error appropriately.
            let nserror = error as NSError
            print("Unresolved error (nserror), (nserror.userInfo)")
            abort()
        }
    }
}

The first thing we do in this saveContext() function is check to see if we've made any changes to our data. If not, then there is no point in saving! If changes have been made, then we try to save the data by calling the save()function in our managed object context. If the save is unsuccessful, we'll have to handle the error.

This helper function will make it easier down the line to save our data. Now, with one function call, we can make sure we are not saving data that doesn't need to be saved, in addition to handling errors.

Let's put our new saveContext() function to use. In your AppDelegate class, you should have several empty function stubs still in the class from when the project was created. Many of these are places where you can add code to run when the application enters and exits different states, like entering and exiting the background. There should also be a function called applicationWillTerminate(), which is called when an app is closed. This is a great time to make sure that the user's data is saved, so let's call our saveContext() function from here:

func applicationWillTerminate(_ application: UIApplication) {
    self.saveContext()
}

This will make it so that if any data accidentally goes unsaved, then our app will save it just before shutdown so that information is not lost.

Now we've got our stack set up, and some easy saving functionality ready to go!