In my experience, performance and memory based solutions are on opposite ends of the slider. You can navigate with your solution somewhere between the two, but with the disadvantage that the best solution in terms of performance, as a rule, means the worst solution based on memory, and vice versa. Hope I explained it clearly enough :)
This is how I handle the problem of lazy downloadable images:
In my application, I created ONE object, which I named GlobalImageProvider . All image requests go through this entity. Thus, I control how many threads I use to load, and I can implement a caching system (memory + local disk), all this is completely transparent for the application and with full control. By controlling the size of the cache, I can control how fast the application feels. Performance is wise, nothing beats the presence of a UIImage already created in memory. For memory reasons, you can even disable the cache.
Moreover, I can even dynamically change the number of threads while the application is running, depending on the quality of the network that I have.
To make online queries, I use NSURLConnection , but I plan to switch to something else since I read that it is losing memory.
On the view & controller side, I have AsyncImageView , which is just a UIImageView that knows how to work with GlobalImageProvider . He knows to display an activity indicator at boot time and can handle the response from GlobalImageProvider .
If you know the URL of the image that you need, all you have to do is add AsyncImageView to your screen and query GlobalImageProvider using AsyncImageView as a "handler" for that image.
If you don't like mixing data with images, you can add a ViewController between GlobalImageProvider and AsyncImageView. It receives an image response and places it in an ImageView.
Something about it, hope this helps you a bit.
Andrei Stanescu
source share