At the moment, the image cache doesn't do a good job handling out-of-memory conditions. It occasionally causes an Activity to crash due to memory consumption.

Some tests should be created and memory usage should be profiled to see where it can best be optimized.

If an image URL resolves to a 404, it shouldn't pound on the server trying to download it. Instead, it should have a sane timeout for when it should retry.

This can possibly be done using the LastUpdatedMap in MelAUtils.

Instead of attempting to resize a huge image and causing an OOM error, the library should check to see if it's a reasonable size to scale and go from there.

The idea of a "reasonable size" should be determined empirically based on actual memory consumption for resizing an image using the resize technique used in the library.

It's also possible that resizing a huge image is fairly efficient and that this sanity check is unnecessary.

Hey,

great project. I just think I found a minor documentation error, which took me some to figure out.
In
https://github.com/mitmel/Android-Image-Cache/blob/master/src/edu/mit/mobile/android/imagecache/ImageLoaderAdapter.java#L43
it should say "ImageView#getTag(R.id.ic__uri)" instead of "ImageView#getTag(R.id.ic__load_id)"

At the moment, the image cache doesn't actually do any cleanup of its cache. This should be fixed, perhaps with some state persistence using file access times or something like that.

So that images that get cached are updated, standard HTTP caching techniques should be employed to ensure that they aren't out of date.

This includes conditional HTTP headers, e-tag storing and last-modified storing. The metadata should be stored in a way that hitting the "clear cache" button in the system UI will clear the database too.

It may even make sense to look into using a proper HTTP caching library for this part, while still using this for any resized derivatives. This library will still need to know when to refresh derivatives, so it may need to communicate with the cache.