persistent – Augmented Code

Using CoreData with SwiftUI

CoreData is Apple’s object graph and persistence framework. It provides data sources for synchronising data with view. Let’s take a look on how to use those data sources in SwiftUI views. Starting with NSFetchedResultsController what is used for list and collection views, after that observing NSManagedObject directly from SwiftUI view and lastly subscribing to managed object context notifications.

NSFetchedResultsController

NSFetchedResultsController is used for providing data in table and collection views. It supports sorting and filtering data and arranging data into sections. We can use delegate for getting change callbacks. NSFetchedResultsControllerDelegate contains several methods:

	// Diffable data source (new in iOS 13)
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChangeContentWith snapshot: NSDiffableDataSourceSnapshot)
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChangeContentWith diff: CollectionDifference<NSManagedObjectID>)

	// Manually updating table view and collection view
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange anObject: Any, at indexPath: IndexPath?, for type: NSFetchedResultsChangeType, newIndexPath: IndexPath?)
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange sectionInfo: NSFetchedResultsSectionInfo, atSectionIndex sectionIndex: Int, for type: NSFetchedResultsChangeType)
	optional func controllerWillChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>)
	optional func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>)

view raw DataSources.swift hosted with ❤ by GitHub

In SwiftUI we are not going to directly manipulate views. Only what we need to do is letting SwiftUI view know that data is about to change. Let’s take a look on simple app with list of items stored by CoreData. Data is represented by ColorItem where only stored value is hex string of the color (e.g. #AA22BB).

	final class ColorItem: NSManagedObject {
	@NSManaged var hex: String
	}

view raw ColorItem.swift hosted with ❤ by GitHub

ColorItems are managed by ContentView’s view model. View model creates NSFetchedResultsController, performs fetch and provides array of fetched ColorItems to the SwiftUI’s List. In addition, view model is delegate of the NSFetchedResultsController (requires view model to be NSObject subclass). As view model is ObservableObject, we can very easily let SwiftUI view know that it should refresh. We need to do two things: firstly, implementing controllerWillChangeContent delegate method and calling send() on objectWillChange publisher. Secondly, view model property must use @ObservedObject property wrapper in SwiftUI view. Result is that SwiftUI view subscribes to objectWillChange publisher and refreshes whenever publisher emits an event.

	extension ContentView {
	final class ViewModel: NSObject, NSFetchedResultsControllerDelegate, ObservableObject {
	private let colorController: NSFetchedResultsController<ColorItem>

	init(managedObjectContext: NSManagedObjectContext) {
	let sortDescriptors = [NSSortDescriptor(keyPath: \ColorItem.hex, ascending: true)]
	colorController = ColorItem.resultsController(context: managedObjectContext, sortDescriptors: sortDescriptors)
	super.init()
	colorController.delegate = self
	try? colorController.performFetch()
	}

	func controllerWillChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
	objectWillChange.send()
	}

	var colors: [ColorItem] {
	return colorController.fetchedObjects ?? []
	}
	}
	}

	extension ColorItem {
	static func resultsController(context: NSManagedObjectContext, sortDescriptors: [NSSortDescriptor] = []) -> NSFetchedResultsController<ColorItem> {
	let request = NSFetchRequest<ColorItem>(entityName: "ColorItem")
	request.sortDescriptors = sortDescriptors.isEmpty ? nil : sortDescriptors
	return NSFetchedResultsController(fetchRequest: request, managedObjectContext: context, sectionNameKeyPath: nil, cacheName: nil)
	}
	}

view raw ViewModelFetchedResults.swift hosted with ❤ by GitHub

And finally let’s see the ContentView implementation. NSManagedObject has objectID property what we can use in List for identifying every ColorItem. Cell is custom view what we’ll take a look at next.

	struct ContentView: View {
	@ObservedObject var viewModel: ViewModel

	var body: some View {
	NavigationView {
	VStack {
	List(viewModel.colors, id: \.objectID) { (colorItem) in
	Cell(colorItem: colorItem)
	}
	}.navigationBarTitle("Colors")
	}
	}
	}

view raw ContentViewFetchedResults.swift hosted with ❤ by GitHub

NSManagedObject

NSManagedObject implements ObservableObject protocol and therefore it is possible to use it together with @ObservedObject property wrapper and getting SwiftUI view refreshed automatically when any of the ColorItem properties change. NSFetchedResultsController required a little bit of code for setting up delegate but that is not the case with NSManagedObject.

	struct Cell: View {
	@ObservedObject var colorItem: ColorItem

	var body: some View {
	HStack {
	Text(verbatim: colorItem.hex)
	Spacer()
	Rectangle().foregroundColor(Color(colorItem.uiColor)).frame(minWidth: 50, maxWidth: 50)
	}
	}
	}

view raw Cell.swift hosted with ❤ by GitHub

