Core Data on Andrew Bancroft

How to Use @FetchRequest in SwiftUI

Sat, 03 Aug 2019 03:11:48 +0000

Once you’ve passed an NSManagedObjectContext instance to your SwiftUI View, you’ll need to pull data out of your Core Data persistent store with a fetch request.

First Things First

The remainder of this how-to assumes that you’ve already got a way to initialize the Core Data stack. Ticking the ‘Use Core Data’ checkbox when you start a new app will place some boilerplate code in AppDelegate.
@Environment(\.managedobjectcontext) must be assigned before the View is initialized for @FetchRequest to work.
Code examples are taken from my “Blog Idea List” sample project that includes a single Core Data Entity named BlogIdea:

Resources

Blog Idea List SwiftUI Example Xcode Project

You can refer to my introduction to using Core Data with SwiftUI to review all of the steps in one spot. It includes an example project with all of the pieces stitched together!

Breaking Down the Code

There are three key components to this:

A way to configure an NSFetchRequest with an NSSortDescriptor added. Your app will blow up 💥 if you don’t have one added to your fetch request.
The @FetchRequest property wrapper in your SwiftUI view.
A SwiftUI View that displays the results of the executed fetch request.

The following code snippets provide you an example of how to weave all three components together.

Comments with ❇️ symbols will explain the details inline.

BlogIdea.swift

import Foundation
import CoreData

// ❇️ BlogIdea code generation is turned OFF in the xcdatamodeld file
public class BlogIdea: NSManagedObject, Identifiable {
    @NSManaged public var ideaTitle: String?
    @NSManaged public var ideaDescription: String?
}

extension BlogIdea {
    // ❇️ The @FetchRequest property wrapper in the ContentView will call this function
    static func allIdeasFetchRequest() -> NSFetchRequest<BlogIdea> {
        let request: NSFetchRequest<BlogIdea> = BlogIdea.fetchRequest() as! NSFetchRequest<BlogIdea>
        
        // ❇️ The @FetchRequest property wrapper in the ContentView requires a sort descriptor
        request.sortDescriptors = [NSSortDescriptor(key: "ideaTitle", ascending: true)]
          
        return request
    }
}

ContentView.swift

import SwiftUI

struct SwiftUIView: View {
    // ❇️ The BlogIdea class has an `allIdeasFetchRequest` static function that can be used here
    @FetchRequest(fetchRequest: BlogIdea.allIdeasFetchRequest()) var blogIdeas: FetchedResults<BlogIdea>

    var body: some View {
        List(self.blogIdeas) { blogIdea in
            Text(blogIdea.ideaTitle ?? "")
        }
    }
}

Note that you don’t actually need to hold a reference to the @Environment’s managedObjectContext.

@Environment’s managedObjectContext must be set! But you don’t have to “call” it or use it directly to make the fetch request “go”.

Where’s the Call to Perform the Fetch Request?

With most Core Data apps, you’re going to see a call to fetch(_:) somewhere in your code.

This happens “behind the scenes” when you use the @FetchRequest property wrapper in your SwiftUI view. No need to use your managed object context to perform the fetch request manually.

For a more complete guide to using Core Data with SwiftUI, you can refer to the introduction I published. It includes an example project with all of the pieces stitched together!

How to Pass NSManagedObjectContext to a SwiftUI View

Fri, 02 Aug 2019 03:11:48 +0000

Step one to using Core Data with SwiftUI is to initialize the Core Data stack and pass an instance of your NSManagedObjectContext to your view.

First Things First

The remainder of this how-to assumes that you’ve already got a way to initialize the Core Data stack. Ticking the ‘Use Core Data’ checkbox when you start a new app will place some boilerplate code in AppDelegate.
Code examples are taken from my “Blog Idea List” sample project that includes a single Core Data Entity named BlogIdea:

Resources

Blog Idea List SwiftUI Example Xcode Project

You can refer to my introduction to using Core Data with SwiftUI to review all of the steps in one spot. It includes an example project with all of the pieces stitched together!

Breaking Down the Code

There are two key components to this:

the Core Data Stack
the SwiftUI @Environment’s managedObjectContext variable.

“Passing in” your managed object context will probably happen early on in your app’s launch sequence. SceneDelegate is where I pass mine in with the Blog Idea List app.

On the receiving end is your SwiftUI View. An @Environment property wrapper needs to be set up in order to pull out the managed object context so you can use it.

The following code snippets provide you glimpses into both sides of the coin. Comments with ❇️ symbols will explain the details inline.

SceneDelegate.swift

 2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22

                     

class="lnt"> 1 language-swift" data-lang="swift">func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { if let windowScene = scene as? UIWindowScene { let window = UIWindow(windowScene: windowScene)

// ❇️ Get the managedObjectContext from the persistent container // ❇️ This assumes you've left the Core Data stack creation code within AppDelegate let managedObjectContext = (UIApplication.shared.delegate as! AppDelegate).persistentContainer.viewContext

// ❇️ Pass it to the ContentView through the  // ❇️ managedObjectContext @Environment variable let contentView = ContentView() .environment(\.managedObjectContext, managedObjectContext)

window.rootViewController = UIHostingController(rootView: contentView)

self.window = window window.makeKeyAndVisible() } class="p">}

ContentView.swift

import SwiftUI

struct SwiftUIView: View {
    // ❇️ Access the @Environment's managedObjectContext variable
    // ❇️ and keep a reference to use later
    @Environment(\.managedObjectContext) var managedObjectContext

    var body: some View {
        // ❇️ Use self.managedObjectContext however you need within your SwiftUI view!
    }
}

For a more complete guide to using Core Data with SwiftUI, you can refer to the introduction I published. It includes an example project with all of the pieces stitched together!

iOS Data Persistence: The Big Picture

Tue, 30 Apr 2019 10:03:33 +0000

We’ve all been there. Do a search on the topic of “saving data in iOS” and you’ll get dozens of search results mentioning at least six different frameworks and platforms, and a month’s worth of reading.

Wouldn’t it be nice to distill the possibilities down into just what you need in order to start down a path for persisting data in your app?

“iOS Data Persistence: The Big Picture” will be worth the hour of your time.

Resources

iOS Data Persistence: The Big Picture

Course Outline

During this one hour course, you will learn the reasons for saving data to help ground you as you begin to traverse the data persistence landscape.

You will discover how to use technologies like User Defaults and Property Lists, and I will guide you on how to work with Swift’s Encodable and Decodable protocols.

You will understand what you’re getting into if you choose to work with SQLite, Core Data, or Realm Database for local data persistence.

You will know how it feels to reach for a remote data storage option like CloudKit, Realm Platform, or Firebase.

Finally, you will see a clear picture of what it’s like to design a document-based application and integrate your app’s data with the iOS Files app.

When you’re finished with this course, you will have the skills and knowledge you need to make an informed decision about putting a reliable data storage plan for your iOS app into action.

1 – Establishing the Data Persistence Landscape

During the course, you will have the opportunity to experience a variety of data persistence scenarios and technologies.

You’ll get general feel for setup requirements and a taste of what it’s like to work with each solution in code.

To start you off on the right footing, this module will establish the data persistence possibilities and focus in on the reasons for saving data so that you’re persisting with a purpose.
You will be introduced to a player profile matrix to help you analyze your data persistence options from a number of angles.
Finally, you will get the feel for working with the Swift Encodable and Decodable protocols.

2 – Saving Settings and Configuration

Users are picky, aren’t they? Everybody has preferences though, so it’s no wonder that you as a developer are often tasked with letting your users to customize their experience within your app.

You will learn how to manage user preferences with the UserDefaults system that’s built in to iOS
Next, you will explore synchronizing settings with iCloud Key-Value Store
Finally, you will understand how to ship configuration for your app with Property Lists that are included in your application bundle

4 – Saving Objects and Object Graphs

What if you only wanted to load a subset of the data into memory instead of being locked in to an all-or-nothing situation with UserDefaults or Property Lists?

What if you needed to save a more complex data model that includes relationships?

For that, you’ll need to know about saving and sharing objects and object graphs…

Six Technologies/Frameworks will be featured in this module:

SQLite
Core Data
Realm Database
CloudKit
Realm Platform
Firebase

The goal is to help you answer two questions:

“What am I getting myself into if I pick one persistence technology over another?”
“How does it feel to work with this persistence technology in code?”

You will answer these questions by…

Scanning the arena of persistence options and explore what sets these technologies apart from UserDefaults and Property Lists.
Surveying the setup process to see what it takes to get up and running with each technology in the list
Exploring the data modeling process to wrap your head around what the data structure design process is like for each technology in the list
Getting the feel for working with data so that you understand what it’s like to create objects, update them, delete them, query and filter them, and watch for data changes so that you can update your user interface appropriately

5 – Saving Data as Documents and Files

What if you need to encapsulate chunks of content together and save it all as a packaged up file…as a single unit with a custom file extension?

For that, you need to know about saving data as documents and files.

You will explore the use-case for building a “document-based application”
Next you will walk through designing a document as a subclass of UIDocument
You will learn to create and load documents from a Document Browser
Customizing your app’s file extension is a key step that you will work through
You will spend some time understanding how to interact with document data in code as users interact with the user interface
Finally, you will answer the question, “How do I get my app’s files to show up in the iOS Files app?”

Feedback Welcome!

