Using an NSFetchedResultsController without a UITa

2020-07-18 03:58发布

问题:

I'm running into problems trying to use a NSFetchedResultsController without a corresponding UITableViewController.

According to Apples documentation:

"NSFetchedResultsController is intended to efficiently manage the results returned from a Core Data fetch request to provide data for a UITableView object."

So I first researched whether using the NSFetchedResultsController without a UITableViewController was advisable and encounter this Stackoverflow post where it is concluded that, at least in some circumstances, it's not a bad idea.

But now I've encountered an issue where the NSFetchedResultsController behaves differently when a corresponding UITableViewController isn't present. The problem is when a UITableViewController is not present, the objects returned by the NSFetchedResultsController do not have IndexPaths. I've documented this problem in a stackoverflow post. (Note this is a simplification of the issue, in some circumstances the objects do have IndexPaths, but I've encountered enough problems to believe that expecting IndexPaths without a UITableViewController is a bad idea.)

Without IndexPaths, I can't access the returned objects in their sort order, and I can't access specific objects. So what I am looking for is either a way to get the NSFetchedResults controller to return objects with IndexPaths, or an alternative way to access the objects. (Or perhaps I shouldn't be using an NSFetchedResultsController at all?)

Re alternative methods, one work around would be to pass the fetchedObjects to an array, and then work with that array. But in my experience creating new pointers to FRC objects always causes problems. I think every time I've ever tried to retain an NSManagedObject with my own pointers it has eventually caused a bug.

FYI, what I am trying to create is a navigation bar similar to the navigation bar in Photos. If you imagined you could dynamically add photos to the Photos application, then it would make sense for the photos in the bar to managed by an NSFetchedResultsController -- so that adding a new photo would be dynamically added to the end of the bar, much like how adding a new object is dynamically added to a UITableView.

Thanks for any ideas you might be able to help me out with!

UPDATE this issue is (tentatively) solved by using -[NSFetchedResultsController fetchedObjects] objectAtIndex:]

回答1:

This is solved by using -[NSFetchedResultsController fetchedObjects] objectAtIndex:]

NSFetchedResultsController behaves as a collection of managed objects, similar to an NSArray, which makes it easy to use. In fact, it exposes a read-only property called fetchedObjects that is of type NSArray to make things even easier to access the objects it fetches.



回答2:

Is there anything wrong with working with -[NSFetchedResultsController fetchedObjects]? I'm not quite sure what you mean when you say you running into problems creating new pointers and retaining them--could you explain more? You shouldn't usually have to retain NSManagedObjects (they're fetched and faulted as needed), so that might be the issue.



回答3:

(Note this is a simplification of the issue, in some circumstances the objects do have IndexPaths, but I've encountered enough problems to believe that expecting IndexPaths without a UITableViewController is a bad idea.)

Both UITableView and NSFetchedResultsController use the NSIndexPath UIKit Additions extensions to NSIndexPath. That extended class generates indexPaths with explicit section and row attribute. These paths should be manually created using:

+[NSIndexPath indexPathForRow:inSection:]

If you use other methods to create the indexPath, the receivers have to infer the section and row attributes. They will usually infer correctly but the possibility of error remains.