20

I worked with a brilliant developer once who more or less refused to ever call reloadData() on a UICollectionView.

He even frowned upon collectionView.reloadItemsAtIndexPaths(collectionView.indexPathsForVisibleItems()), preferring instead to reload only the exact index paths that required a visual update.

I picked this up from him but am struggling to think of what problems specifically would be caused by a generic reloadData(). Of course, if you have expensive side-effects that are triggered by a reload, that's one thing. But if your data source itself is just hanging out, why not reloadData() as an easy-on-the-coding-side way of updating the collection view?

What problems will be caused by this practice?

buildsucceeded
  • 4,203
  • 4
  • 34
  • 72
  • it is not a bad practice at all – it depends on the circumstances which one is more reasonable to use; but the answer is primary opinion-based. – holex Feb 18 '16 at 09:12
  • @holex IMHO, answers are not opinion based, given the OPs clear understanding (or misunderstanding) of the matter. An answer should first _clarify_ what's going on under the hood. Then, whether a certain approach is then _faster_ than the other - can be measured. Otherwise, there are pros and cons - but I don't think there are "opinions". – CouchDeveloper Feb 18 '16 at 09:19
  • 1
    @CouchDeveloper, even if you'd measure the resources (e.g. _execution time_ or _used memory_), it is always opinion-based which is preferred better for the current situation in spite of both preferences are legit; the actual perspective defines the list of pros and cons – and there are always various perspectives. – holex Feb 18 '16 at 09:58

6 Answers6

32

No, it is not a bad practice at all.

Just a short overview, So you get your answer

UICollectionView is highly optimized, and thus only keep On-screen visible rows in memory. Now, All rows Cells are cached in Pool and are reused and not regenerated. Whenever, user scrolls the UICollectionView, it adds the just-hidden rows in Pool and reuses them for next to be visible rows.

So, when you call reloadData(), it simply updates the data in row cells, like updating the UILabel text and the update occurs only for visible cells, and the process goes on.

Now, Consider you have ten rows visible in your collection view and while calling

reloadItemsAtIndexPaths(collectionView.indexPathsForVisibleItems())

you simply update the UILabel like elements for only those items, but if you call reloadData(), you update the data for ten visible items, which doesn't make any difference as it is a very light process.

You should use reloadData() everywhere. Keep it simple and readable. Performance wise, reloadItems doesn't make any difference.

It is properly elaborated in Apple Docx

Apple Link

Call this method to reload all of the items in the collection view. This causes the collection view to discard any currently visible items and redisplay them. For efficiency, the collection view only displays those cells and supplementary views that are visible. If the collection data shrinks as a result of the reload, the collection view adjusts its scrolling offsets accordingly.

gunjot singh
  • 2,578
  • 20
  • 28
  • Nice post, thanks! FYI the new method call is: myCV.reloadItems(at: myCV.indexPathsForVisibleItems) – Lucy Oct 16 '18 at 00:59
  • Still true? Apple docs now say: *Call this method sparingly when you need to reload all of the items in the collection view.* https://developer.apple.com/documentation/uikit/uicollectionview/1618078-reloaddata – Nolan Amy Aug 29 '20 at 03:47
1

As a general refusal, I think it is exaggerated. There will be some performance gains if the table is large, and if the items are expensive to create. If the number of items per row can vary, and you reload item #317 out of 500 items, then you know that the number of items in all the previous rows hasn't change, so you don't need to recalculate that. But if you only have 20 items, it usually makes little difference.

gnasher729
  • 51,477
  • 5
  • 75
  • 98
1

reloadData and reloadItemsAtIndexPaths will only cause to recreate and redisplay the cells for rows which have an associated visible cell.

So, since the number of visible cells are usually not changing and are usually small (e.g. 5 to 20 at max), the overall work to render cells is always constant and independent on the number of items in your data model.

As opposed to reloadItemsAtIndexPaths, which selectively re-renders the specified visible cells, reloadData will update all currently visible cells, and also update the underlying and associated views when the number of items of the model has changed (e.g. adjusting scrollbar and hight of the view).

You may use reloadItemsAtIndexPaths for performance reasons - but generally, it's not required - and oftentimes not recommended, since it requires to take care about the number of items at other places in your code, too.

CouchDeveloper
  • 18,174
  • 3
  • 45
  • 67
0

This is not just in the reload method in collectionView. but the same issue with the Tableview. I don't know whether you are aware of reload method of tableview and collectionView .I am explaining overhear.

When you call reload method. OS Check for all visible cell. and call cellForRow method for all cell. It means you code perform extra thing. which are unnecessary. So it's perfect way to call reloadItemsAtIndexPaths to reload only those cell which need to update.

Suppose you collectionView having 20 visible cell. having image which is set at cellForRow Method. now you want to update the image at cell 11. if you call reload method then cellForRow will call for each and every cell. But if you use reloadItemsAtIndexPaths and only one indexPath then it will only execute cellForRow once that is for cell 11.

Crazy Developer
  • 3,464
  • 3
  • 28
  • 62
0

It's just give you some performance gain. If you have a lot of items then for reloading a few items you don't have to reload the whole CollectionView. But if you have few items then it's not that costly.

The thing is that it's a small performance gain for a few items. But it's a good practice. So, choice is yours.

Rashad
  • 11,057
  • 4
  • 45
  • 73
0

reloadData can be considered bad practice if it is called for every single small change in data. When calling reloadData, cells are recreated, there is no guarantee that every visible data item will get the same cell after reloadData. In fact they will usually not. This means that if you have long running operations in your cells like animations or touch recognizers, they can create lot of hard traceable bugs if you don't understand what is happening.

Refreshing UITableView/UICollectionView view using reloadData is desirable when changing data collection to table.

Michal Dobrodenka
  • 1,104
  • 8
  • 27