My goal is to help you filter the noise… to help you distill an overwhelming amount of information down into the big picture possibilities so that you’re on a trajectory for being able to make an informed decision about putting a reliable data storage plan for your iOS app into action.

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

Do Core Data Entities Need Primary Keys?

Fri, 10 Aug 2018 22:31:47 +0000

In this video I pop the hood on Core Data’s SQLite persistent store to discover the details about whether or not you need to add a property representing a “primary key” for your Core Data Entities. Take a look and be sure to subscribe for to stay connected to future screen casts!

Transcript

I had a question asked to me recently to the effect of… “Do I need to create a Primary Key property when I model my Core Data Entities?”

I’m going to tackle answering this one with an Xcode sample project I built a while back and put out on GitHub…

If you go to https://github.com/andrewcbancroft/Zootastic, you’ll be able to clone the repository and follow along with me if you’d like.

This repo is Zoo-themed … don’t judge -haha My kids love animals so I couldn’t help myself…

The Core Data model for this project looks like this. I’m going to focus in on just one of those entities in this video…namely, the Zoo entity.

With that context in mind, let’s think about primary keys… Do you need them when you’re modeling Entities in a Core Data project?

Let’s consider what primary keys are for, first of all. Essentially what you’re after when you specify a Primary Key in a relational database is a guarantee of the uniqueness of a row in a table…

You want to make sure that a given representation…a given instance…one row of an Entity can be uniquely identified, and that’s typically done by adding an ID column with a sequential, unrepeated integer value called a Primary Key.

That way even though two rows may have similar information, such as these two zoos with the same name, you can always represent the City Zoo in Denver Colorado with the unique ID of 1, and the City Zoo in Oklahoma City, OK with the ID of 3.

Suppose our data model has this Zoo entity with two properties: Location and Name…

The question at hand is… Do you add this ZooID property? Or not?

By far the most common use-case with apps using Core Data is to use the NSSQLiteStoreType as the underlying persistent store.

What this means is that Core Data acts as an abstraction layer over the underlying persistent store, which happens to be a SQLite relational database under the hood.

When you create Entities with Attributes in your core data model, those turn into Tables with Columns in the SQLite database.

What I want to do right now is show you what happens when your data model is initialized in an app using Core Data with a SQLite persistent store, and what you’re going to discover is that Core Data’s got your back when it comes to Primary Keys.

Watch this…

I’m going to edit the scheme of the Zootastic app to show you how to get a little bit of extra debug information related to the SQL queries that are being run under the hood as Core Data interacts with your persistent store.

Under Run, you can add an argument that’s passed when the app is launched to get this extra debug information. Use the -com.apple.CoreData.SQLDebug switch and pass 1 as the argument.

Running the app loads a ton of text into the debug console’s output, but what I’m interested in showing you is right up here at the top.

Do you see this right here? Core Data sends a CREATE TABLE statement to the SQLite database engine, and within the columns it creates is this Z_PK integer column as a… Primary Key.

But I haven’t listed a PK property in my Entity!

Seeing the fact that even though I don’t put in a special primary key property, Core Data still creates that column in the SQLite database, I think you can answer the question on your own.

My answer would be, “No… you don’t need to specify a special ID property to serve as your entity’s Primary Key because Core Data knows this internally and creates one automatically.”

Now just in case you’re skeptical and don’t believe that the column is actually IN the database, I want to show you explicitly.

At the top of this debug output, do you see this? it’s a path to the sqlite database file that the app is using. I’m going to copy it and jump over to a terminal session.

cd to that directory and list its contents.

Zootastic.sqlite is what I want to peek into, so I’ll run sqlite3 with that file specified.

If you run .table, sqlite will list out all the tables in this database file.

Running .schema on ZZOO shows you that yes indeed the primary key column is present in the database table that holds the Zoos for the app.

Selecting all columns from the ZZOO table shows that it’s populated with integer values as you’d expect.

Bottom line? You don’t need to explicitly create an ID column to serve as a primary key. Core Data takes care of that for you.

If you’re learning Core Data, you might enjoy my Core Data Fundamentals with Swift course on Pluralsight. I cover the essentials to get you up and running with Core Data in your apps developed for Apple’s platforms.

Thank you for watching!

Using an Existing SQLite Store with NSPersistentContainer

Mon, 10 Jul 2017 18:02:05 +0000

If you’ve been creating the Core Data Stack without NSPersistentContainer and you’re thinking about switching things up to use NSPersistentContainer, you need to think about your existing SQLite persistent store.

Creating the stack with NSPersistentContainer handles the creation of SQLite stores internally, so brand new setups using NSPersistentContainer are pretty easy.

But how do you go about telling NSPersistentContainer about your existing SQLite store?

Let’s take a look now at how you can configure the container to use your previously-created persistent store.

Before NSPersistentContainer

Supposing that your previous Core Data stack creation step pointed to a .sqlite file somewhere in your user’s documents directory:

1// Configure NSPersistentStoreCoordinator with an NSPersistentStore
2let psc = NSPersistentStoreCoordinator(managedObjectModel: model) // model instance creation not shown here...
3
4let storeURL = try! FileManager
5        .default
6        .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
7        .appendingPathComponent("NameOfDataModel.sqlite")
8
9try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: nil)

After NSPersistentContainer

The key to migrating to NSPersistentStore with an existing SQLite persistent store is the NSPersistentStoreDescription class. Take a look at the following code to see how to configure an instance of NSPersistentStoreDescription and assign it to the NSPersistentContainer instance’s persistentStoreDescriptions property:

 1let container = NSPersistentContainer(name: "NameOfDataModel")
 2
 3let storeURL = try! FileManager
 4        .default
 5        .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
 6        .appendingPathComponent("NameOfDataModel.sqlite")
 7
 8let storeDescription = NSPersistentStoreDescription(url: storeURL)
 9container.persistentStoreDescriptions = [storeDescription]
10
11// Remaining setup for NSPersistentContainer

Breaking it down

The let storeURL = portion of the code is identical in both snippets.

The difference is how you tell the Stack where the persistent store is located. In times past, you’d tell the NSPersistentStoreCoordinator this information through its addPersistentStore method.

With NSPersistentContainer, you need to do two things:
1 – Initialize an NSPersistentStoreDescription instance with the storeURL (i.e. the URL to where your existing persistent store is located).

2 – Assign the NSPersistentStoreDescription instance to the NSPersistentContainer's persistentStoreDescriptions property.

One subtlety to note is that the property’s name is plural: persistentStoreDescriptions.

Even though may only a single persistent store description instance to assign, such as in the example code above, you still need to wrap it in an array before you assign it, since it’s possible to add more than one description to the container.

With that adjustment to the NSPersistentContainer stack creation process, your app will once again use the persistent store it used to use!

You might also enjoy…

Creating the Core Data Stack with Backwards Compatibility in Swift

Core Data Cheat Sheet for Swift iOS Developers

Resources

Core Data Fundamentals with Swift

A Swift Implementation of the Core Data Stack Using NSPersistentContainer

Mon, 15 May 2017 18:19:46 +0000

If you’re targeting iOS 10 and above, you’ve got the opportunity to pick your poison when it comes to creating the Core Data stack.

You could opt for the process I described in Creating the Core Data Stack with Backwards Compatibility in Swift — that process still works perfectly fine in iOS 10+.

Alternatively, you could use the new NSPersistentContainer class if you want to write a few less lines of code and keep up-to-date with the latest framework enhancements!

What’s the point of the “Core Data stack”?

It’s important to keep in mind the fundamental goal with creating the “Core Data stack”. At the end of the day, we’re all just trying to get our hands on an instance of NSManagedObjectContext.

Nearly every Core Data framework Type that we interact with requires an instance of NSManagedObjectContext to do its work. Whether it’s NSEntityDescription to initialize new NSManagedObject instances, an NSFetchRequest to retrieve data, or an NSFetchedResultsController to keep our UIs in sync, we’re always depending on NSManagedObjectContext.

So the bottom-line goal of setting up the “stack” is to configure all the plumbing necessary for our apps to work with the “under the hood” stuff of Core Data. The thing we interact with constantly is that all-valuable NSManagedObjectContext instance.

Creating the stack with NSPersistentContainer

NSPersistentContainer saves a few keystrokes and abstracts away a few of the moving parts when it comes to setting up the Core Data stack. Compare my Backwards Compatibility post if you’re curious about what’s being simplified.

So… how’s it done?

First: Make sure you’re targeting iOS 10+, macOS Sierra (10.12)+, watchOS 3+, or tvOS 10+

NSPersistentContainer is only available in Apple’s latest platform versions (latest as of May, 2017).

Once you’ve ticked the build target prerequisite above, check out this code example:

//Step 1
let container = NSPersistentContainer(name: "NameOfModel")

// Step 2
// Happens asynchronously!
container.loadPersistentStores(completionHandler: {
    persistentStoreDescription, error in
    // Step 3
    guard error == nil else { fatalError("Failed to load store: \(error)") }

    let mainContext = container.viewContext
    // Use the context to do Core Data stuff in your app
})

Step-by-step through the code

Using NSPersistentContainer can be seen as a 3 step process.

1 – Initialize an NSPersistentContainer instance. Its only parameter is the name of the model (look at your .xcdatamodeld file for this)
2 – Call loadPersistentStores on the container instance. This function executes asynchronously, so to hook back in and continue doing things when the function is finished with its work, you supply a completionHandler.
3 – Guard against errors and use the container’s viewContext property, which is the NSManagedObjectContext instance you need. I haven’t written in detail about this (yet), but in my Pluralsight course on Core Data in Swift, I go over how to take the managed object context and follow a dependency injection pattern so that you isolate where it’s created, and use the single instance throughout your app in a way that’s testable.

