
Automatic Remote Image Loading In an iOS Table View Controller - jamesjyu
http://blog.parse.com/2012/07/12/loading-remote-images-in-a-table-view/
======
sunsu
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>

~~~
andwang
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!

------
thathoo
How is this better than SDWebImage or AFNetworking libraries? Any quick
comparisons?

~~~
andwang
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.

~~~
jazzychad
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.

~~~
matthavener
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...](http://petersteinberger.com/blog/2012/nsurlcache-uses-a-disk-cache-
as-of-ios5/)

~~~
jazzychad
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...

~~~
matttthompson
NSURLCache does disk caching in iOS 5 and up, but only for http (no https)
requests. Use SDURLCache if you want more options there.

------
geon
@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...](https://github.com/geon/UIImageViewCached/blob/82c8b56564f8aaa128dd905eed392896ea962890/UIImageViewCached/UIImageView%2BCached.m)

I also implemented an optional spinner, which works better than a placeholder
for larger-than-icon images.

------
jazzychad
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?

~~~
andwang
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.

~~~
jazzychad
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...

~~~
andwang
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.

