Core Data on Andrew Bancroft

Using Core Data With SwiftUI - An Introduction

Wed, 31 Jul 2019 04:40:54 +0000

How does Apple intend for us to use Core Data with SwiftUI?

They gave us a path forward with the most recent beta release of iOS 13 (Beta 5 at the time of this writing)!

Resources

First Things First

To work effectively with Core Data in SwiftUI, the Data Flow Through SwiftUI WWDC session is a huge help.
With this talk under your belt, you’ll have at least been introduced to key words like @State, @Binding, @ObservableObject (which replaces @BindableObject as of Beta 5), and @Environment.

On the Right Path

Even prior to Beta 5, the “right path” for using Core Data with SwiftUI seemed to be through the @Environment.

In the release notes for iOS Beta 5, Apple seems to be leading us there:

NSManagedObject now conforms to ObservableObject.

The new @FetchRequest property wrapper can drive views from the results of a fetch request

managedObjectContext is now included in the environment.

With these three pieces in place, Apple has given us out-of-the-box support for using Core Data with SwiftUI.

So…

How Do You Get Started?

I decided to create a basic, single-view app that can

Persist a list of BlogIdeas to a Core Data persistent store
Use the new @FetchRequest property wrapper to fetch BlogIdeas
Use the @Environment’s managedObjectContext to create, update, and delete BlogIdeas

Grab the project over at GitHub and explore!

The sample project that includes a single Core Data Entity named BlogIdea:

I kept as much out-of-the-box stuff as I could.

How Does It Work?

Throughout the project, you’ll notice emoji symbols to help draw your eye to the Core Data pieces.

❇️ Alerts you to Core Data pieces

ℹ️ Alerts you to general info about what my brain was thinking when I wrote the code

Code Walkthroughs

I completely relate if you need to chunk things up and inspect the details of how each piece of the puzzle looks in isolation before you dive into the full app.

I’ve written up two separate how-tos that show you more specific details:

Breaks down how to pass an NSManagedObjectContext instance to your SwiftUI Views.

Breaks down how to use the @FetchRequest property wrapper in your SwiftUI Views.

NSPersistentCloudKitContainer Buggy Behavior List

Thu, 11 Jul 2019 04:40:54 +0000

NSPersistentCloudKitContainer is brand new with Xcode 11 and iOS 13.

It works… kind of… sometimes…

I’m keeping this list of buggy behavior to help keep my head straight. I’ve also filed bug reports on each.

Hopefully others in the iOS community who are experimenting with NSPersistentCloudKitContainer can confirm or deny these same oddities. If they’re fixed in a subsequent beta, I’ll come back here and note it!

Which Beta Version Does This Affect?

I’ve tested out each of these on iOS 13 Beta 5 and Xcode 11 Beta 5.

Enabling CloudKit doesn’t create a default container

In Xcode 11, adding the iCloud capability and clicking the CloudKit checkbox is not automatically creating a default container for new apps that I’m testing…

Xcode 10

Xcode 11

Existing data doesn’t sync

Suppose that…

You have an existing Core Data app
The app is installed on two devices with the same user signed in to iCloud
Data has been saved independently on both devices

Now suppose that you want to take advantage of the automagic syncing offered with NSPersistendCloudKitContainer.

If you…

Set up your app to work with NSPersistentCloudKitContainer
Rebuild your app and install it on both devices
Launch the app on both devices…

You might expect the existing data to show up on both devices. It doesn’t.

If you add new data on one device, only the new data that gets saved after the NSPersistentCloudKitContainer conversion gets synced. Existing data never does.

🤷🏼‍♂️

Data only syncs after you close and re-launch your app

I really thought I had this figured out. Beta 5 has proved me wrong.

In Beta 2, simply setting automaticallyMergesChangesFromParent on the container’s viewContext to true seemed to work.

Not with Beta 5.

You can save new data and wait (and wait… and wait…). It doesn’t show up in the UI until after you re-launch the app.

Here’s what I’m experiencing:

Record accessor methods missing in Xcode

“On my machine”, attempting to use the record(for:) methods on NSPersistentCloudKitContainer produce the following error message:

