views:

198

answers:

3

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  A: 

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.

eman
This [stackoverflow post of mine](http://stackoverflow.com/questions/2375551/nsmanagedobjects-that-i-own-being-released-by-main-m) is about a problem where the objects would get spontaneously released (after running for 5 minutes or so). But I've encounter similar problems, point a retained pointer at an NSManagedObject and it'll not be there when you need it later.I am confused though, re "working with -[NSFetchedResultsController fetchedObjects]" -- sounds like you are suggesting working with it directly, but then you suggest new pointers which would imply working with them indirectly?
robenk
I might get what you are saying, you could do the fetch, put the result in an array, work with the array then release it (i.e. not retain anything, which my experience makes me think would work fine). But then you'd be constantly doing fetches and creating arrays all over the place which doesn't feel right either. Let me know if I am missing what you mean though.
robenk
oh crap, "-[NSFetchedResultsController fetchedObjects] objectAtIndex:" if that works I'll feel dumb
robenk
Managed objects are retained by their context. No other object can kill them unless you first delete them from the context.
TechZen
+1  A: 

(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.

TechZen
Cool, thanks for pointing out that special NSIndexPath method. I wasn't aware of its existence.
robenk
+1  A: 

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

robenk