In addition, if there are cases where we would like to observe specific property, then Combine provides publisher for key path. Because NSManagedObject supports key-value observing we can use the publisher and subscribe to individual property changes.

	let cancellable = color.publisher(for: \.hex).sink { (string) in
	print(string)
	}

view raw KVOPublisherSink.swift hosted with ❤ by GitHub

Subscribing to CoreData notifications

When we need to observe changes in persistent store we can observe notifications sent by the framework. As NotificationCenter supports publishers, we can subscribe to it, unpack data from notification and do something with the data. For making this easier we can introduce a separate type. It will unpack the user info dictionary and filter by type. This allows to easily observe, for example, ColorItem insertions. Or, if we would like to receive every possible change, we can specify NSManagedObject as the generic type.

	private var cancellables = [AnyCancellable]()

	let cancellable = NotificationCenter.default.publisher(for: .NSManagedObjectContextObjectsDidChange, object: managedObjectContext)
	.compactMap({ ManagedObjectContextChanges<ColorItem>(notification: $0) }).sink { (changes) in
	print(changes)
	}
	cancellables.append(cancellable)

	struct ManagedObjectContextChanges<T: NSManagedObject> {
	let inserted: Set<T>
	let deleted: Set<T>
	let updated: Set<T>

	init?(notification: Notification) {
	let unpack: (String) -> Set<T> = { key in
	let managedObjects = (notification.userInfo?[key] as? Set<NSManagedObject>) ?? []
	return Set(managedObjects.compactMap({ $0 as? T }))
	}
	deleted = unpack(NSDeletedObjectsKey)
	inserted = unpack(NSInsertedObjectsKey)
	updated = unpack(NSUpdatedObjectsKey).union(unpack(NSRefreshedObjectsKey))
	if deleted.isEmpty, inserted.isEmpty, updated.isEmpty {
	return nil
	}
	}
	}

view raw ManagedObjectContextChanges.swift hosted with ❤ by GitHub

Summary

We took a look at how to use NSFetchedResultsController and NSManagedObject in SwiftUI views. We saw that integrating NSFetchedResultsController requires only a little bit of code and using NSManagedObject even less. In addition, we looked at subscribing to CoreData notifications and unpacking notification payload.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Example project

CoreDataCombineSwiftUI (Xcode 11.3)

Support me on Patreon

Donate with Paypal

Buy me a coffee

Creating persistent data store on iOS

Storing data persistently on iOS is something what is needed quite often. In this post, we are going to look into how to build a persistent data store and how to store image data.

Initialising the persistent data store

Persistent data store is an object managing a folder on disk. It allows writing and reading data asynchronously.
Firstly, we need to create a folder where to store all the files. As every instance of the data store should manage its own folder, we will add an argument name to the initialiser. Then we can create a folder in user’s documents folder with that name. As writing and reading data is an expensive operation, we are going to offload the work to a concurrent DispatchQueue. Concurrent dispatch queue allows us to read multiple files at the same time (more about it a bit later).

	final class PersistentDataStore {
	let name: String
	private let dataStoreURL: URL
	private let queue: DispatchQueue

	init(name: String) throws {
	self.name = name
	queue = DispatchQueue(label: "com.augmentedcode.persistentdatastore", qos: .userInitiated, attributes: .concurrent, autoreleaseFrequency: .workItem)
	let documentsURL = try FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
	dataStoreURL = documentsURL.appendingPathComponent(name, isDirectory: true)
	try FileManager.default.createDirectory(at: dataStoreURL, withIntermediateDirectories: true, attributes: nil)
	}
	}

view raw PersistentDataStore+Creation.swift hosted with ❤ by GitHub

Storing data asynchronously

Method for storing data on disk consists of closure, identifier and completion handler. This allows us to create a closure what transforms object to data. For example, it could transform UIImage to Data. Secondly, this transformation, possibly slow operation, can be offloaded to the same thread writing the data into a file. Using closure gives us a flexible API what we can extend with convenience methods.

	typealias Identifier = String

	enum Result {
	case failed(Error)
	case noData
	case success(Identifier)
	}

	func storeData(_ dataProvider: @escaping () -> (Data?), identifier: Identifier = UUID().uuidString, completionHandler block: @escaping (Result) -> ()) {
	queue.async(flags: .barrier) {
	let url = self.url(forIdentifier: identifier)
	guard let data = dataProvider(), !data.isEmpty else {
	DispatchQueue.main.async {
	block(.noData)
	}
	return
	}
	do {
	try data.write(to: url, options: .atomic)
	DispatchQueue.main.async {
	block(.success(identifier))
	}
	}
	catch {
	DispatchQueue.main.async {
	block(.failed(error))
	}
	}
	}
	}

	// Example (adding data to data store with unique identifier):
	persistentStore.storeData({ () -> (Data?) in
	return image.jpegData(compressionQuality: 1.0)
	}) { (result) in
	switch result {
	case .success(let identifier):
	print("Stored data successfully with identifier \(identifier).")
	case .noData:
	print("No data to store.")
	case .failed(let error):
	print("Failed storing data with error \(error)")
	}
	}