One consideration that I would encourage you to think about is the guard statement. Ask: “Is fatalError really the best thing for me to do?”

A lot of apps that use Core Data really can’t continue past this point if the persistent store can’t be loaded. In that case, the guard may not be so bad. If you can fall back to an alternate screen that doesn’t rely on Core Data though, that might be a more pleasant experience for your users than simply crashing with a fatal error.

Wrap up

This is the simplest way to use NSPersistentContainer to create your Core Data stack, and that’s where I want to leave it for today!

Thank you, as always, for your interest in the content I’m creating!

And yes, if you’re learning Core Data, I would love to contribute to your understanding of the framework. That’s why I built Core Data Fundamentals with Swift for Pluralsight! If you’re a subscriber, I’d be thrilled to engage with you on the course!

Core Data Model Attributes and NSManagedObject Property Types Must Match!

Sun, 23 Apr 2017 20:03:34 +0000

I admit – it might have taken me less time to figure out my runtime exception if I hadn’t just migrated my project to Swift 3 when I encountered the bug.

That’s the problem isn’t it? You go in… you intend to do one thing. Before long, you’ve got 15 files with an M out to the right. The project builds (finally), but ah – then there’s runtime.

When the crash occurs, you’re never sure if it was an existing problem, or if it was caused by the code conversion. Who knows – maybe it’s both?

Perhaps this is a story more about code conversion than it is about Core Data. In any case, perhaps it’ll help a poor soul struggling to figure out why just happened.

Data model Attributes and NSManagedObject property types – Match ’em!

Whenever you’re creating a subclass of NSManagedObject for the Entities in your data model, you’re in a mapping process.

Each Attribute on an Entity maps over to a property on the NSManagedObjectSubclass.

Not only must the names of those Attributes and properties match, but the Types of each must match as well.

Optionals are Types

String isn’t the same as String?.

Date isn’t the same as Date?.

They’re different Types.

So what happens if you specify that a certain Attribute named, say, createdOn is a Date with the Optional checkbox checked in the data model designer like this:

And over in the implementation of your NSManagedObject subclass, you have code that’s written like this:

`1`	`@NSManaged var createdOn: Date //instead of Date? (ie, the ? is missing)`

What’ll happen? Well, I can tell you what’ll happen. :]

When you run the app and attempt to load objects from your persistent store that have been saved with nil for the createdOn value, your app will blow up:

Xcode isn’t entirely unhelpful. While the EXC_BAD_INSTRUCTION message in the text editor isn’t very illuminating, the Debug Navigator on the left () provides some clues.

For me, it displayed just the breadcrumb that made me go, “Oh! Let me go check and see if I’ve got a Type mis-match between my data model and my NSManagedObject subclass”:

Interesting… It looks like there was an attempt to go from an NSDate? (optional) instance to a Date (non-optional).

The issue isn’t that I’ve got a mismatch between NSDate and Date. The runtime can swap those around and substitute them easily.

Rather, it’s that I’m trying to go from optional, where nil is fine, to non-optional, where nil…well…crashes things.

Lessons learned

What have I learned?

1 – Map Attributes to NSManagedObject subclass properties carefully.
2 – Don’t accidentally miss a ? to indicate that a property is optional if I’ve got it marked as optional in the data model
3 – Read the Debug Navigator. It’s not just a list of gibberish – it can actually provide helpful clues so you know where to go look to solve your problem!

Resources

Core Data Fundamentals with Swift

Creating the Core Data Stack with Backwards Compatibility in Swift

Sun, 16 Apr 2017 21:23:46 +0000

In 2017, we live in a world where there are still non-iOS 10 devices out in the wild. If your app is targeting an iOS version earlier than iOS 10, or macOS Sierra (10.12), you’ll be unable to take advantage of Core Data’s latest “stack creation” class called NSPersistentContainer. So what can you do?

While NSPersistentContainer does aim to simplify the stack creation process, at the end of the day, it’s not terrible to have to mess with some of this Core Data plumbing.

End goal of creating the Core Data stack

The end goal of Creating the Core Data stack is to get an instance of NSManagedObjectContext. That’s it.

Most apps that rely on Core Data will end up making fetch requests to obtain data, or wire up other classes like NSFetchedResultsController. To make these things work, you’ve got to provide an instance of NSManagedObjectContext.

NSManagedObjectContext is sort of that central gear in the whole system that makes the other gears turn.

So. Bottom line: Once you have an instance of NSManagedObjectContext, you’re golden. That’s what creating the Core Data stack gives you in the end.

3 steps to creating the Core Data stack

The Core Data stack can be created in about 3 steps:

1) Initialize an instance of NSManagedObjectModel

This corresponds to your .xcdatamodeld file. You’ll want to glance over to the project navigator on the left and locate the .xcdatamodeld file to record its name for this step.

1
2
3

// Initialize NSManagedObjectModel
let modelURL = Bundle.main.url(forResource: "NameOfDataModel", withExtension: "momd")
guard let model = NSManagedObjectModel(contentsOf: modelURL!) else { fatalError("model not found") }

2) Initialize and configure an instance of NSPersistentStoreCoordinator with the NSManagedObjectModel instance and an NSPersistentStoreType

The reason you create the NSManagedObjectModel instance first is because the next step depends on it. NSPersistentStoreCoordinator will use your NSManagedObjectModel instance to configure itself and prepare to create the correct kind of persistent store based on what NSPersistentStoreType you tell it to use.

In the code example that follows, I used NSSQLiteStoreType to create a SQLite persistent store. Regardless of what kind of persistent store you use though, NSPersistentStoreCoordinator needs your managed object model instance.

// Configure NSPersistentStoreCoordinator with an NSPersistentStore
let psc = NSPersistentStoreCoordinator(managedObjectModel: model)

let storeURL = try! FileManager
        .default
        .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
        .appendingPathComponent("NameOfDataModel.sqlite")

try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: nil)

3) Initialize an instance of NSManagedObjectcontext and assign it the NSPersistentStoreCoordinator instance

The last step is to initialize an instance of NSManagedObjectContext and assign it the NSPersistentStoreCoordinator instance.

1
2
3

// Create and return NSManagedObjectContext
let context = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)
context.persistentStoreCoordinator = psc

Putting it all together – creating the Core Data stack in code

When I create the Core Data stack, I like to encapsulate the code in a stand-alone function that returns an instance of NSManagedObjectContext.

Here are all three steps put together:

func createMainContext() -> NSManagedObjectContext {
    
    // Initialize NSManagedObjectModel
    let modelURL = Bundle.main.url(forResource: "NameOfDataModel", withExtension: "momd")
    guard let model = NSManagedObjectModel(contentsOf: modelURL!) else { fatalError("model not found") }
    
    // Configure NSPersistentStoreCoordinator with an NSPersistentStore
    let psc = NSPersistentStoreCoordinator(managedObjectModel: model)

    let storeURL = try! FileManager
            .default
            .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
            .appendingPathComponent("NameOfDataModel.sqlite")
    
    try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: nil)
    
    // Create and return NSManagedObjectContext
    let context = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)
    context.persistentStoreCoordinator = psc
    
    return context
}

Once you’ve got a function like createMainContext(), you’ll be able to call it to obtain a fully-configured NSManagedObjectContext instance.

I highly recommend you avoid calling it inside any of your view controllers. Instead, my recommendation is to call it to obtain your NSManagedObjectContext instance inside of the AppDelegate's application(_:didFinishLaunchingWithOptions:) function. From there, you can pass it to your first view controller, and from that first view controller on to other view controllers that need it through prepare(for segue:sender:).

For more on this “dependency injection” strategy, or if you’re more of a visual learner, check out my Pluralsight course, Core Data Fundamentals with Swift!

Resources

Core Data Fundamentals with Swift

You might also enjoy…

Core Data Fundamentals with Swift

Sun, 02 Apr 2017 22:04:02 +0000

Core Data is an extremely powerful framework for managing and persisting data on your users’ devices. And let’s face it: saving data to your users’ devices is inevitable. The question is, which data management and persistence technology you use when the time comes for you to tackle this challenge?

“Core Data Fundamentals with Swift” will give you the essential skills you need to architect an app to use Core Data.

Course Trailer

You can check out a trailer of the course over at Pluralsight completely free.

Resources

Core Data Fundamentals with Swift

Topics

1 – Getting Started with Core Data

Module 1 is the introduction to the course with discussion of the motivating factors for using Core Data, course prerequisites, storyline overview, and a demo of the end product of the course.

I had a blast making the demo app. Essentially, I put you in the scenario where we team up to build a prototype of an app that our Human Resources department has come to us with. They came to us with an idea – Over the past year or two, they’ve noticed that employee morale is down a bit. To improve the situation, they’re implementing a new Employee Recognition program. As part of the new program, they’ve come to our internal software development team to see if it might be possible to build some kind of an app that allows employees to recognize one another for jobs well-done – electronic “Shout Outs” if you will.

And that’s where you and I come in – HR wants us to prototype something up so that they have an idea of what’s possible.

Throughout the course, we work on this prototype app together!

2 -Setting up the Core Data Stack

