Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Does NSFetchedResultsController make a call to the DB every time the table view asks for a new row?
Did anyone track that? Apple says it makes sure that at any given time there is an minimum of needed objects in mem, so actually that could be the only way to do it. What’s offscreen gets lost, and what’s scrolling in is fetched immediately from the persistent store. Just like anyone else would do it in -tableView:cellForRowAtIndexPath: right? Or not?
NSFetchedResultsController and Core Data in general uses a fairly complex and highly optimized behind the scenes caching system. The caches are both in memory and on disk. It is certainly not a simple case of the fetched results controller making one disk access for each row of a table.
You can think of the fetched results controller as a data structure holding the data for the table. How it manages its relationship with the logical and physical data store really isn’t relevant and in any case, it changes dynamically according to immediate conditions. If you design your data model properly, you end up optimized automatically.