Android - Storing images downloaded from the web

Question

I had a question related to whether or not (and how) I should store images loaded from the web. Let's say I am calling a web service from my Android app. In this web service I get a URL for an image on the web. I download and show this image on the left side of a list item in a ListView. My question is, what method should I use for possibly storing the image? Should I:

1. Save it to the SDCard, checking if it exists when the ListView is created (on subsequent requests) and re-downloading as necessary (while updating the image occasionally, in case it changes).
2. Store it in the cache using Context.getCacheDir(), but possibly being forced to re-download it more often since I cannot rely on the image staying in the cache.
3. Always download it and never store the image.

The image files themselves are fairly small, but I expect some users could have dozens of these small images downloaded/stored. Which would work best, and/or what is the preferred method?

As a side question, should I load all of the images in my ListView first (and possibly lock the UI for some time) or load them asynchronously but show a placeholder graphic in the meantime (which might be a bit more "ugly")? What's the standard here?

Answer 1

About where to store: The answer depends on what is being downloaded and how much. Then you make a choice.

For instance: If you are downloading something that is temporary, less in number(less remote fetches) and size(less memory) and is local to an Activity then you should consider holding the images in memory using SoftReferences. SoftReferences can lead to refetches but since the number of items is small it should be affordable.

However, if the number of items to be downloaded exceeds a certain threshold(meaning more fetches and memory) you should consider reducing the fetches and also the Runtime memory consumption by caching them. Here you can either choose to save them on Sdcard or on temporary storage(cache directories local to app). For items that are small and hold meaning only in the context of Application(e.g thumbnails), the user will mostly not use it outside of your application. So, you can store such things in the cache directory. The best part of using them is that you don't have to clean the mess. It is handled automatically. It might lead to re-fetches though.

However, if the downloaded items are large in size and can stand alone outside the context of the application such as pictures, video, audio clips then SDcard should be your option. You should also read: Handling large Bitmaps to avoid OOM error during BitmapFactory.decodeStream(..)

Note that you can also check to see if using a database can help here.See this

Some considerations while lazy loading items in a ListView: You should do the loading in the background and not block the UI thread.You should consider showing a temporary image while the item is being downloaded. This is apparent in many native applications. For an example implementation of lazy loading see this. Additionally, for large lists, you can implement the SlowAdapter pattern(check API demos). It basically stalls download while the list is scrolling.

Example Projects that can help you here:

Romain Guy's Shelves project uses two level of caching wherein he employs an in-memory cache(HashMap containing SoftReferences) and storage on Sdcard.Browse Source code here

There are also some open source libraries that Mark Murphy wrote(CWAC) and DroidFu that can help here.

Good Luck!

Answer 2

In regards to your "side question" -- I think that loading them asynchronously would be the preferred behavior, especially since you need to consider that with network transactions, it might not just be "lock the UI for some time", but "lock the UI permanently" in case it never loads.

If you consider this behavior ugly, though, you could set a timer (1 or 2 seconds) that gives a few of the images a chance to load, and if they have all loaded or the timer has expired, go ahead and show the UI anyway with placeholder images and let the rest load asynchronously. This would be the way to go to prevent permanent locks anyway.

As for the first part of your question, I think it is somewhat dependent on the context and type of images you are displaying. With most web assets, though, I think #2 would be the preferred approach, since you certainly don't want to download multiple times in the same session, but you probably don't want to eat up permanent storage either.

Answer 3

In regards to your "side question" -- I think that loading them asynchronously would be the preferred behavior, especially since you need to consider that with network transactions, it might not just be "lock the UI for some time", but "lock the UI permanently" in case it never loads.

To avoid this , If we are talking about WebImageView by droid-fu you can change the ImageLoader.java initialize() function to this

    static int alive=-1;
   public static synchronized void initialize(Context context) {

        if (executor == null) {        
           executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(DEFAULT_POOL_SIZE);           
       }
        else if(alive==executor.getActiveCount()){
               executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(DEFAULT_POOL_SIZE);
           }
       alive=executor.getActiveCount();
       if (imageCache == null) {
           imageCache = new ImageCacheHope(context, 25, 5);
       }
   }

Answer 4

I wrote an Android Image Manager that handles caching transparently (memory and disk). The code is on Github https://github.com/felipecsl/Android-ImageManager