Working with Core Data begins with setting up the Core Data Stack. You will learn how to implement the stack, how to architect your app for testability and maintenance, and how to share Core Data components (such as NSManagedObjectContext) between view controllers.

3 – Creating a Data Model

Building a data model is the foundation for persisting information with Core Data. You will learn to create a data model in Xcode, and you will understand how to work with that model in Swift code.

4 – Building Relationships Between Entities

Understanding the importance of relationships and how to build them is vital to the efficiency and expressiveness of your Core Data model. You will learn why building relationships is worth the investment, and then you will gain the skills you need to be able to build these strategic links between Entities in Xcode.

5 – Saving, Accessing, and Deleting Data

Having the ability to save data to a Core Data persistent store is essential. Being able to retrieve that data later on for display, for modification, or even for removal from the persistent store is also a critical. You will learn the mechanics of how to use the Core Data framework classes that are involved with saving, accessing, and deleting data in this module.

6 – Showing and Synchronizing Data with NSFetchedResultsController

Displaying data in a user interface and keeping it synchronized with the state of the persistent store is a critical piece of the Core Data puzzle. You will learn how to use NSFetchedResultsController for keeping table views in sync. You will also examine using the iOS Notification Center as an alternative way to detect and respond to changes in the persistent store.

7 – Changing Core Data Models

It’s inevitable: You’re going to have to change your data model from its original form sooner or later. This module will guide you in creating new versions of your data model. You will also learn how to migrate your persistent store to new data model versions so that no data is lost as you make changes.

8 – Understanding Core Data Changes in iOS 10 and macOS Sierra

Change is constant. Be prepared for the latest enhancements to the Core Data framework by understanding what’s new in Core Data with Apple’s latest platforms. You will learn about a new framework class called NSPersistentContainer that is designed to simplify the Core Data stack creation process. This concluding module will also point you to resources that will help you build on your new Core Data foundation.

Course Resources

Demos of technology in action are super important to me. That being the case, I tried to pack as much demo content into the course as possible. You’ll get to see the full array of dev-time experiences, not just the final “it works perfectly” outcomes.

The course also comes complete with working Xcode projects that gradually build you up to the final version of the app, one step at a time through each module.

Feedback Welcome!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

Core Data: Solving Ambiguous Type / Redeclaration of Type

Wed, 29 Mar 2017 02:57:05 +0000

I just finished roasting some coffee from Peru. I’ve never had it before, but it got me thinking about my Roaster On the Go “app” as I thought about the context that I could use to show you the solution to the compiler error described in the title. I used this to demonstrate Working with Unwind Segues Programmatically in Swift, but now I’m going to use it to show you how to resolve these errors that can crop up when you’re implementing NSManagedObject subclasses for your Core Data Entities.

Scenario – Adding a data model

The “app” doesn’t currently use Core Data, but for this article, I’ve created a rudimentary data model that includes a single Entity called Product:

Now suppose that I’m ready to implement a subclass of NSManagedObject for the Product Entity.

Doing so right now using Xcode 8’s default settings is going to give me all kinds of issues.

To be clear, I’m using Xcode 8.2 for this scenario.

The error that I’m getting when I attempt to build after creating a subclass of NSManagedObject for the Product Entity is one of the following (depending on how you choose to create the NSManagedObject subclass):

Invalid redeclaration of ‘Product'

‘Product’ is ambiguous for type lookup in this context

or in the compiler output

filename “Product+CoreDataClass.swift” used twice

What’s happening??

This is a conflict with Xcode 8’s auto codegen for NSManagedObject subclasses. In some versions of Xcode 8 (version 8.2, for example), this auto codegen is turned on by default. This can present a problem if you intend to manually create NSManagedObjectSubclasses for your Entities.

Solution

To solve this problem, or to avoid it before it occurs, you essentially need to turn off Xcode 8’s auto code generation feature for NSManagedObject subclasses if you intend to implement your NSManagedObject subclasses manually (my personal preference).

Take a look at the steps below to get your project building again:

1 – Turn off automatic code generation for NSManagedObject subclasses

Open your data model (the .xcdatamodeld file in your project).

Click on each Entity in your data model and in the Data Model Inspector of the Utilities Pane, change the Codegen property from “Class Definition” or “Category/Extension” to “Manual/None”:

2 – Choose module

You also need to tell Xcode where it can look to find a definition for the NSManagedObject subclass that you will implement for this Entity by choosing “Current Product Module” for the Module value:

Save your .xcdatamodeld file.

3 – Clear derived data

Behind the scenes, Xcode creates files and implements Types for the Entities in your data model. It puts them in your derived data folder and automatically traverses this folder to look for Type definitions for Core Data Entities. So in order to get your project building again, you need to get rid of those files that Xcode created automatically.

The “big hammer” for this is to simply clear all of your project’s derived data. To do this, click on the Products menu, hold down the Option key, and click “Clean build folder…”:

Press Option Key -> Clean Build Folder..." width="224" height="321" class="alignnone size-full wp-image-13118" srcset="https://www.andrewcbancroft.com/wp-content/uploads/2017/03/CleanBuildFolder.png 224w, https://www.andrewcbancroft.com/wp-content/uploads/2017/03/CleanBuildFolder-209x300.png 209w" sizes="(max-width: 224px) 100vw, 224px" />

Alternatively, you could opt to go in and delete the only auto-generated Swift files, but you’ve got to do some digging.

Click on File -> Project Settings:
Project Settings" width="353" height="495" class="alignnone size-full wp-image-13121" srcset="https://www.andrewcbancroft.com/wp-content/uploads/2017/03/ProjectSettings1.png 353w, https://www.andrewcbancroft.com/wp-content/uploads/2017/03/ProjectSettings1-214x300.png 214w" sizes="(max-width: 353px) 100vw, 353px" />

Next, click on the arrow next to the path leading to your default derived data folder:

Next, find the folder for your project at the root of your default derived data directory (where you were taken in Finder when you clicked the arrow in Project Settings). Then get ready to dig…

Click Build -> Intermediates -> ProjectName.build -> Debug-iphonesimulator -> ProjectName.build -> DerivedSources -> CoreDataGenerated -> ProjectName

Delete the .swift files in this folder.

4 – Rebuild

After you rebuild, any compiler errors you previously had, related to “ambiguous Type” or “redeclaration of Type” should be resolved!

Resources

Core Data Fundamentals with Swift

Using a Core Data Model in Swift Playgrounds

Sun, 10 Jul 2016 20:48:54 +0000

Did you know that you can tinker with Core Data inside of Swift playgrounds in Xcode? You can!

Jeremiah Jessel, author at http://www.learncoredata.com, wrote up an article in 2015 detailing how you can use the Core Data framework inside a playground. He shows how you can do everything from setting up the Core Data stack, to creating NSManagedObjects programmatically in code. Great stuff!

After I read his guide, I got to thinking: I wonder if you can take an .xcdatamodeld file created with Xcode’s Data Model designer and use it in a Playground….

The short answer is, kinda. You can’t use the .xcdatamodeld file (at least, I couldn’t find a way), BUT, you can use the compiled “momd” file that gets created when you build your app.

Limitations

There’s at least two limitations / caveats I’ve come across as I’ve been playing with this concept:

No NSManagedObject subclasses

While you can create instances of the Entities in the model, if you’ve created NSManagedObject subclasses for your Entities, you won’t be able to use those in the playground. You’d have to resort back to setting properties on your NSManagedObject instances using setValue(_: forKey:).

But this is a minor drawback, especially if you’re just wanting to tinker.

Model updates

After you read the walkthrough, you’ll know how to get the model into your playground.

Here’s the deal though: If you ever make changes to your model, you’ll need to go through the steps necessary to re-add a freshly-compiled model to the playground’s Resources folder that includes the changes. This is because resources that are added to a playground are copied, not referenced.

I don’t think that’s a terrible draw-back, especially once you know how to do it.

So how do you do it? Here’s how:

Walkthrough

Get started by adding a Data Model to your project. If you’ve got a project already going that uses Core Data, you probably already have a .xcdatamodeld file in your project. If you don’t, though, one is easily add-able from the File menu:

Add Data Model file (unless you already have one)

File -> New -> File…

For my “smoke test”, just to see if it was possible, I left the default value for the model name as “Model.xcdatamodeld”.

Add entity with attribute

Once I had the data model added to the project, I went in and added an entity (named “Entity”) with an attribute (named “attribute” of type Integer 16):

Add a playground

Next up, I added a new playground to my project:

File -> New -> Playground…

Build project; Locate “momd” file

With a playground and a data model has some structure to it, I built the project (CMD + B) so that the .xcdatamodeld file would be compiled into an “momd” file. It’s the momd file that needs to be added to the playground as a resource.

To find the “momd” file, expand “Products” in your project navigator, right-click the .app file, and click “Show in Finder”:

Show .app package contents

In the finder window, right-click the .app file, and click “Show package contents”:

Drag “momd” file from Finder to playground Resources folder

Write Core Data code to use model

That’s it! Now that the “momd” file is in the playground’s Resources folder, you’re set to write code against it. You can insert NSManagedObject instances, perform fetch requests, etc. Here’s an example that I wrote up:

import UIKit
import CoreData

