iOS 10: Collection View Data Prefetching | Ray Wenderlich

🎓 Courses & Articles
1

Discover how to preload data for your table and collection views using the new data prefetching APIs.

This is a companion discussion topic for the original entry at https://www.raywenderlich.com/5000-ios-10-collection-view-data-prefetching
2

It’s great for the case of scrolling down. However, when scrolling back and upside, it’s sad to see it is once again loading.

3

Hi @jackyccaa

I’m not entirely sure I understand what you mean? Do you mean that the data preloading process doesn’t work when you scroll upwards?

Part of this implementation requires the system to predict which cells you’ll need next. Since it cannot predict a change in scroll direction, it appears always to err on the expectation that the user will continue to scroll downwards.

Is this the phenomenon you’re referring to? The good thing is the the new prefetching behaviour will never be worse than the pre-iOS 10 behaviour. And in many cases it will be much improved.

Hope that helps

sam

4

Thanks.

What I tried to express is:

A typical scene
You scroll down couple pages, then you scroll up again.

Expected behavior
When you scroll up again, it should not be necessary again to load again since you are on the way back.
That is to say, as long as it has been loaded, it should be cached and never see the loading indicator regardless up/down direction.

5

Hi @jackyccaa

The collection (or table) view doesn’t perform any caching itself - once the cell has scrolled off the screen, it is reused elsewhere.

The implementation of the datasource shown in this project specifically doesn’t include caching. This was as a way to demonstrate the prefetching behaviour in a demo scenario. It’s a lot more difficult to demo prefetching if everything is cached as soon as it is loaded.

It should be pretty simple to cache the data as it successfully downloaded - in fact, a really simplistic implementation could just keep the Operation objects around in the dictionary, and then nothing else would need to change to support the kind of caching you’re talking about.

A more thorough treatment of caching could ensure that just the data is cached, and include some kind of memory limiting procedure, to ensure that old items in the cache are purged when the cache gets too large.

Hope that helps

sam

6

Very good intro about prefetching in iOS 10. For those who wants to know more, I recommend to watch the WWDC video about the new API: What's New in UICollectionView in iOS 10 - WWDC16 - Videos - Apple Developer :slight_smile:

1 Like
7

@fabiwerneck Thanks for the recommendation. Unfortunately the documentation is pretty empty at the moment, so the WWDC video is the best place to go. Hopefully that’ll be resolved some time soon.

sam

8

In my consideration of the topic, I considered that behind the scenes the NSURLCache can be caching what one is pulling from the network and we can tweak the size of this (for example in our appdelegate), but it’s not the best solution (by itself). Creating one’s own image cache using NSCache can work well, and again similarly, we can define the size of this and it can kick out elements when it gets to capacity. If we know that the number of images we are downloading is limited we could permanently store images locally indexed by url, which means that we never need download the same image twice, and we know we need to download anything with a novel URL not previously seen (again this doesn’t really work where we have a large number of images to load).