Value of type ‘NSPersistentCloudKitContainer’ has no member ‘record’

I can “Jump to definition” and the methods appear to be there…

Attempting to use the function in code doesn’t work…

How Smart (Or Dumb?) Should NSManagedObjects Be?

Wed, 19 Jun 2019 04:40:54 +0000

Apps aren’t “dumb”. Apps do things. Smart things. The question is: Where do the “smart parts” go?

So how you smart or how dumb should NSManagedObject subclasses be?

What code should you write in one of these? What should you not?

TLDR;

Keep NSManagedObjects about Core Data-y things.

Ask, “Does this help my NSManagedObject subclass work with Core Data-related functionality?”

Let the answer to that question guide your decision about whether to extend your NSManagedObject subclass with additional features.

Designed Overrides

Apple has designed some spots for you to customize an NSManagedObject’s default behavior.

Managed Object “Life Cycle” Events

NSManagedObject comes with several overridable methods that you can implement in order to “hook in” to the life cycle of the object. What do I mean? Check out this sampling of overrideable methods:

awakeFromFetch(): Provides an opportunity to add code into the life cycle of the managed object when Core Data is bringing the object from the persistent store into memory.

awakeFromInsert(): Provides an opportunity to add code into the life cycle of the managed object when it is initially created.

willSave(): Provides an opportunity to add code into the life cycle of the managed object when it is about to be saved.

didSave(): Provides an opportunity to add code into the life cycle of the managed object after the managed object’s context completes a save operation.

These methods can be overwritten to add code that should be strategically executed at these pre-determined-by-Apple points in time.

Validation Code

You can implement custom validation logic in an NSManagedObject subclass. Don’t override validateValue(_:forKey:) though.

Instead, implement a custom method with a signature that matches the signature of validatePropertyName:error:.

For example, if your NSManagedObject subclass has an age property and you wanted to implement special validation logic, you could do this:

func validateAge(value: AutoreleasingUnsafeMutablePointer<AnyObject?>) throws {
    guard let valueNumber = value.pointee as? NSNumber else { return }
    
    if valueNumber.floatValue > 0.0 {
        return
    }
    
    let errorStr = NSLocalizedString("Age must be greater than zero", tableName: "Employee", comment: "validation: zero age error")
    let userInfoDict = [NSLocalizedDescriptionKey: errorStr]
    let error = NSError(domain: "EMPLOYEE_ERROR_DOMAIN", code: 1123, userInfo: userInfoDict)
    throw error
}

You could also override one of these methods to add advanced validation:

validateForInsert()
validateForUpdate()
validateForDelete()

Key-Value Observing

NSManagedObject subclasses inherit methods related to key-value observing that could be appropriate to override.

Summarizing Designed Overrides

Have you noticed a pattern in each of these sections?

Key word: override

Apple designed NSManagedObject with intentional, overrideable methods.

“Should I implement this code here?”

Take a look at the method names and let that be a guiding factor in your decision-making.

On Fetching Behavior

Xcode adds a fetchRequest method when it auto-generates code for you. So…I’d say it’s probably okay to put some basic fetching behavior with an NSManagedObject subclass. Keep it simple though:

1
2
3

  @nonobjc public class func fetchRequest() -> NSFetchRequest<EntityName> {
      return NSFetchRequest<EntityName>(entityName: "EntityName")
  }

My personal preference is to put object fetching behavior in a separate Type.

You might make a DataProvider Type and let it handle setting up NSFetchRequest(s) with appropriate predicates and sort descriptors.

Avoid putting all data-providing code in a catch-all DataProvider. If you’re fetching Notes, make a NoteProvider. If you’re fetching Tags, make a TagProvider.

On Convenience Properties & Functions

One piece of convenience code that I extend my NSManagedObject subclasses with is an entityName property.

This helps me avoid sprinkling the name of an Entity in String form throughout my code.

1
2
3

extension EntityName {
    static let entityName = "EntityName"
}

When it comes to other types of functionality, my recommendation is to put that code elsewhere.

Keep NSManagedObjects about Core Data-y things.

