Home/ Questions/Q 367067
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T13:41:34+00:00

I have setup Core Data for an iPhone app without an instance of NSFetchedResultsController.

  • 0

I have setup Core Data for an iPhone app without an instance of NSFetchedResultsController.

To do this, I created a created a model class to encapsulate all core data requests and constructing of NSFetchRequests/NSPredicates.

This kept all Core Data specific code out of my UITableViewController.

Now I want to add NSFetchedResultsController to make populating a sectioned UITableView easier.

My issue is this: In all examples I have seen the instance NSFetchedResultsController is an ivar of the UITableViewController. This leads to all NSFetchedResults statements constructed within the UITableViewController.

I feel like this is clutters the UITableViewController and adds another responsibility.

How do you deal with this?

What does your object graph look like when using NSFetchedResultsController?

Where do you construct your NSPredicates?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Update:

    I’ve gone back to constructing NSFetchedResultsControllers within the UITableViewControllers.

    I’ve also been using a category on NSManagedObjectContext for queries. Additionally, I have been putting more logic within categories on my NSmanagedObject subclasses.

    Overall, I am happy with the architecture I have been using as of late.

    Original Answer:

    I guess I’ll post my own take on the matter.

    Since NSFetchedResultsController is a Foundation class and not a UIKit class, it screams model to me.

    Same thing for NSFetchRequest.

    It seems that constructing a an NSFetchRequest relies on knowledge of the data model, which you could argue a UITableViewController should have no knowledge of.

    This leading me to several ideas about what the object graph should look like.

    One option is to subclass NSFetchedResultsController and make is like a factory class, where I return fully configured instances of NSFetchedResultsController. This keeps NSFetchRequest Construction.

    Another option is very similar, but instead of subclassing NSFetchedResultsController, I create a NSObject subclass or category that handles the same work.

    Both of these options seem to conform to MVC better than using the UITableViewController to perform those tasks.

    • 0