Automatic Remote Image Loading In an iOS Table View Controller(blog.parse.com)
blog.parse.com
Automatic Remote Image Loading In an iOS Table View Controller
http://blog.parse.com/2012/07/12/loading-remote-images-in-a-table-view/
5 comments
I suggested this feature on the last HN article when they announced Parse powered Table Views. No one seemed to think it was a good idea then, but I'm very glad parse decided to implement it! Reference: https://news.ycombinator.com/item?id=3401887
Sunsu, thanks for the awesome feedback. We do think this is a great addition. After all, PFQueryTableViewController is about loading data stored on Parse; and if a developer has images stored on Parse, we should be able to load them and display them in the controller.
Let me know what other things would be great to have!
How is this better than SDWebImage or AFNetworking libraries? Any quick comparisons?
I have not seen SDWebImage. From what I can recall about AFNetworking (a fantastic library, by the way), it provides a category on UIImageView whose methods can download and display web images. I don't think it provides any help for loading images in a UITableViewController context. In other words, the app developer still needs to state what URL to load and when to load the images. With PFQueryTableViewController, you just state which image each cell should load, and the loading is managed by the controller.
SDWebImage provides a nifty category extension UIImageView+WebCache which provides a setImageWithURL:placeholderImage: method on UIImageViews and uses the SDWebImageCache to cache the images locally for you. It is excellent and I use it everywhere.
AFNetworking provides a similar category extension, but there is no obvious way to make it use an ondisk cache that survives app restarts, so its caching is not as useful as SDWebImage's.
AFNetworking provides a similar category extension, but there is no obvious way to make it use an ondisk cache that survives app restarts, so its caching is not as useful as SDWebImage's.
I could be wrong, but as of iOS5, NSURLConnection does disk caching by default, and therefore so does AFNetworking. Source: http://petersteinberger.com/blog/2012/nsurlcache-uses-a-disk...
Yes, There is disk caching for NSURLConnection by default, but in my experience it does not cache it across app restarts, so each time the app starts again all the images have to be fetched all over again... SDWebImage gives the persistent disk caching I want.
If I'm misunderstanding what's happening please let me know...
If I'm misunderstanding what's happening please let me know...
NSURLCache does disk caching in iOS 5 and up, but only for http (no https) requests. Use SDURLCache if you want more options there.
Just glanced through SDWebImage's source code. Think this is quite similar to AFNetworking's UIImageView category. My comment below should also apply here.
In the Parse framework, the equivalent class is PFImageView. We chose to design our API differently; from my experience, I believe the assignment of the web image to load and the actual download of the images should be two different steps. This is evident in UITableViewController. In tableView:objectForRowAtIndexPath:, the app developer should know which URL to load, but we should not load the images at this point. Although you CAN achieve the same goal via the other two libraries' API, I feel strongly the API becomes more intuitive to use when the two steps are broken apart.
In the Parse framework, the equivalent class is PFImageView. We chose to design our API differently; from my experience, I believe the assignment of the web image to load and the actual download of the images should be two different steps. This is evident in UITableViewController. In tableView:objectForRowAtIndexPath:, the app developer should know which URL to load, but we should not load the images at this point. Although you CAN achieve the same goal via the other two libraries' API, I feel strongly the API becomes more intuitive to use when the two steps are broken apart.
By the looks of it, Parse is still downloading the image as the table view scrolls (that would be only reasonable). The behavior of not displaying until the table stops moving would appear to be a shortcoming of Parse not executing its operation using NSRunLoopCommonModes. AFNetworking gets this right.
Hi Mattt, in PFQueryTableViewController, the downloading does not start until the scrolling stops. We chose to do this because we wanted the default loading behavior to be very passive. You could verify this is indeed the behavior from the animated gif - the network activity does not start until the table finished scrolling.
@andwang
May I suggest you (optionally) animate the images to fade in instead of just switching them. This avoids the visual "popping", and really makes it look more polished.
I wrote/adapted something similar for my app a while ago:
https://github.com/geon/UIImageViewCached/blob/82c8b56564f8a...
I also implemented an optional spinner, which works better than a placeholder for larger-than-icon images.
May I suggest you (optionally) animate the images to fade in instead of just switching them. This avoids the visual "popping", and really makes it look more polished.
I wrote/adapted something similar for my app a while ago:
https://github.com/geon/UIImageViewCached/blob/82c8b56564f8a...
I also implemented an optional spinner, which works better than a placeholder for larger-than-icon images.
Does this load images as the table is scrolling? Or only loads onscreen images when the scrolling stops? Do I have any control over which behavior I want?
Currently, it loads the onscreen images when the scrolling stops (which is a non-aggressive loading behavior). If you wish to be more aggressive about loading the images, i.e. loads the images when the scrolling starts to decelerate, or loads the images as soon as the table scrolls (very aggressive), you can fine control the loading behavior via the loadInBackground method in PFImageView (the PFTableViewCell has a PFImageView as its imageView property).
In designing the API, I debated whether I should introduce a property that lets developer specify a loading behavior from a default set. I chose not to expose it for now and wait for some feedback; if this is a commonly asked feature, I can always introduce it later. I find, in the personal apps I build, this loading behavior is sufficient for 90% of them. Would love to hear others' feedback, though.
In designing the API, I debated whether I should introduce a property that lets developer specify a loading behavior from a default set. I chose not to expose it for now and wait for some feedback; if this is a commonly asked feature, I can always introduce it later. I find, in the personal apps I build, this loading behavior is sufficient for 90% of them. Would love to hear others' feedback, though.
Cool, thanks for the info, makes sense. I also prefer to do non-aggressive loading as a dev, but for some of my apps I got lots of feedback from users that loading images that way "felt slow and laggy" since they are used to aggressive loading in other apps...
Exactly. To be aggressive in loading is kind of risky since doing it poorly can lead to a non-responsive behavior in the app. App developers can always choose to be more aggressive if the default behavior is not aggressive enough, but if the framework chooses to be overly aggressive, it prohibits some apps from adopting the framework.
[deleted]