Ask, “Does this help my NSManagedObject subclass work with Core Data-related functionality?”

Let the answer to that question guide your decision about whether to extend your NSManagedObject subclass with additional features.

“Additional features” often translates to “additional responsibility”. Single responsibility is the name of the game if you can achieve it.

On Core Data Object Fetching and Display Strategies

Fri, 14 Jun 2019 04:40:54 +0000

Setting the Stage

Suppose one of the NSManagedObject subclasses from your Core Data data model looked like this:

public class BlogIdea: NSManagedObject {

    @NSManaged public var ideaTitle: String?
    @NSManaged public var ideaDescription: String?

}

Suppose that you also have a class that will provide BlogIdeas to your view controller:

1
2
3

class BlogIdeaProvider {
    // fetches BlogIdea instances to use in your view controller
}

Requirement: Say that you need to list all of the ideaTitles you have inside of a table view (note that you don’t need to display the ideaDescription at this time).

Question: Which of the following strategies would you recommend for this requirement?

Fetch all the BlogIdea objects, return them, and then use those returned NSManagedObject instances to display the ideaTitle in the table view.

1class BlogIdeaProvider {
2    func fetchBlogIdeas() -> [BlogIdea] {
3        // fetch BlogIdea instances
4
5        // return the BlogIdea NSManagedObject subclass for the view controller to use
6    }
7}

Fetch all of the BlogIdea objects, but make a fetchBlogIdeaTitles function instead. Just return the ideaTitles, say, in an array of strings to display in the table view.

1class BlogIdeaProvider {
2    func fetchBlogIdeaTitles() -> [String] {
3        // fetch BlogIdea instances
4
5        // pull out ONLY the ideaTitle, 
6        // assemble an array for the titles, 
7        // return the array
8    }
9}

Swifting Out Loud

I’ll give my recommendation and then walk through my reasoning.

In nearly all situations, I would go with option number 1: fetch the NSManagedObject instances that I need to display, and work with those fully-featured objects, rather than go through the effort to return only the Strings that I need for display.

Why?

To that, I’d ask the question: “What are you planning to do next, once the ideaTitles are displayed in the table view?

Presumably, you’re displaying them so that a user can tap on a cell and…do something with them. And that “do something with them” part almost always means

Show more details (in which case, you need the ideaDescription property as well now)
Edit the object (in which case you get all your saving features only if it’s in NSManagedObject form)
Delete the object (again…needs to be a full NSManagedObject to easily delete)

Efficiency Trade-offs

One might be concerned about efficiency – “Why return a full object when you only need one of its properties?”

That’s true. You only need one property…for now. Again, I think it goes back to “what happens next?”

Fetching Efficiency

Will you display the ideaTitle and then have to go fetch again to get the rest of what you need from your persistent store? That’s almost guaranteed to be less efficient than holding the full NSManagedObject in memory from the start.

Memory Efficiency

If you’re trying to stay memory-efficient, perhaps another idea is to fetch only a subset of the BlogIdeas… You could limit the number of results that come back (after all, only so many can be shown in a table view at a time, anyway, right?).

Code Efficiency

When you say “Core Data” and “table view” in the same sentence, it should also trigger the word NSFetchedResultsController. This class is a huuuuge help because it was designed specifically for displaying data from NSManagedObjects in table or collection views. If you only return an array of Strings, you’ll have to write a bunch of boiler plate code yourself to keep your table view in sync with your persistent store, but you get all of that for free with NSFetchedResultsController.