// Core Data Stack Setup for In-Memory Store
public func createMainContext() -> NSManagedObjectContext {
    
    // Replace "Model" with the name of your model
    let modelUrl = NSBundle.mainBundle().URLForResource("Model", withExtension: "momd")
    guard let model = NSManagedObjectModel.init(contentsOfurl: modelUrl!) else { fatalError("model not found") }
    
    let psc = NSPersistentStoreCoordinator(managedObjectModel: model)
    try! psc.addPersistentStoreWithType(NSInMemoryStoreType, configuration: nil, URL: nil, options: nil)
    
    let context = NSManagedObjectContext(concurrencyType: .MainQueueConcurrencyType)
    context.persistentStoreCoordinator = psc
    
    return context
}

let context = createMainContext()

// Insert a new Entity
let ent = NSEntityDescription.insertNewObjectForEntityForName("Entity", inManagedObjectContext: context)
ent.setValue(42, forKey: "attribute")

try! context.save()

// Perform a fetch request
let fr = NSFetchRequest(entityName: "Entity")
let result = try! context.executeFetchRequest(fr)

print(result)

Woohoo! I thought this was pretty cool.

Don’t forget: If you make updates to your model, you need to re-build your app, delete the “momd” folder from your playground’s resources, re-drag the freshly-compiled “momd” file to your playground again to work with the latest version of the model.

Potential usefulness

The other important question to ask, besides “I wonder if this is possible?” is “How is this useful?”

Learning. Playgrounds in and of themselves make sense as a learning tool. How cool is it to be able to build the model you’re thinking of in the Xcode designer, import that into a playground, and tinker with it as a learning exercise??
This could also be useful when you need to try out your data model but don’t really want to wire it up to an actual user interface yet. Strip away all the UI complexity and just work with the data model… in a playground! It just seems like a more elegant solution to the “print it out to the console” method of experimenting with the model.
There might be situations when you’re building semi-complicated NSPredicate instances for a fetch request – why not get it working in a playground first, then migrate it over to your app? Just an idea!

You might also enjoy…

Core Data Cheat Sheet for Swift iOS Developers

Using Swift to Seed a Core Data Database

Displaying Data With NSFetchedResultsController and Swift

Sync Table View Data: NSFetchedResultsController and Swift

Resources

Core Data Fundamentals with Swift

Sharing a Core Data Model with a Swift Framework

Wed, 26 Aug 2015 04:04:05 +0000

Updated on June 13, 2017 – Swift 3.0, Xcode 8

Code re-use is a powerful thing, but it’s not always easy to pull off. We strive for it though, because in the long run, it makes maintaining the code far, far easier than if we just settled for copying and pasting.

With the introduction of dynamic frameworks in iOS 8, a world of possibility opened up for iOS developers to achieve some pretty cool re-use scenarios, one of which we’re going to dive into today.

Not only can we share code between projects, we can also share Core Data models between projects by utilizing frameworks!

Perhaps you’re working on an iOS + Mac app combination and the data model for each is identical. Maybe you’re building several iOS apps that have different user interfaces but share some underlying persistence-layer models. Whatever the case may be, wouldn’t it be awesome to design the Core Data model once and share it between your projects?

Example scenario

Our working example for this walkthrough will be the following:

Our team is building an iOS app and a Mac app and the underlying data model will be exactly the same between them. The only difference between the apps will be the target platform.

The app will target car enthusiasts everywhere – we will empower car fanatics to manage of a list of their favorite cars.

We’ll be creating two Xcode projects during this walkthrough: One will be the framework and will be called “CarKit”. The other will be a single view iOS application. We won’t actually dive into the Mac project, but one could imagine the process being very similar for importing CarKit into the Mac application when it came time to build that one.

I’m providing a completed CarKit + Carz package for you to look at over at GitHub:

Resources

CarKit + Carz Core Data Framework Example

Let’s get started!

Creating a Swift framework project

To get started with creating a Swift framework, begin with Xcode’s New Project dialog (File -> New -> Project…). Typically we stay in the realm of the “iOS Application” project templates, but if you click “Framework & library”, you’ll see the option to create a new Cocoa Touch Framework:

In keeping with Apple’s “___Kit” theme, we’ll name our framework “CarKit”:

Add a data model file

Once the framework project has been created, we’re set to drop in a new Data Model file from Xcode’s new file dialog (File -> New -> File…). Choose Core Data, and then Data Model:

Give the data model file a name that seems to fit your situation. For our example, let’s name it “CarModel”:

Add model attributes

Next it’s time to actually add attributes to the model. Since our theme is cars here, we’ll stick with three simple attributes: year, make, and model:

Create NSManagedObject subclass

With the model attributes all configured, it’s time to create an NSManagedObject subclass. This will make consuming the model much easier in client applications. I’ve actually written up a full walk through on creating an NSManagedObject subclass in Swift as there are some nuances. Feel free to read up on that if you so desire!

Be absolutely sure to mark your NSManagedObject subclass and its properties public – otherwise, the client app won’t be able to see the class or its properties:

As I point out in Implement NSManagedObject Subclass in Swift, you need to set the Module property in the Data Model Inspector to be CarKit (which is the same as the “Current Project Module” option for this example):

Build and inspect outputs

We’ve got a framework, and we’ve got a Data Model with attributes and an NSManagedObject subclass all appropriately implemented. Now it’s time to build the project and inspect the output of the build!

Command + B to build, and then head up to the File menu and choose Project Settings:

In the Project Settings area that appears, click the small gray arrow under the “Derived Data” section:

Next, find the derived data folder for your project. It should be named the same as your project with a set of random characters after. Sometimes there will be multiple folders that could be your project. You can look at the last modified date to help figure you figure out which one was most recently built and choose that one.

Expand the Build folder down to Build -> Products -> Debug-iphonesimulator. There you should see the CarKit.framework artifact, and within it, everything that’s needed to be able to utilize the data model in a client application. Awesome!

Note: This framework is not production-ready. It’s a little more involved to create a framework that one can run on a device / pass validation when submitting to the app store. The development of the framework remains the same, but the build phases and procedures must be modified to make it “universal”. Rather than overly complicate this walkthrough, I recommend reviewing “Universal Cocoa Touch Frameworks for iOS 8 – (Remix) by @kodmunki to create a “universal” framework capable of being run in the simulator and on iOS devices.

Creating the framework-dependent app

With the framework built, it’s time to create the iOS app that will utilize that framework and its packaged assets! Begin a new project from File -> New -> Project and select “Single View Application”. I’ll name our example app “Carz”. Ensure that “Use Core Data” is selected so that you get the boilerplate Core Data code put into your project by Xcode:

Remove Xcode-generated .xcdatamodeld file

When you select “Use Core Data” in the project creation window, Xcode automatically generates some boilerplate code, which we want. But it also gives us a “Carz.xcdatamodeld” file, which we will not need because we’ll use the model that’s found in CarKit. Remove the “Carz.xcdatamodeld” file that Xcode provides for you:

Obtain framework Bundle Identifier

Speaking of using the CarKit Core Data model, we’re now ready to configure that piece of the app. To do this part, you will need to know the Bundle Identifier from your framework project. To find out what it is, jump back over to the framework project, click the top-level node in the project navigator, click on the framework target name, and look under the General tab of the project configuration. There you’ll find the Bundle Identifier, which you can copy to your clipboard:

Replace managedObjectModel property initialization

Out of the box, Xcode generates some code to help locate your Core Data model file. The boilerplate managedObjectModel property looks like this:

lazy var managedObjectModel: NSManagedObjectModel = {
    // The managed object model for the application. This property is not optional. It is a fatal error for the application not to be able to find and load its model.
    let modelURL = NSBundle.mainBundle().URLForResource("DataModelFileName", withExtension: "momd")!
    return NSManagedObjectModel(contentsOfURL: modelURL)!
}()

However, this won’t work for us, because we’re going to use the data model from CarKit, and CarKit is not in the mainBundle(). This is why we jumped over and copied the Bundle Identifier for CarKit in the previous step. To locate the data model file in that bundle, you’ll replace the managedObjectModel initialization step to the following (for CarKit):

lazy var managedObjectModel: NSManagedObjectModel = {
        // The managed object model for the application. This property is not optional. It is a fatal error for the application not to be able to find and load its model.
        let carKitBundle = Bundle(identifier: "com.andrewcbancroft.CarKit")
        
        let modelURL = carKitBundle!.url(forResource: "CarModel", withExtension: "momd")!
        return NSManagedObjectModel(contentsOf: modelURL)!
}()

Recall that “CarModel” is the name of the Core Data model we created for the framework in CarKit. We simply look for that artifact by calling URLForResource:withExtension: on the carKitBundle to initialize an NSManagedObjectModel instance.

Add CarKit framework to project and embed binary

Now it’s time to actually bring in the framework for use within our app. I typically open up a Finder window and drag over a copy of the framework (in this case, the CarKit.framework file) into my project. Feel free to organize it into a “lib” folder.

Assuming that you go through all the necessary steps to make the framework production-ready, you’ll want to embed the binary and ensure that it’s referenced in the “Linked Frameworks and Libraries” portion of your project configuration:

Taking the model out for a test drive (pun intended)

It’s simple enough to try things out by writing a simple little snippet of code in the AppDelegate:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    // Override point for customization after application launch.
    
    let newCar = NSEntityDescription.insertNewObject(forEntityName: "Car", into: self.managedObjectContext!) as! Car
    newCar.year = 2015
    newCar.make = "Tesla"
    newCar.model = "S"
    
    do {
        try self.managedObjectContext?.save()
    } catch _ {
    }
    
    let fetchRequest = NSFetchRequest<NSFetchRequestResult>(entityName: "Car")
    let cars = (try! self.managedObjectContext?.fetch(fetchRequest)) as! [Car]
    
    print(cars, terminator: "")
    
    return true
}

