Is it possible to build an asynchronous image downloading mechanism for UITableViews with just NSURLSession? How?

Question

I want to build an image downloader for my UITableView so images can be loaded asynchronously into the table view.

With NSURLSession automatically using NSURLCache to cache HTTP requests, will I be able to depend on that solely as my caching mechanism? I notice many use NSCache to save the downloaded image, but if NSURLSession already implements a cache, is that necessary? If anything, isn't it bad, as I'm duplicating a copy of the image in memory?

Furthermore, if it's possible, how do I use this in conjunction with UITableView? Cell reuse presents an interesting issue with assigning the result of a background transfer.

I can't simply download the image using NSURLSessionDownloadTask and in the completion block set the cell's image, as by the time it downloads the cell may have been reused and thus causing it to set it to the wrong cell.

let downloadTask = session.downloadTaskWithURL(URL, completionHandler: { location, response, error in
    var dataFetchingError: NSError? = nil
    let downloadedImage = UIImage(data: NSData.dataWithContentsOfURL(location, options: nil, error: &dataFetchingError))

    dispatch_async(dispatch_get_main_queue()) {
        // Might end up on the wrong cell
        cell.thumbnail.image = downloadedImage
    }
})

So how do I make sure that the assigned image makes its way to the correct cell, and that I'm caching these downloads properly?

I'm aware of SDWebImage and the like, but I'd like to try to solve this problem without the use of a library.

Answer 1

You can just have the final dispatch to the main queue see if the cell was still visible before updating the image cell. You can do this using cellForRowAtIndexPath (not to be confused with the similarly named UITableViewDataSource method):

dispatch_async(dispatch_get_main_queue()) {
    if let updateCell = tableView.cellForRowAtIndexPath(indexPath) as? MyCell {
        updateCell.thumbnail.image = downloadedImage
    }
}

(Note, this assumes that the index path of the cell cannot possibly change while the asynchronous update is in progress. If it's possible that you can insert/delete rows while the update is in progress, you should not just use the old indexPath, but rather go back to the model and recalculate the appropriate index path for this cell.)

Obviously, those UIImageView categories offer other advantages besides just updating the image view asynchronously. For example, if the cell is reused, these categories will cancel any old pending network requests for that cell. This is important so that if you scroll quickly, the currently visible cells will otherwise get backlogged behind download requests for cells that may have long since scrolled out of view.

But if you're only concerned about the making sure that a cell is still visible before updating the image, the above should address that.

---

Regarding your cache question, there are two different types of cache to discuss: RAM cache and persistent storage cache. Both SDWebImage and AFNetworking UIImageView categories implemented their own RAM cache (using NSCache) for performance. For persistent storage caching, though, SDWebImage implemented their own, and AFNetworking argued that one should rely on the built-in NSURLCache for that. I'm sympathetic to the SDWebImage perspective because (a) historically NSURLConnection caching to persistent storage on iOS was inconsistent; (b) caching can easily be disturbed by the server using the wrong headers in the responses; and (c) Apple has been annoying opaque on the criteria for when something gets cached and when it doesn't.

So bottom line, there's probably a good argument to implement a NSCache mechanism if you want silky-smooth scrolling, but you might be able to get away with relying on NSURLCache for persistent storage caching.