Is NSAsynchronousFetchRequest suitable for production app?

Question

Created Jun ’21

Replies 1

Boosts 0

Participants 2

NSAsynchronousFetchRequest seems like an answer to read large amount of data from CoreData, without blocking main thread.

But, it is lacking some key features, provided by NSFetchedResultsController. The key features are :-

In NSFetchedResultsControllerDelegate didChange and controllerDidChangeContent, we automatically receive a complete change information of persistence store. This enables us to implement the animation of add/delete/move/modify in collection view.
Always listen to DB changes. Whenever there is changes being written into the persistence store, NSFetchedResultsControllerDelegate didChange and controllerDidChangeContent will be triggered automatically. This enables us to ensure our UI is in sync with DB.

But, NSAsynchronousFetchRequest doesn't come with NSAsynchronousFetchedResultsController :(

I was wondering, if you were using NSAsynchronousFetchRequest, how do you implement

Animation changes on collection view?
Always listen to DB change?

My initial thought for animation changes on collection view, it seems we can utilise UICollectionViewDiffableDataSource.

But, I notice it might be highly memory inefficient to do so. We need to keep ALL NSManagedObject in memory, fire all faults during comparison. It looks like we will run out of memory, if there are many rows.

May I know, how do you achieve the following features, if you ever apply NSAsynchronousFetchRequest in production app?

Animation changes on collection view?
Always listen to DB change?

Thanks.

Boost

Answer 1

deeje OP

Jun ’21

There are several issues here.

CoreData is very specifically designed to manage memory efficiently, especially with large data sets. But you are correct that some queries can take a long time, and if performed on the main thread, can cause a hitch. When a query is performed, however, not all the data is loaded. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/FaultingandUniquing.html

When configured with NSManageObjects, DiffableDataSource uses only the object IDs to detect changes, and the snapshots currently returned by FRC (as of iOS 15 beta 1) only include .inserts, .deletes, and .moves, but not .updates. If you want to handle updates, you have to specifically call snapshot.reload or snapshot.refresh for the changes objects.

You can configure an NSFetchedResultsController to use a background NSManagedObjectContext. Any access to properties of the found objects must be done within a moc.perform { } block, or use the objectIDs to retrieve the objects on the main thread viewContext.

Another idea is to re-create the behavior of FRCs by listening to CoreData notifications directly. See https://developer.apple.com/documentation/foundation/nsnotification/name/1506884-nsmanagedobjectcontextobjectsdid

1