This code simply obtains a new Car object, sets some properties, and saves it all with the managedObjectContext instance that’s configured in the AppDelegate.

Then it goes and performs a fetch request to grab all the Car objects and prints them. The results? See for yourself:

Wrapping up

This walkthrough guided you through the process of creating a framework for the purpose of sharing a Core Data model with multiple projects. My hope is that you’re now empowered to make use of _re_use by utilizing Swift frameworks to share even portions of your persistence layer!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Displaying Data With NSFetchedResultsController and Swift

Thu, 05 Mar 2015 15:14:53 +0000

The combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate Core Data with a user interface. The greatest benefits of using NSFetchedResultsController come when we use it to automatically update a table view when objects are added, updated, or removed from a Core Data data store. First things first, though…

With a Core Data data store seeded with data, the next logical step is to display that data somewhere other than the console. This post will be devoted to figuring out how to set up an NSFetchedResultsController to display data inside a UITableView.

A follow-up post has been published to help you keep the table view in sync with the data as it changes in your persistent store, so once you’re finished here, you might check out that next step!

Final goal

NSFetchedResultsController will help us accomplish two things:

It will fetch data from the Core Data data store
It will use some of the data we fetch to populate various pieces of the UI (table view section headers, cell “title” and “subtitle” text. Here’s what we’re going for:

Setup and resources

I’m continuing my “Zootastic” example that I used to write about using Swift to seed a Core Data database. In fact, I’ve simply branched the project on GibHub and added the things we’re exploring in this post.

Resources

Example Xcode Project

For this entry, we’ll still be dealing with our three primary NSManagedObject subclasses: Zoo, Animal, And Classification:

Storyboard

Zootastic is a single view application. The Storyboard contains one view controller with a table view filling the Scene.

The table view is using one prototype cell with an Identifier of “Cell” (for simplicity). The Style of the prototype cell is set to Subtitle.

MainViewController.swift

MainViewController.swift is where the action is happening. Here’s a quick outline of what we need to accomplish in this class:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // maintain a reference to NSManagedObjectContext instance

    // create and configure an NSFetchedResultsController instance

    // Implement UITableViewDataSource methods
}

As you can see, MainViewController is a class concerned with being the table view’s data source and delegate. Additionally, it will serve as the NSFetchedResultsControllerDelegate. For this post, we won’t actually need the fetched results controller delegate functionality to display data. Those methods are particularly useful for synchronizing things when data changes.

With the class declaration out of the way, we’ll investigate the class implementation one section at a time.

Maintain NSManagedObjectContext instance reference

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {
    
    public var context: NSManagedObjectContext!

    // ...
}

You may be asking, “Where will you set this NSManagedObjectContext reference?”. I’m employing a pattern that I’ve found successful in the past: I assign it when the finishes launching through the AppDelegate’s application:didFinishLaunchingWithOptions method. More on this, shortly…

For now, know that we’re counting on that later step to take place, since context is defined as an implicitly unwrapped optional.

Create and configure NSFetchedResultsController instance

Next, we need to create and configure an NSFetchedResultsController instance. Here’s a bit of code with comments to follow:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {
    
    // ...
    
    lazy var fetchedResultsController: NSFetchedResultsController = {
        let animalsFetchRequest = NSFetchRequest(entityName: "Animal")
        let primarySortDescriptor = NSSortDescriptor(key: "classification.order", ascending: true)
        let secondarySortDescriptor = NSSortDescriptor(key: "commonName", ascending: true)
        animalsFetchRequest.sortDescriptors = [primarySortDescriptor, secondarySortDescriptor]
        
        let frc = NSFetchedResultsController(
            fetchRequest: animalsFetchRequest,
            managedObjectContext: self.context,
            sectionNameKeyPath: "classification.order",
            cacheName: nil)
        
        frc.delegate = self
        
        return frc
        }()
    
    // ...

}

If you’ve not read Colin Eberhardt’s Swift Initialization and the Pain of Optionals post, I highly recommend it. His post is a fantastic analysis, and the final option of using lazy stored properties initialized by a closure expression is what I’ve chosen to do here. I won’t repeat his analysis here, so feel free to jump over to his post to figure out what’s going on there.

Within the closure expression, I’m setting up a fetch request with some sorting applied. All that’s left is to initialize the NSFetchedResultsController, set its delegate and return it.

viewDidLoad()

Once the view has loaded, the idea is to perform the NSFetchedResultsController instance’s fetch request so that it has data to use in our UITableViewDataSource methods. This is how to do it:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    override public func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.

            do {
                try fetchedResultsController.performFetch()
            } catch {
                print("An error occurred")
            }
    }

    // ...

}

UITableViewDataSource methods

The final step in implementing MainViewController is to set up the table view so that it pulls data from fetchedResultsController. I’m implementing the standard UITableViewDataSource methods here, along with tableView:titleForHeaderInSection. Take a look:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    // MARK: TableView Data Source
    public func numberOfSectionsInTableView(tableView: UITableView) -> Int {
        if let sections = fetchedResultsController.sections {
            return sections.count
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.numberOfObjects
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) 
        let animal = fetchedResultsController.objectAtIndexPath(indexPath) as! Animal
        
        cell.textLabel?.text = animal.commonName
        cell.detailTextLabel?.text = animal.habitat
        
        return cell
    }
    
    public func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.name
        }
        
        return nil
    }

    // ...

}

Apart from a bit of if let ___ = ___ syntax, there’s not an awful lot of surprising code here if you’re familiar with working with table views. I’ve highlighted the relevant code related to fetchedResultsController. Without using NSFetchedResultsController, you’d probably supply data to the table view from an array or a dictionary or both. The fetchedResultsController code simplifies the data display dilemma when you’re using Core Data.

Once the UITableViewDataSource methods are implemented, the implementation of MainViewController is complete for this example.

AppDelegate.swift

There’s one final thing we need to do in order to get things rolling. In the “maintain NSManagedObjectContext instance reference” section of this post, I mentioned the strategy for assigning the NSManagedObjectContext instance in the MainViewController. Here’s how I do it:

class AppDelegate: UIResponder, UIApplicationDelegate {

    // ...


    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        // Override point for customization after application launch.
        
        let dataHelper = DataHelper(context: self.managedObjectContext)
        dataHelper.seedDataStore()
        
        dataHelper.printAllZoos()
        dataHelper.printAllClassifications()
        dataHelper.printAllAnimals()
        
        let rootViewController = self.window!.rootViewController as! MainViewController
        rootViewController.context = self.managedObjectContext;
        
        return true
    }

    // ...

}

Note: With iOS 13, the code to assign the managedObjectContext to the root view controller needs to go in your app’s SceneDelegate.

The portion new to “injecting” the managedObjectContext into MainViewController is highlighted. I simply grab a reference to the rootViewController (which in our example is the MainViewController) and cast it to the appropriate type. Then I set the context property to the managedObjectContext that’s created in the AppDelegate via Xcode’s auto-generated Core Data stack setup.

Wrapping up

If you’re using Core Data in your iOS application, the combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate data from your data store into your UI. We’ve explored how to display data in a table view using NSFetchedResultsController. Feel free to grab the GibHub project for further investigation and to see Zootastic in action.

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Using Swift to Seed a Core Data Database

Thu, 26 Feb 2015 03:44:53 +0000

Designing an application’s UI can be difficult without actual data to present. Early on in the design process, data sourced from something like an array can suffice. Later on, however, our data sources become more dependent on actual data stores, such as what Core Data provides us.

During development, I’ve found that it’s often convenient to seed a Core Data database with sample data so that I can preview how it’ll look in my application. Along with that, it’s nice to start with a fresh copy of the data each time I run the app. Let’s explore how to accomplish this task in Swift!

Scenario setup

Resources

Example Xcode Project

I’ve created a fictitious Core Data app called “Zootastic”, which is intended to model zoos, and the animals that each zoo cares for. (I’ll give you one guess as to what kinds of shows and activities my two year old and I have been in to lately). :]

Specifically, I have the following Entities:

Zoo
- name
- location
- animals (relationship)
Animal
- commonName
- habitat
- classification (relationship)
- zoos (relationship)
Classification
- scientificClassification
- family
- order
- animals (relationship)

I’ve created NSManagedObject subclasses for each of my entities, to make it easier to set properties.

DataHelper.swift

Once a Core Data data model is set up, we’re ready to create what I called DataHelper. It serves the purpose of seeding the data store, and logging the data store’s contents back out to the console. It violates the single-responsibility principle, but wait! Don’t lynch me!

Knowing that this class is intended to be used solely for development, I didn’t put a lot of effort into separating concerns. I opted for a “here’s where I go to do all my seeding for manual testing purposes” approach.

Here are a few snippets from the class (grab the full Xcode project over at GitHub):

Initialization

 1public class DataHelper {
 2    let context: NSManagedObjectContext
 3    
 4    init(context: NSManagedObjectContext) {
 5        self.context = context
 6    }
 7    
 8// ...
 9
10}

The primary thing to take away from the initialization routine is that instead of calling out to the AppDelegate to get an instance of the NSManagedObjectContext, I’m choosing to require it to be passed in during the initialization of DataHelper. It’s a pattern I like to practice because it allows me to do unit tests in real-world applications that use Core Data.

