insertRowsAtIndexPaths crashes on endUpdates in tableView:willDisplayCell:forRowAtIndexPath only if user scrolls quickly

Ok as the title suggests, I am trying to insert more rows in a uitableview when the user scrolls to the bottom of the list. The whole reason is to lazily load the data for performance reasons with a large data set.

The odd thing is that if I scroll slowly then it works fine, but if I scroll quickly then it crashes on [tableView endUpdates];

The datasource is a nsmutablearray which loads data from coredata, using a common fetchRequest. I cannot use a fetchedResultsController in my current circumstances.

The datasource count is correct before and after the insert is called. The row count (and data source count) are correct.

If I scroll slowly and later at some point scroll quickly, it crashes, with usually the same error with the index being beyond the bounds, however the index and bounds in the error message are incorrect with the original counts when the tableview was first bound (and before any insertions occured). Ie row count of 4 and datasource count of 4 & etc.

This is the error:

Termin开发者_如何学JAVAating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 3 beyond bounds [0 .. 2]'

I also tried inserting rows during the cellForRowAtIndexPath method but with the same result.

Any ideas?

---

That is not the right way to solve large data set scrolling problems.

1. The UITableView is designed to only keep a small number of cells in memory at any one time.
2. Trying to fetch data while scrolling will perform horribly as disk access is significantly slower than UI updates.

Instead you should consider limiting your batch size when fetching your data from Core Data. Secondarily you should also run instruments against your app and confirm where the hotspots are. It is highly unlikely that the scrolling or population of cells is the slow point.

BTW, an NSMutableArray is rarely useful when dealing with the results from Core Data. Unless you have a specific reason to have a NSMutableArray you should probably change it to a NSArray.

---

Is NSMutableArray prepopulated at start of the application? Currently I assume, that you use a controller object as your UITableViewDelegate that just returns the final number of rows while the NSMutableArray becomes filled up as you move along?

In that case the loading from Core Data might be too slow if you speed up your scrolling resulting in "holes" in the array.