After some more testing with Volley and a few emails from readers I have modified the Volley image cache demo to include an in-memory L1 cache. I have also updated the blog post to reflect the change. Rather than expound on the reasons for the change in the original post I have chosen to go over the logic here so as to avoid muddying the intentions of the original post.
When I originally started playing with Volley I did not fully understand how the developers intended for image caching to work. As I have already indicated in the full blog, I found it quite odd that the ImageLoader required an ImageCache implementation but there was no real clear direction in the presentation or (non-existent) documentation as to how that was supposed to behave. It was also not completely clear if the L2 disk cache used to cache the HTTP requests was also being used to cache the images themselves.
I went down the road of adding the original image cache after seeing several requests for a demonstration of how a disk cache might work in Volley. Unfortunately, we were all missing the forest for the trees as it appears we already get disk caching for free. What we do not get, but what Volley requires, is an in-memory L1 cache implementation.
The end result is that I have added a BitmapLruImageCache to the demo. You can still configure the demo to run off of the disk based cache, but you may very well run into i/o blocking issues. I would still like to see the L1 cache be made optional because quite frequently a disk based cache will be good enough to get the job done (provided it is written in a non-blocking way as the default Volley implementation is). You can see the new cache creation in the init below: