UITableView Loading Images Slowly - uitableview

Question

The TableView fetches images from parse api. However, when scrolling through the tableView, there is lag while the image is loading.
Is there is an efficient way to decrease lag? Some way to load images before (or even after) the user scrolls to the cell? I'm not too familiar with dealing with asynchronous calls.
Fetch Image Function
func fetchImage(restaurantArray: PFObject!, completionHandler: ImageCompletionHandler!){
var imageReference = restaurantArray["PhotoUploaded"] as PFFile
imageReference.getDataInBackgroundWithBlock{
(data, error) -> Void in
if (error != nil){
completionHandler(image: nil, error: error)
}else{
let image = UIImage(data: data)
completionHandler(image: image, error: nil)
}
}
}
TableView Cell
func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCellWithIdentifier("RestaurantCell", forIndexPath: indexPath) as FeedCell
cell.nameLabel.text = restaurantNames[indexPath.row]
// check if image is empty
if foodPhotoObjects.isEmpty {
} else {
self.fetchImage(self.foodPhotoObjects[indexPath.row] as? PFObject, completionHandler: {
(image, error) -> () in
if image != nil {
cell.mainRestaurantImageView.image = image
cell.mainRestaurantImageView.contentMode = .ScaleAspectFill
cell.mainRestaurantImageView.clipsToBounds = true
}else{
//alert user: no image or put placeholder image
}
})
}
return cell
}

Answer 1

You can get this functionality for free by using PFImageView, less code for you to write to achieve the desired effect. Just call loadInBackground: after setting the file property.
https://parse.com/docs/ios/api/Classes/PFImageView.html
As for UI lag, profile in Instruments to determine what is so expensive that it is causing significant noticeable lag.

Answer 2

A couple of thoughts:
You should confirm whether this completion block is running on the main thread (examine NSThread.isMainThread) and if not, make sure to dispatch the update of the image view back to the main thread, e.g. dispatch_async(dispatch_get_main_queue()) { ... }. Trying to perform updates of UIKit controls from a background thread can end up with inconsistent behavior, so make sure you're only updating the UI form the main thread.
You should consider the implications of the user quickly scrolling down and back up in the table view. Your code will result in re-fetching images previously retrieved.
Sometimes the underlying NSURLCache will handle this gracefully, caching the images for you. In other cases it will not. (Sadly, the caching of network requests is dictated by some fairly opaque criteria, and depending upon the server implementation, you might not have a lot of control over that.)
You might want to confirm your behavior, and implement your own caching (e.g. NSCache) of previously downloaded images and checking that before retrieving images again.
I would make sure to test this process in conjunction with the network link conditioner so you can confirm the behavior of the app in less than ideal environments (i.e. real-world situations).
Unrelated to your question there are two issues with updating the cell asynchronously:
If the cell scrolled out of view by the time the image retrieval completed, the cell could have been reused, and the cell may have been reused for another row in the table. (Test this by running the app with the network link conditioner degrading the network response time to something more lke a poor cellular connector.) This problem can manifest itself as a "flickering" of images or replacing images with images associated with other cells.
You generally solve this by calling tableView.cellForRowAtIndexPath(indexPath) (a UITableView method, not to be confused with the similarly named UITableViewDataSource method), which will return nil if this index path has scrolled off of the screen, and will return the UITableViewCell if the cell is visible. Use this rather than the previously established cell value when doing the final asynchronous population of the cell.
If there is any possibility that the table could have been reloaded (i.e. the data source changed) during the process of retrieving the image asynchronously, you might actually want to go back to the model, identifying the appropriate index path associated with the image you just downloaded asynchronously.
Bottom line, imagine some degenerate situation where it took a minute or so to retrieve the image (unlikely, just imagine). Think through the contingencies associated with that (the cell scrolled off and subsequently reused, the indexPath for the image might not longer be valid, etc.). Make sure you handle these contingencies gracefully.