view raw PersistentDataStore+Storing.swift hosted with ❤ by GitHub

Identifier is internally used as a filename and default implementation creates unique identifier. Therefore, when data store consumer would like to replace the current file, it can supply an identifier, otherwise new file is created.
Completion handler contains a Result enum type. Result enum consists of three cases: success, transformation failure and data writing failure. Success’ associated value is identifier, failure contains error object and transformation failure is equal to noData.
Important to note here is that the work item has barrier specified. Barrier means that when DispatchQueue starts to handle the work item, it will wait until all the previous work items have finished running. Meaning, we will never try to update a file on disk when some other request is busy reading it.

Loading data asynchronously

Load data is generic method allowing the data transformation closure to return a specific type (e.g. transforming Data to UIImage). Shortly, load data reads file from disk and transforms it into a different type. As transformation can be a lengthy task, it is yet again running on the background thread and will not cause any hiccups in the UI.

	func loadData<T>(forIdentifier identifier: Identifier, dataTransformer: @escaping (Data) -> (T?), completionHandler block: @escaping (T?) -> ()) {
	queue.async {
	let url = self.url(forIdentifier: identifier)
	guard FileManager.default.fileExists(atPath: url.path) else {
	DispatchQueue.main.async {
	block(nil)
	}
	return
	}
	do {
	let data = try Data(contentsOf: url, options: .mappedIfSafe)
	let object = dataTransformer(data)
	DispatchQueue.main.async {
	block(object)
	}
	}
	catch {
	print("Failed reading data at URL \(url).")
	DispatchQueue.main.async {
	block(nil)
	}
	}
	}
	}

	// Example
	persistentStore.loadData(forIdentifier: "my_identifier", dataTransformer: { UIImage(data: $0) }) { (image) in
	guard let image = image else {
	print("Failed loading image.")
	return
	}
	print(image)
	}

view raw PersistentDataStore+Loading.swift hosted with ❤ by GitHub

Removing data asynchronously

Removing a single file or all of the files is pretty straight-forward. As we are modifying files on disk, we will use barrier again and then FileManager’s removeItem(at:) together with contentsOfDirectory(at:includingPropertiesForKeys:options:).

	func removeData(forIdentifier identifier: Identifier) {
	queue.async(flags: .barrier) {
	let url = self.url(forIdentifier: identifier)
	guard FileManager.default.fileExists(atPath: url.path) else { return }
	do {
	try FileManager.default.removeItem(at: url)
	}
	catch {
	print("Failed removing file at URL \(url) with error \(error).")
	}
	}
	}

	func removeAll() {
	queue.async(flags: .barrier) {
	do {
	let urls = try FileManager.default.contentsOfDirectory(at: self.dataStoreURL, includingPropertiesForKeys: nil, options: [])
	try urls.forEach({ try FileManager.default.removeItem(at: $0) })
	}
	catch {
	print("Failed removing all files with error \(error).")
	}
	}
	}

view raw PersistentDataStore+Removing.swift hosted with ❤ by GitHub

Extension for storing images

It is easy to extend the PersistentDataStore with convenience methods for storing a specific type of data. This allows us to hide the technical details of transforming image to data and vice-versa. Moreover, calling the method gets easier to read as data transformation closure is not visible anymore.

	extension PersistentDataStore {
	func loadImage(forIdentifier identifier: Identifier, completionHandler block: @escaping (UIImage?) -> (Void)) {
	loadData(forIdentifier: identifier, dataTransformer: { UIImage(data: $0) }, completionHandler: block)
	}

	func storeImage(_ image: UIImage, identifier: String = UUID().uuidString, completionHandler handler: @escaping (Result) -> ()) {
	storeData({ image.jpegData(compressionQuality: 1.0) }, identifier: identifier, completionHandler: handler)
	}
	}

	// Examples:
	persistentStore.storeImage(image) { (result) in
	print(result)
	}

	persistentStore.loadImage(forIdentifier: "my_identifier") { (image) -> (Void) in
	guard let image = image else {
	print("Failed loading image.")
	return
	}
	print(image)
	}

view raw PersistentDataStore+Image.swift hosted with ❤ by GitHub

Summary

We created a persistent data store what is performant and has a flexible API. API can be extended easily to support any other data transformation. In addition, it uses thread-safe techniques for making sure data never gets corrupted.

Playground

PersistentDataStore (GitHub) Xcode 10, Swift 4.2

References

DispatchQueues (Apple)
dispatch_barrier_async (Apple)