Using NSFetchedResultsController would change the code a bit. Instead of returning an array of blog ideas ([BlogIdea]), you could hold a reference to a NSFetchedResultsController<BlogIdea> and configure it to fetch:

 1// MARK: - Concept
 2// If you give a `Provider` a persistent container, and a fetched results controller delegate to talk back to,
 3// a `Provider` Type can act as a liaison between the view controller and the pieces of Core Data that are needed
 4// to initialize a fetched results controller, perform fetches, and other Core Data related actions on behalf of your
 5// view controller (instead of you putting all this code in the view controller itself)...
 6
 7class BlogIdeaProvider {
 8    private var persistentContainer: NSPersistentContainer
 9    private weak var fetchedResultsControllerDelegate: NSFetchedResultsControllerDelegate?
10    
11    // MARK: - Initializers
12    init(with persistentContainer: NSPersistentContainer, 
13              fetchedResultsControllerDelegate: NSFetchedResultsControllerDelegate?) {
14
15        self.persistentContainer = persistentContainer
16        self.fetchedResultsControllerDelegate = fetchedResultsControllerDelegate
17
18    }
19    
20    // use this in your view controller to display BlogIdea instances
21    lazy var fetchedResultsController : NSFetchedResultsController<BlogIdea> = {
22        // Configure a fetched results controller and perform an initial fetch
23        let blogIdeasFetchRequest = NSFetchRequest<BlogIdea>(entityName: "BlogIdea")
24        
25        let controller = NSFetchedResultsController<BlogIdea>(  fetchRequest: blogIdeasFetchRequest,
26                                                                managedObjectContext: self.persistentContainer.viewContext,
27                                                                sectionNameKeyPath: nil,
28                                                                cacheName: nil)
29        
30        controller.delegate = self.fetchedResultsControllerDelegate
31        
32        do {
33            try controller.performFetch()
34        } catch {
35            fatalError("\(#function): Failed to performFetch: \(error)")
36        }
37        
38        return controller
39    }()
40}

Concluding Thoughts

I know I keep going back to it, but I think it’s what will help make the decision.

What’s the next thing you’re expecting to happen after you fetch the objects and display them?

Let that be your guiding principle for your fetching and displaying strategy.

With Core Data, it’s almost always going to be more convenient to be working with NSManagedObjects. Start there, and handle efficiency problems as they arise. 🙌🏻

Getting Started With NSPersistentCloudKitContainer

Tue, 11 Jun 2019 04:40:54 +0000

First Things First

In order to use NSPersistentCloudKitContainer in your app, you need to be targeting iOS 13+.
The CloudKit syncing portion only works on physical devices (not in the simulator). That being the case, you’ll need two or more devices running the app and using the same iCloud account to fully test things out and make sure syncing and data merging behavior works as you’d expect it to.

The goal of this walkthrough is to provide you with a fully-working example of performing and synchronizing create, read, update, and delete operations using NSPersistentCloudKitContainer.

It’s the project I wish I had for referencing the basics…something beyond the out-of-the-box, saving a list of timestamps that comes pre-implemented with a Master-Detail app, but something less complicated than Apple’s example project which ends up having several relationships involved in the data model, extra features configured on the persistent container, etc.

I offer it to you as reference as well – I hope it helps!

Resources

Setup

The easiest way to get stareted with NSPersistentCloudKitContainer is to enable Core Data and CloudKit when you start your new project.

The Core Data + CloudKit Stack

Xcode provides the Core Data Stack code you need in the usual location: in the AppDelegate.swift file.

There’s one notable difference though. Instead of initializing a normal NSPersistentContainer, Xcode uses the new NSPersistentCloudKitContainer (this is why it’s important to check the CloudKit box when you create your app).

What About Existing Apps?

If you’ve got an existing app that’s using a “regular” NSPersistentContainer, you can change it to NSPersistentCloudKitContainer and continue on from there!

If you’re not using NSPersistentContainer with your app yet, my guide on how to migrate may be of help!

Adding Capabilities

While Xcode auto-generates the Core Data + CloudKit stack for you, it does not enable iCloud for you.

To enable full functionality, you need to go to your Xcode project settings.

Then click on the Signing & Capabilities section and add the iCloud and Background Modes capabilities.

Check the CloudKit checkbox, and the Remote Notifications checkbox.

Add iCloud + CloudKit

Add Background Modes + Remote Notifications

What About Registering for Remote Notifications?

The beauty of NSPersistentCloudKitContainer is that it handles all the work required to listen for and respond to remote notifications.

This means that data saved locally on one device gets pushed up to iCloud synced back down to another device automatically.

What About My Data Model in iCloud?

When you enable the iCloud capability for your app, Xcode automatically creates a container for your app in the CloudKit Dashboard.

