Valueurl Binding On Large Arrays Causes Sluggish User Interface

I have a large data set (some 3500 objects) that returns from a remote server via HTTP. Currently the data is being presented in an NSCollectionView. One aspect of the data is a path pack to the server for a small image that represents the data (think thumbnail for simplicity).

Bindings works fantastically for the data that is already returned, and binding the image via a valueurl binding is easy to do. However, the user interface is very sluggish when scrolling through the data set - which makes me think that the NSCollectionView is retrieving all the image data instead of just the image data used to display the currently viewable images.

I was under the impression that Cocoa controls were smart enough to only retrieve data for the information that is actually being output to the user interface through lazy loading. This certainly seems to be the case with NSTableView - but I could be misguided on this thought.

Should valueurl binding act lazily and, moreover, should it act lazily in an NSCollectionView?

I could create a caching mechanism (in fact I already have such a thing in place for another application - see my post here if you are interested Populating NSImage with data from an asynchronous NSURLConnection) but I really don't want to go this route if I don't have to for this specific implementation as the user could potentially change data sets often and may only want small sub-sets of the data.

Any suggested approaches?

Thanks!

Update

After some 开发者_如何学Gomore testing it seems that the problem arises because a scroll action through the data set causes each image to be requested from the server. Once all the images have been passed over in the data set the response is very fast.

So question... is there any way of turning off the valueurl fetch while scrolling and turning it back on when scrolling has finished?

---

My solution is to use a custom caching mechanism like the one I already use for another application. The problem manifests itself because as you scroll past images that have not yet been downloaded, the control triggers itself to go and fetch the as yet non-downloaded files.

Once downloaded the images are available locally and therefore scrolling speed normalizes. The solution is to check to see if the image is available locally and present an alternate app-bundle graphic while the image is being downloaded in the background. Once the image has been downloaded, update the model with the image replacing the stub image that came from the bundle.

This leaves the UI in a very responsive state throughout, leaves the user with the ability to interact and allows for a custom background management of the images.

Of course it would have been nice if Cocoa id all this for me, but then what would I be left to do? :-)