seedZoos()

 1public class DataHelper {
 2
 3// ...
 4
 5    private func seedZoos() {
 6        let zoos = [
 7            (name: "Oklahoma City Zoo", location: "Oklahoma City, OK"),
 8            (name: "Lowry Park Zoo", location: "Tampa, FL"),
 9            (name: "San Diego Zoo", location: "San Diego, CA")
10        ]
11        
12        for zoo in zoos {
13            let newZoo = NSEntityDescription.insertNewObjectForEntityForName("Zoo", inManagedObjectContext: context) as! Zoo
14            newZoo.name = zoo.name
15            newZoo.location = zoo.location
16        }
17        
18        do {
19            try context.save()
20        } catch _ {
21        }
22    }
23
24// ...
25
26}

A few observations on the code above:

This function may look a bit interesting. I’ve chosen to create an array of tuples that I loop over and use to extract actual Zoo information when I call NSEntityDescription.insertNewObjectForEntityForName(). It just looked nice to me to have two chunks of code to analyze inside the function: One (the array of tuples) to see all of the zoo information I plan to insert, and another (the for-loop) to do the actual inserting into the data store. Adding more Zoos in the future would mean simply adding another tuple to the array. Convenient!
Since I’ve created NSManagedObject subclasses for my entities, I can cast the result of NSEntityDescription.insertNewObjectForEntityForName() to an actual Zoo, to work with the properties directly.

printAllZoos()

 1public class DataHelper {
 2
 3// ...
 4
 5    public func printAllZoos() {
 6        let zooFetchRequest = NSFetchRequest(entityName: "Zoo")
 7        let primarySortDescriptor = NSSortDescriptor(key: "name", ascending: true)
 8        
 9        zooFetchRequest.sortDescriptors = [primarySortDescriptor]
10        
11        let allZoos = (try! context.executeFetchRequest(zooFetchRequest)) as! [Zoo]
12        
13        for zoo in allZoos {
14            print("Zoo Name: \(zoo.name)\nLocation: \(zoo.location) \n-------\n", terminator: "")
15        }
16    }
17
18// ...
19
20}

printAllZoos() function utilizes a standard NSFetchRequest, along with an NSSortDescriptor. Check out my cheat sheet for more examples of common Core Data operations.

Once again, having the NSManagedObject subclass in place allows me to cast the result of the fetch request to a [Zoo].

seedAnimals()

 1public class DataHelper {
 2
 3// ...
 4
 5    private func seedAnimals() {
 6        // Grab Classifications
 7        let classificationFetchRequest = NSFetchRequest(entityName: "Classification")
 8        let allClassifications = (try! context.executeFetchRequest(classificationFetchRequest)) as! [Classification]
 9
10        let manatee = allClassifications.filter({(c: Classification) -> Bool in
11            return c.family == "Trichechidae"
12        }).first
13        
14        // Same pattern for monkey and bat
15        
16        // Grab Zoos
17        let zooFetchRequest = NSFetchRequest(entityName: "Zoo")
18        let allZoos = (try! context.executeFetchRequest(zooFetchRequest)) as! [Zoo]
19        
20        let oklahomaCityZoo = allZoos.filter({ (z: Zoo) -> Bool in
21            return z.name == "Oklahoma City Zoo"
22        }).first
23        
24        // Same pattern for San Diego Zoo and Lowry Park Zoo
25        
26        // Create an array of "animal" tuples, assigning
27        // whatever Classification and Zoo make sense
28        let animals = [
29            (commonName: "Pygmy Fruit-eating Bat", habitat: "Flying Mamals Exhibit", classification: bat!, zoos: NSSet(array: [lowryParkZoo!, oklahomaCityZoo!, sanDiegoZoo!])),
30            (commonName: "Mantled Howler", habitat: "Primate Exhibit", classification: monkey!, zoos: NSSet(array: [sanDiegoZoo!, lowryParkZoo!])),
31            (commonName: "Geoffroy’s Spider Monkey", habitat: "Primate Exhibit", classification: monkey!, zoos: NSSet(array: [sanDiegoZoo!])),
32            (commonName: "West Indian Manatee", habitat: "Aquatic Mamals Exhibit", classification: manatee!, zoos: NSSet(array: [lowryParkZoo!]))
33        ]
34        
35        // Create -actual- Animal instances and insert them
36        for animal in animals {
37            let newAnimal = NSEntityDescription.insertNewObjectForEntityForName("Animal", inManagedObjectContext: context) as! Animal
38            newAnimal.commonName = animal.commonName
39            newAnimal.habitat = animal.habitat
40            newAnimal.classification = animal.classification
41            newAnimal.zoos = animal.zoos
42        }
43        
44        do {
45            try context.save()
46        } catch _ {
47        }
48    }
49
50// ...
51
52}

seedAnimals() is the most complicated piece of the whole scenario because it depends on entities that have been previously inserted into the data store. An Animal, which is a member of some Classification lives in some habitat at a Zoo. So in order to get a complete Animal into the data store, we need to have a Classification and one or more Zoo to assign it.

I’ve chosen to go ahead and execute fetch requests for the entities I made in previous seed___() functions. Additionally, rather than deal with NSPredicate, I just grab all Classifications and all Zoos, and use array’s filter function to get the exact Entity I want.

The last thing I’ll mention / warn against, is that I am using explicitly unwrapped optionals in this function. I’ve gone ahead and “risked it”, trusting that I’m only using this technique during development time to help me see how things will look in my UI. In other words, this isn’t code that will end up in Production. It’s simply meant to help me while I’m developing, so I’ve gone ahead and done things the quick way here.

The rest of the function follows the same patterns that have already been used in this example.

AppDelegate.swift

 1func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
 2        // Override point for customization after application launch.
 3        
 4        let dataHelper = DataHelper(context: self.managedObjectContext)
 5        dataHelper.seedDataStore()
 6        
 7        dataHelper.printAllZoos()
 8        dataHelper.printAllClassifications()
 9        dataHelper.printAllAnimals()
10        
11        return true
12    }

Above is a peek at what my AppDelegate.swift file’s application:didFinishLaunchingWithOptions: function looks like. Nothing fancy going on here. I’m simply initializing a DataHelper instance with the NSManagedObjectContext instance that’s created in this class, and calling the seed and print functions I defined earlier.

Starting fresh every time

I’ve found that sometimes it helps to have a freshly seeded data store every time I the app while I’m in development mode. When I’m testing the UI, I may create new entities during my manual testing, but one of the convenient things about seeding the data store is that I don’t have to. And even if I did, it’s often quite nice to start fresh each run. To do this we’ll dive into some of the boilerplate code that Xcode generates for us when we choose to use Core Data when we create the project. Specifically, we’ll target the persistentStoreCoordinator closure:

 1lazy var persistentStoreCoordinator: NSPersistentStoreCoordinator = {
 2        // The persistent store coordinator for the application. This implementation creates and returns a coordinator, having added the store for the application to it. This property is optional since there are legitimate error conditions that could cause the creation of the store to fail.
 3        // Create the coordinator and store
 4        let coordinator = NSPersistentStoreCoordinator(managedObjectModel: self.managedObjectModel)
 5        let url = self.applicationDocumentsDirectory.URLByAppendingPathComponent("Zootastic.sqlite")
 6        
 7        do {
 8            try NSFileManager.defaultManager().removeItemAtURL(url)
 9        } catch _ {
10        }
11
12        
13        var failureReason = "There was an error creating or loading the application's saved data."
14        do {
15            try coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: url, options: nil)
16        } catch {
17            // Report any error we got.
18            var dict = [String: AnyObject]()
19            dict[NSLocalizedDescriptionKey] = "Failed to initialize the application's saved data"
20            dict[NSLocalizedFailureReasonErrorKey] = failureReason
21            
22            dict[NSUnderlyingErrorKey] = error as NSError
23            let wrappedError = NSError(domain: "YOUR_ERROR_DOMAIN", code: 9999, userInfo: dict)
24            // Replace this with code to handle the error appropriately.
25            // abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
26            NSLog("Unresolved error \(wrappedError), \(wrappedError.userInfo)")
27            abort()
28        }
29        
30        return coordinator
31        }()

I’ve highlighted the key line that I added (everything else was already in place, generated for me by Xcode). Adding that line removes the sqlite database. The lines that follow add it back in a fresh state.

Wrapping up

Designing an application’s UI can be difficult without actual data to present. During development, it’s often convenient to seed a Core Data database with sample data so that we can preview how it’ll look in our application. Along with that, it’s nice to start with a fresh copy of the data each time we run the app. We explored how to accomplish this task in Swift!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Core Data Cheat Sheet for Swift iOS Developers

Wed, 18 Feb 2015 18:20:59 +0000

Updated on July 27, 2016 – Additional Cheats

Having trouble recalling how to perform basic Core Data operations? This cheat sheet is a handy reference to keep you productive with Core Data and Swift!

The code snippets below are here to help jog your memory when it’s been a while since you’ve worked in Core Data. They could also be helpful for newcomers to iOS development, Core Data, and Swift.

One assumption I’m making in this post is that you’ve created NSManagedObject subclasses for your entities to make them easier to work with in a type-safe way. If you need help getting started with that, I’ve written a walk-through to guide you through that process.

Querying

Fetch all entities

// Assuming type has a reference to managed object context

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    // Do something with fetchedEntities
} catch {
    // Do something in response to error condition
}

