0

After using Core Data in several cases I just wondering in which case which solution is the best? Even fetchedResultController is extensively used and popular especially in Apple documentations my guess that's not the best solution or fit well in other cases where the code have to fetch more then one managedObject etc.. Several times it pushes developers to use two or more fetchedResultControllers which is really complicate and rigid solution. I found several beautiful and brilliantly simple solution from Marcus Zarra for the Fetch/Predicate solution, and love Jeff LaMarche's polished navigation-based fetchedResultController, but what's the real difference?

BootMaker
  • 1,639
  • 1
  • 22
  • 24
  • Compare http://stackoverflow.com/questions/13335775/core-date-concept-nsfetchedresultscontroller-vs-nsmanagedobject-objectswithfet. Is that what you are asking? – Martin R Feb 07 '13 at 08:03
  • @Martin R Your linked answer is absolutely correct and good but it emphasizes the notification/modification as a difference which is just one aspect and replaceable with NSNotification for which Zarra offered a nice solution in another [answer](http://stackoverflow.com/questions/3147122/core-data-can-nsfetchedresultscontroller-fetch-two-different-entities). Just a kickoff question: If I have a tableView with 1000+ elements to populate, both solutions just fetch the visible cells and fault the others? Which is faster? – BootMaker Feb 07 '13 at 08:46
  • 1) So your question is restricted to table views? If you don't need automatic updates then using a FRC does not make sense. - 2) A FRC is designed for driving table views and it should optimize batch sizes etc for this purpose. But I did not make performance checks yet so I cannot give a definite answer to "which is faster". If you test it yourself, add the "-com.apple.CoreData.SQLDebug 1" argument to the launch options to see what is happening on the SQLite level. – Martin R Feb 07 '13 at 09:03
  • (cont) 3) There are things a fetch request cannot do, e.g. using sorting on transient attributes or function based sort descriptors. In that cases you cannot use a FRC and it might be necessary to fetch *all* entries into an array and sort them in memory. You would have to listen for managed object change notifications then and refetch/reload the table view if necessary. - 4) So my first advice would be: If you can use a FRC, use it. – Martin R Feb 07 '13 at 09:07
  • @anktastic No comment. – BootMaker Feb 07 '13 at 13:45
  • @Martin Yes your answer is relevant especially regarding transient attributes or function based sort descriptors. What I realized more and more are the limitations of the FRC, so I rather say if there is no advantage of using FRC I rather avoid it, this is why I asked for it especially in complicate tableViews, but your standpoint could be true too. – BootMaker Feb 07 '13 at 13:55
  • One big advantage of a FRC is that animated table view updates and section grouping come for free. That alone are reasons (for me) to use a FRC if possible. – Martin R Feb 07 '13 at 14:01
  • @Martin Yes, animated modification and section handling are my clear advantages too, and all other limitations you have mentioned and a rigid design are the cost. – BootMaker Feb 07 '13 at 14:33

0 Answers0