It does not, however, create a schema that matches your Core Data model…yet. This is a setting you can toggle, but the default behavior is to “lazily” create the schema as people create objects and save them to your persistent store.

Walking Through the Example Project

WWDC always gets the blog ideas flowing through my brain, so this little app’s theme is “saving a list of blog ideas”, both locally, and across my devices using NSPersistentCloudKitContainer.

User Interface

The user interfacde allows you to perform the essential operations of a data-driven app: create, read, update, and delete objects.

Data Model

The data model for this is basic: a single BlogIdea Entity with two String properties: ideaTitle and ideaDescription.

No relationships or extra configuration options… just one Entity to keep it a basic reference-able project.

The BlogIdea NSManagedObject subclass is implemented like this:

public class BlogIdea: NSManagedObject {

    @NSManaged public var ideaTitle: String?
    @NSManaged public var ideaDescription: String?

    static var entityName: String { return "BlogIdea" }
}

View Controllers

There are two view controllers that come with this example:

MainViewController

class MainViewController:   UIViewController, 
                            NSFetchedResultsControllerDelegate, 
                            UITableViewDataSource, 
                            UITableViewDelegate {
    // Responsible for listing out BlogIdeas in a table view

    // Holds a reference to an NSManagedObjectContext instance
    // which gets initialized in the SceneDelegate.swift file
    // and passed to this view controller when the scene gets "connected"

    // Uses NSFetchedResultsController to keep the table view in sync
    // with the Core Data managed object context

    // Implements swipe-to-delete with delete confirmation

    // Navigates to editor when someone taps on a table view row
    // and passes its NSManagedObjectContext instance along
}

BlogIdeaEditorViewController

class BlogIdeaEditorViewController: UIViewController {
    // Responsible for creating new BlogIdeas

    // Holds a reference to an NSManagedObjectContext instance
    // which gets passed along in MainViewController's prepare for segue method

    // Able to edit existing BlogIdeas
}

Understanding the Default Sync Behavior

At this point no additional configuration has happened. The Core Data stack is the unmodified Xcode generated code, and the fetched results controller is hooked up to the managed object context for your app, ready to fetch Blog Ideas and help get them into the table view.

If you open the project, build and run on two devices, and begin adding Blog Ideas, updating them, deleting them, etc. what happens?

The first observation is that…things…don’t…seem to be working…

…At least not how I thought they would.

I expected my Blog List view to automatically update in response to changes made on my other device, buuut… nope. Thankfully it’s an “easy” fix.

Reflecting Changes in the UI

Wherever you access your app’s persistent CloudKit container to grab the viewContext, you need to set the automaticallyMergesChangesFromParent property to true.

I initialize the container in the SceneDelegate, so check out the code exerpt below to see where that gets set.

SceneDelegate.swift

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    // Use this method to optionally configure and attach the UIWindow `window` to the provided UIWindowScene `scene`.
    // If using a storyboard, the `window` property will automatically be initialized and attached to the scene.
    // This delegate does not imply the connecting scene or session are new (see `application:configurationForConnectingSceneSession` instead).
    guard let _ = (scene as? UIWindowScene) else { return }
    
    let navigationController = self.window?.rootViewController as! UINavigationController
    let mainVC = navigationController.viewControllers[0] as! MainViewController
    
    let viewContext = (UIApplication.shared.delegate as! AppDelegate).persistentContainer.viewContext
    viewContext.automaticallyMergesChangesFromParent = true

    mainVC.managedObjectContext = viewContext
}

Making this one-line change will enable the app (which is supported by NSFetchedResultsController) to update the UI in response to remote data changes…

eventually

It can be slow (anywhere from 5 to 15 seconds). But it will eventually update.

Revisiting the iCloud Schema

Once you save an object, the schema within the iCloud Dashboard will update to reflect the properties you designed in your Core Data Model.

Where’s My Data?

If you attempt to query for BlogIdea records in any of the iCloud databases provisioned for your app, you won’t find any.

Why?

That’s because Apple fully manages a hidden Zone for your Core Data + CloudKit data. It was veeeery briefly mentioned in the WWDC 2019 presentation (right about 10:50 if you’re watching).

