I'm developing an iPhone application that makes heavy use of Core Data, primarily for its database-like features (such as the ability to set a sort order or predicate on fetch requests). I'm presenting all the data I fetch in various UITableViewControllers.
What I'd like to know is a rough idea of how many objects I can fetch before it becomes a good idea to use an NSFetchedResultsController to handle the request. In the Core Data docs, it says that SQLite stores consider "10,000 objects to be a fairly small data set," but in the documentation for NSFetchedResultsController it mentions keeping "tens of objects" in memory at a time.
I'm dealing primarily with data sets of up to fifty objects that each have maybe a dozen instances of NSNumber and NSString, as well as a one-to-many relationship for the next set of objects (i.e. there are twenty instances of object A, each of which have a to-many relationship to a set of thirty (distinct) instances of object B, each of which...).
Is this scenario a good fit for using an NSFetchedResultsController, or can I get away with a simple NSArray of results? I don't have an issue with managing the niceties of the controller (convenience methods to get an object for a UITableView index path, adding new objects back to the context, etc.) myself, I'm just wondering about the memory usage of each approach.
I should mention the app will be targeted primarily at iPhone 3G (not S) and first-gen iPod Touch users, so please keep the limited memory of these platforms in mind.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…