__TLIndexPathDataModelNilSectionName__ when rebuilding data model about tlindexpathtools HOT 2 CLOSED

some performance issues with the data model

TLIPT shouldn't have performance issues with 700 items. However, we've experienced performance issues with UICollectionView's internal batch update process when the number of items gets that large. UICollectionView just can't handle large batch updates.

Did you specifically identify a performance problem within the TLIPT code?

So I figured that just clearing out the collection view and then rebuilding it would make it faster, and it does.

The way we've handled this problem is to use [UITableView reloadData] instead of performing batch updates. We did this inside a [UIView transitionWithView] with a page flip animation.

It sounds like what you're trying to do is perform one batch update from your old data model to an empty date model, followed by another batch update from the empty data model to the new data model. Is that right?

Here's what happening. If TLIPT can't determine the section name for an item, then it puts it in a section with the internal name TLIndexPathDataModelNilSectionName. There is a bug in UICollectionView that crashes if you try to load the view with zero sections. So TLIndexPathDataModel has a workaround of creating an empty section using the internal section name. Here are the comments from the code:

if there are no sections, insert an empty section to keep UICollectionView
happy. If we don't do this, UICollectionView will crash on the first
update because it internally thinks there is 1 section when the
UICollectionView controller reports zero sections.

I have not checked if that bug still exists in iOS8. I'll put that on my todo list.

My recommendation, and what I've done in the past, is to set up your delegate to return a blank view or zero size for that section. Or you could try setting the data model to nil and see if the collection view crash bug has been fixed. As I recall, the bug only happened on the first update, so it might not affect you at all.

from tlindexpathtools.

The code is indeed only slow when it has to move around all the items. The comment in that bit of code (https://github.com/wtmoose/TLIndexPathTools/blob/master/TLIndexPathTools/Data%20Model/TLIndexPathUpdates.m#L364) also shows a better suggestion, which I didn't see until after posting this comment.

I did implement the solution based on the comment and now it works acceptably fast. Thanks for the suggestions

from tlindexpathtools.