Wrapping Up

My hope was to provide you with a fully-working example of performing and synchronizing create, read, update, and delete operations using NSPersistentCloudKitContainer.

Check out the GitHub repo, leave a comment, or @ me on Twitter to continue the conversation from here!

First Impressions of NSPersistentCloudKitContainer

Thu, 06 Jun 2019 04:40:54 +0000

Resources

How NSPersistentCloudKitContainer Helps

I suppose the first question everyone should ask is, “What’s the big deal? How does NSPersistentCloudKitContainer even help me?”

I noted at least three huge wins from the WWDC 2019 session. Ask yourself…

“Do I want to figure out how to retrieve data from CloudKit and merge it with my local Core Data persistent store on my own?” – No? Me either. 😃

NSPersistentCloudKitContainer handles making a local replica of your app’s CloudKit data.

“Do I want to implement synchronization schedluing and all the error handling that comes with CloudKit?” – I definitely don’t…

NSPersistentCloudKitContainer handles scheduling CloudKit operations, and takes your // handle errors placeholder code (👀) and actually implements it the right way internally. #sweet

“Do I want to map between NSManagedObjects and CKRecords by hand?” – Not if that could be automagic!

NSPersistentCloudKitContainer handles transforming your NSManagedObjects into CKRecords as well.

Exciting Times

Apple did a lot of work to encapsulate a very common set of code patterns that were necessary for implementing an app with Core Data and CloudKit.

They claim to be able to save us thousands of lines of code (and I believe it!).

I have an app that uses Core Data locally. I’ve been wanting to enable CloudKit on, so that data is synced across my users’ devices. Every time I think about what it’ll take to get the Core Data pieces talking the on the same wavelength as the CloudKit pieces, I just dread the inevitable headache that would ensue. So I run away. 😬

My hope is to see what it’s like to enable NSPersistentCloudKitContainer with that existing app. I’ll be sure to document the journey!

Dipping a Toe In

Just a couple of tidbits about the setup process for getting started with this new class…

Enabling Core Data + CloudKit

While it’s not absolutely required to check these checkboxes, Xcode will provide you with some of the boilerplate code necessary for working with Core Data and CloudKit together.

Starting Point

Xcode generates some code in your AppDelegate.swift file to initialize the Core Data Stack, only this time, instead of a standard NSPersistentContainer, it initializes the new NSPersistentCloudKitContainer:

 1lazy var persistentContainer: NSPersistentCloudKitContainer = {
 2        let container = NSPersistentCloudKitContainer(name: "NSPersistentCloudKitContainer_First_Steps")
 3        container.loadPersistentStores(completionHandler: { (storeDescription, error) in
 4            if let error = error as NSError? {
 5                // Replace this implementation with code to handle the error appropriately.
 6                fatalError("Unresolved error \(error), \(error.userInfo)")
 7            }
 8        })
 9        return container
10    }()

Not Ready Yet (more to enable)

Enable CloudKit Capability

Since you’re working with CloudKit in this scenario, you still need to enable CloudKit so that your app has the appropriate entitlements, and so that your app’s CloudKit container gets created in iCloud.

Enable Remote Notifications

CloudKit also uses Push Notifications to alert your app to data changes coming in from other devices. To get these notifications, you need to enable the Remote Notifications capability for your app as well.

Next Steps

When it comes to learning what to do next, Apple has provided a sample project that I hope to examine and take apart.

More to come!

Resolving Failed to Load Model Named... with Core Data

Thu, 06 Jun 2019 04:40:54 +0000

You’ve done the work to get your Core Data model ready, but right when you hit run, wham. Your debug output log shows:

Failed to load model named ModelName

You you may experience one of these when you attempt to access your persistent container:

Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value

What in the world is going on?

Double-check Target Membership

This is particularly important if you happend to have copied and pasted and .xcdatamodeld file between projects.

Double-check Model Name

Your model name needs to match throughout the various places you refer to it. Things can get out of sync if you ever rename your model.

Check to make sure that the following all match:

YourModelName.xcdatamodeld
let container = NSPersistentContainer(name: “YourModelName”)