TL;DR
- Take the
visible
in function names literally.
- UITableView behaves just as it did in iOS 9.
- You'll need to do some bookkeeping if you want to treat loaded vs. visible cells differently in UICollectionView on iOS 10.
UITableView and UICollectionView appear to behave very differently when it comes to prefetching.
First thing to notice is that there is a difference between prefetching cells and prefetching data:
- Prefetching cells refers to the
cellForRowAtIndexPath
being called before the cell is actually displayed on screen. This enables the scenario where you have cells that are off-screen but still loaded.
- Prefetching data refers to the
prefetchDataSource
methods which inform you about indexPaths
that are going to be displayed on screen. You do not have a reference to the cell when this method is called, and you do not return a cell when this method is called. Instead, this method should do things like fire off a network request to download an image that will be displayed in the cell.
Note: In all of these scenarios, imagine there are 8 cells that can be displayed at any given time.
UITableView: (options: no prefetching
, or prefetch data
)
- Does not prefetch cells, ever. In other words, it will never call
cellForRowAtIndexPath
on an indexPath
that isn't displayed.
- As such, there is no
isPrefetchingEnabled
property on a UITableView.
- You can opt-in to prefetching data by using the
prefetchDataSource
.
- Note that although the table view does seem to be less aggressive with reusing cells, it still appears to call
cellForItemAtIndexPath
when the reused cell comes back on screen. (Although I may need to do some more investigation as to this, especially for collection views.)
UICollectionView: (options: no prefetching
, prefetch cells
, or prefetch cells and data
)
- Prefetches cells by default. In other words, it will call
cellForItemAtIndexPath
for cells that aren't going to be immediately displayed.
- The prefetching of cells only begins when the user scrolls up or down on the collection view. In other words, you will get exactly 8 calls to
cellForItemAtIndexPath
when the view is loaded. Only once the user scrolls down will it start asking for non-visible cells (e.g. if you scrolled down to show 2-10, it might ask for 11-14).
- When the prefetched, non-visible cell comes on screen, it's not going to call
cellForItemAtIndexPath
again. It's going to assume that instantiation you did the first time is still valid.
- You can opt-in to prefetching data by using the
prefetchDataSource
.
- The
prefetchDataSource
turns out to be only useful for the initial load. In the same scenario above, when the first 8 cells are displayed, it may fire off a prefetching of data for cells 9-14, for example. However, once this initial method is called, it's useless thereafter. This is because cellForItemAtIndexPath
is going to be called immediately after each call to prefetchItemsAt
. For example, you'll get prefetchItemsAt:[14, 15]
immediately followed by cellForItemAt:14
, cellForItemAt:15
.
- You can opt-out of all prefetching behavior by setting
isPrefetchingEnabled = false
. This means you can't make a UICollectionView behave similarly to a UITableView with a prefetchDataSource
. Or, in other words, you can not have a UICollectionView prefetch data
only.
For both:
visibleCells
, indexPathsForVisibleRows
, and cellForItemAtIndexPath
do exactly as they say: they only deal with visible cells. In our same scenario, if we have 20 cells loaded, but only 8 are visible on screen. All 3 of these methods will only report about the 8 on-screen cells.
So what does this mean?
- If you're using a UITableView, you can use it as is and never have to worry about a difference between loaded vs. visible cells. They are always equivalent.
- For UICollectionView, on the other hand, you're gonna need to do some book-keeping to keep track of loaded, non-visible cells vs. visible cells if you care about this difference. You can do this by looking at some of the methods on the data source and delegate methods (e.g. willDisplayCell, didEndDisplayingCell).