Fetch maximum of N entities

// Assuming type has a reference to managed object context

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.fetchLimit = 10
do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    // Do something with fetchedEntities
} catch {
    // Do something in response to error condition
}

Insert a new entity

// Assuming encapsulating Type has a reference to managed object context

let newEntity = NSEntityDescription.insertNewObjectForEntityForName("MyEntity", inManagedObjectContext: self.managedObjectContext) as! MyEntity
// Set properties

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Update a single entity

// Assuming type has a reference to managed object context

// Assuming that a specific NSManagedObject's objectID property is accessible
// Alternatively, could supply a predicate expression that's precise enough
// to select only a _single_ entity
let predicate = NSPredicate(format: "objectID == %@", objectIDFromNSManagedObject)

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    fetchedEntities.first?.FirstPropertyToUpdate = NewValue
    fetchedEntities.first?.SecondPropertyToUpdate = NewValue
    // ... Update additional properties with new values
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Update multiple-entities

// Assuming type has a reference to managed object context

let predicate = NSPredicate(format: "MyEntityAttribute == %@", "Matching Value")

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    
    for entity in fetchedEntities {
        entity.FirstPropertyToUpdate = NewValue
        entity.SecondPropertyToUpdate = NewValue
        // ... Update additional properties with new values
    }
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Delete a single entity

// Assuming type has a reference to managed object context

// Assuming that a specific NSManagedObject's objectID property is accessible
// Alternatively, could supply a predicate expression that's precise enough
// to select only a _single_ entity
let predicate = NSPredicate(format: "objectID == %@", objectIDFromNSManagedObject)

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    if let entityToDelete = fetchedEntities.first {
        self.managedObjectContext.deleteObject(entityToDelete)
    }
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Delete multiple-entities

// Assuming type has a reference to managed object context

let predicate = NSPredicate(format: "MyEntityAttribute == %@", "Matching Value")

let fetchRequest = NSFetchRequest(entityName: "MyEntity")
fetchRequest.predicate = predicate

do {
    let fetchedEntities = try self.managedObjectContext.executeFetchRequest(fetchRequest) as! [MyEntity]
    
    for entity in fetchedEntities {
        self.managedObjectContext.deleteObject(entity)
    }
} catch {
    // Do something in response to error condition
}

do {
    try self.managedObjectContext.save()
} catch {
    // Do something in response to error condition
}

Migrate Core Data Model with Automatic Migrations

let model = // set up model

let pscOptions = [NSMigratePersistentStoresAutomaticallyOption : true, NSInferMappingModelAutomaticallyOption : true]
    
let psc = NSPersistentStoreCoordinator(managedObjectModel: model)
try! psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: pscOptions)

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Unit Testing Model Layer with Core Data and Swift

Tue, 13 Jan 2015 13:00:37 +0000

Updated on November 19, 2015 – Swift 2.0

As I approached testing my Core Data model, I have to admit I was apprehensive. How in the world was I going to write unit tests for my model layer that depended on a database. Past experience with trying to write tests with databases was painful. I feared the same would be the case with Core Data.

To my surprise, unit testing my Core Data model layer has been… well… amazing. With little effort, I’ve been able to write the unit tests I’ve wanted. The process went something like this for me:

Create an NSManagedObject subclass of the Core Data entity that I need in my unit test. (This just makes things easier from an Xcode code-completion standpoint)
Write a helper function to set up an in-memory NSManagedObjectContext. Avoiding the need to use an actual sqlite database is pretty handy. It allows for quick-running tests and easy iterations over the data model itself.
Write unit tests using the in-memory NSManagedObjectContext.

I’ve already written about creating an NSManagedObject subclass, so I will unpack steps 2 and 3 in this blog entry.

Set up an in-memory NSManagedObjectContext

A Stack Overflow question+answer sparked some thoughts. The idea and the code both came from there. The answer uses Objective-C, so my contribution is that I’ve written it in Swift. In my project, I created a new Swift file called “CoreDataHelpers.swift” in my tests target. Here’s a look at the helper function:

 1import CoreData
 2
 3func setUpInMemoryManagedObjectContext() -> NSManagedObjectContext {
 4    let managedObjectModel = NSManagedObjectModel.mergedModelFromBundles([NSBundle.mainBundle()])!
 5    
 6    let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)
 7
 8    do {
 9        try persistentStoreCoordinator.addPersistentStoreWithType(NSInMemoryStoreType, configuration: nil, url: nil, options: nil)
10    } catch {
11        print("Adding in-memory persistent store failed")
12    }
13    
14    let managedObjectContext = NSManagedObjectContext()
15    managedObjectContext.persistentStoreCoordinator = persistentStoreCoordinator
16    
17    return managedObjectContext
18}

Observations

I’ll be honest, I’m only starting to put together the pieces involved in setting up the Core Data stack. Working through these unit testing techniques has solidified a lot. Analyzing the helper method from the bottom up has made some sense out of how to configure everything:

I need an NSManagedObjectContext whose NSPersistentStoreCoordinator property uses an in-memory store.
To get such an NSManagedObjectContext, I need to add a persistent store with a type of NSInMemoryStoreType to an NSPersistentStoreCoordinator instance. (note the line that’s highlighted)
Of course, in order to do that, I need an NSPersistentStoreCoordinator instance, and I can’t get one of those unless I initialize it with an NSManagedObjectModel.
To get an NSManagedObjectModel, I use the class method, mergedModelFromBundles() to grab it from my main bundle.
Fast-forwarding now: With a proper NSManagedObjectModel instance, I can create an NSPersistentStoreCoordinator instance with it and add an NSInMemoryStoreType to that persistentStoreCoordinator. Finally, I can initialize an NSManagedObjectContext, assign the configured persistentStoreCoordinator to the context, and return it.

Whew! This whole process felt a lot like reading If You Give a Mouse a Cookie, but that may be because I’ve read it a few hundred times to my 2 year old. :]

Writing the unit test(s)

With the ability to get an NSManagedObjectContext instance that’s using an in-memory store, the unit tests using Entities from my Core Data model are quite easy.

Here’s a sample test:

 1import CoreData
 2
 3class TestsUsingModelFromCoreData: XCTestCase {
 4    func testSomethingUsingCoreData() {
 5        let managedObjectContext = setUpInMemoryManagedObjectContext()
 6        let entity = NSEntityDescription.insertNewObjectForEntityForName("EntityName", inManagedObjectContext: managedObjectContext)
 7        
 8        // model setup
 9        
10        // XCTAssert    
11    }
12}

Conclusion

I was so surprised at how straightforward the test was. The helper function makes a world of difference for me. I hope it does for you, too!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Implement NSManagedObject Subclass in Swift

Fri, 18 Jul 2014 04:08:12 +0000

Updated on July 8, 2016 – Xcode 7

My goal with this blog entry is to help get you set up to create NSManagedObject subclasses in Swift for the Entities in your Core Data model.

Example

Let’s look at a fabricated example: Say that you’ve got a Core Data project and you’re creating Entities. For my simple project, I’ll create an Entity called “MyEntity” with an attribute called “myAttribute”.

After you create an NSManagedObject subclass for the Entity and come back to the data model screen to specify the “Class” in the inspector area, you must prefix the name of the class with “YourProjectName.” (don’t forget the dot). Forgetting to do this will lead to run-time errors when you start interacting with instances of your NSManagedObject subclass.

Apple specifies this in their documentation page, but it was a subtle mention at the end of the document and I just happened upon it as I was troubleshooting this:

Swift classes are namespaced—they’re scoped to the module (typically, the project) they are compiled in. To use a Swift subclass of the NSManagedObject class with your Core Data model, prefix the class name in the Class field in the model entity inspector with the name of your module.

Walk-through

Create an Entity

In your .xcdatamodeld file, create an Entity to your liking. In my example, I named the Entity “MyEntity” and I gave it an attribute called “myAttribute” with a data type of String.

Create an NSManagedObject Subclass for that Entity

On the Menu, click Editor, then “Create NSManagedObject Subclass…”

Make sure you choose “Swift” as your language of choice as you click Next through the wizard and Xcode will generate you a file that is appropriate for your Entity. The files it created for me (Xcode 7.1.1) look like this:

Verify NSManagedObject class in the “Data Model Inspector”

Make sure that you have your .xcdatamodeld file selected in the Navigator panel. Then make sure your Utilities panel is visible.

Click the “Data Model Inspector” icon. This will be the last icon in the inspector of Xcode. You should see a section for “Entity” and within this section, two textboxes: one for Name and one for Class. You should also see a drop-down for the Module that the NSManagedObject subclass is found in.

You’ll be verifying the Class and the Module values:

According to the Swift documentation, Swift class namespaces are scoped to the module they’re compiled in (usually the project you’re working in).

To use the NSManagedObject subclass in your project, you just need to verify that the Module setting is set to “Current Product Module”, assuming that the NSManagedObject subclass you’re wiring this Entity to is found in that module. If it’s in another module, you’ll need to adjust the Module value in the inspector appropriately.

Once the Class and Module values are verified (or set), you’ll be able to use this NSManagedObject subclass anywhere in your project.

You might also enjoy…

Core Data Cheat Sheet for Swift iOS Developers

Using Swift to Seed a Core Data Database

Displaying Data With NSFetchedResultsController and Swift

Sync Table View Data: NSFetchedResultsController and Swift

Resources

Core Data Fundamentals with Swift