0

So I am using a UICollectionView with an NSFetchedResultsController with cache (leaning on Ash Furrow's implementation https://github.com/AshFurrow/UICollectionView-NSFetchedResultsController). Everything is functional, but I'm getting sluggish response due to what seems like redundant cycling of the uicollectionviewcontroller delegates.

This is what I'm doing: Every few seconds, I am inserting a new entity into the managedObjectContext. Each entity ends up in it's own section based on the value of section key attribute when fetched. Each entity has 22 different attributes that end up being presented in 22 new cells (rows) for the entity section.

This is what is happening: My NSFetchedResultsController delegates appear to working as expected (they capture the single section entry). When I end up running the batch updates, it calls cellForItemAtIndexPath for only the new entity (as expected). BUT (and this is MY ISSUE) the UICollectionViewController cycles through numberOfItemsInSection and sizeForItemAtIndexPath (I have different sized cells for the 22 new cells) for every single existing section. Isn't this cached? Don't we already know this? Any ideas why this is happening? I'm a noob, so am I misunderstanding something fundamental here? Am I fundamentally implementing the sections and rows of the collectionView incorrectly?

And the end result is that the extra cycles become very expensive as the number of entities/sections increase and the ui quickly becomes too staggeringly sluggish to be acceptable/usable.

Ideas?

UPDATE: REASONING FOUND So I guess I needed to delve deeper into the implications of using custom cell formatting calls in my delegate. I don't really understand why this needs to be so costly (calling it on every row not just those in view), but it is.
heightForRowAtIndexPath being called for all rows & how many rows in a UITableView before performance issues?

Community
  • 1
  • 1
jaypee
  • 75
  • 1
  • 5
  • http://stackoverflow.com/questions/5324205/heightforrowatindexpath-being-called-for-all-row-how-many-rows-in-a-uitablevie – jaypee May 09 '13 at 20:56

1 Answers1

0

So I guess I needed to delve deeper into the implications of using custom cell formatting calls in my delegate. I don't really understand why this needs to be so costly (calling it on every row not just those in view), but it is.

This SO thread talks about it: heightForRowAtIndexPath being called for all rows & how many rows in a UITableView before performance issues?

Community
  • 1
  • 1
jaypee
  • 75
  • 1
  • 5
  • The reason for its need to be called on every row (even those outside the tableview) is so it can know how big the table view contentSize should be. It can't know where to display the scroller if it doesn't know the full height of the table view. As of iOS 7 though, you can approximate the height for improved performance. – Accatyyc Aug 02 '13 at 08:37