Question

Does anyone have an example of how to efficiently provide a UITableView with data from a Core Data model, preferable including the use of sections (via a referenced property), without the use of NSFetchedResultsController?

How was this done before NSFetchedResultsController became available? Ideally the sample should only get the data that’s being viewed and make extra requests when necessary.

Thanks,

Tim

Answer 1

For the record, I agree with CommaToast that there’s at best a very limited set of reasons to implement an alternative version of NSFetchedResultsController. Indeed I’m unable to think of an occasion when I would advocate doing so.

That being said, for the purpose of education, I’d imagine that:

• upon creation, NSFetchedResultsController runs the relevant NSFetchRequest against the managed object context to create the initial result set;
• subsequently — if it has a delegate — it listens for NSManagedObjectContextObjectsDidChangeNotification from the managed object context. Upon receiving that notification it updates its result set.

Fetch requests sit atop predicates and predicates can’t always be broken down into the keys they reference (eg, if you create one via predicateWithBlock:). Furthermore although the inserted and deleted lists are quite explicit, the list of changed objects doesn’t provide clues as to how those objects have changed. So I’d imagine it just reruns the predicate supplied in the fetch request against the combined set of changed and inserted records, then suitably accumulates the results, dropping anything from the deleted set that it did previously consider a result.

There are probably more efficient things you could do whenever dealing with a fetch request with a fetch limit. Obvious observations, straight off the top of my head:

• if you already had enough objects, none of those were deleted or modified and none of the newly inserted or modified objects have a higher sort position than the objects you had then there’s obviously no changes to propagate and you needn’t run a new query;
• even if you’ve lost some of the objects you had, if you kept whichever was lowest then you’ve got an upper bound for everything that didn’t change, so if the changed and inserted ones together with those you already had make more then enough then you can also avoid a new query.

The logical extension would seem to be that you need re-interrogate the managed object context only if you come out in a position where the deletions, insertions and changes modify your sorted list so that — before you chop it down to the given fetch limit — the bottom object isn’t one you had from last time. The reasoning being that you don’t already know anything about the stored objects you don’t have hold of versus the insertions and modifications; you only know about how those you don’t have hold of compare to those you previously had.