Android Developer

Los Angeles Freelance Developer

Android Developer header image 2

Introducing EssentialsLoader

May 6th, 2013 · 4 Comments · Android, EssentialsLoader, OOP

Allow me to introduce EssentialsLoader. EssentialsLoader is my image loading (lazy loading) system that I’ve been using for sometime now. It’s part of the Essentials tools (along with EssentialsLogger) that I’ve created and decided to release publicly. So why did I create my own image loading system when there are others out there such as Loading Large Bitmaps Efficiently from Google? EssentialsLoader address a couple of important issues which most other systems were not handling to my liking.

First, EssentialsLoader decouples the view from the loading process. What does this mean? Take for instance Google’s lib that I linked to above. You are required to reference an ImageView to load a bitmap. Now that’s just down right silly. So to use their lib I’m forced to use an ImageView and I have no control over how or where the loaded image will go! I can’t change the drawable shape; I can’t set it to be a background; I can’t set the scale type on load; and I don’t get a Callback for when it has loaded. But back to my original point. A loading system should not make the assumption of how the loaded image will be used. EssentialsLoader decouples this process and you are free to use the loaded bitmap however you’d like.

Secondly, most loading system do not expose the cache. They are often created internally and you have no way to access them. What if you wanted to share the disk cache across loaders but not the memory cache or vise versa? Or what if you wanted a custom type of cache allowing you to cache and/or reject Bitmaps at your whim? EssentialsLoader allows you to do this by passing in the cache of your choosing in the constructor.

The lack of a good and architecturally flexible system has frustrated me for sometime now (along with the lack of a HorizontalListView….come on guys…). I’m hoping EssentailsLoader can start filling in this void. This post was more of an introduction and I don’t have any follow up post in mind to elaborate on it. So go check out the samples and if there’s an architectural point you’d like for me to address in a blog post feel free to send me a message or leave a comment.

Happy loading!

Tags: ······

4 responses so far ↓

  • 1 Kiran Rao // May 7, 2013 at 2:39 am

    This is a great library. I was considering working on something similar since I wanted to use bitmap caching but then not put them in ImageViews. I had varied uses for cached bitmaps including using them in LevelListDrawables, drawing them on canvas etc.

    While EssentialsLoader solves these problems, there is one limitation which prevents me from using it: As far as I can tell, the library assumes that the images always come from the web. In my case, the images are resources packaged with my app in drawable-*dpi folders.

    Why would anyone want to cache resource bitmaps? Well, I have about 20 bitmaps of up to 640*640 pixels to display some graphics in my app. This is in one “tab”. The same graphics is repeated in a viewpager. You do the math.

    I don’t want the resources to be decoded every time the orientation is changed or when I swipe between the pages.

    I have created a custom solution on top of Chris Banes’ Android-Bitmap-Cache library. I currently have no plans of working on extracting it into an open source library. But it would help others if you added the feature to EssentialsLoader.

    Basically what you want is in addition to loading from a URL, you need to allow decoding from resource, from file and as raw.

  • 2 musselwhizzle // May 7, 2013 at 1:42 pm

    Hi Kiran, Thanks for the post and feedback. I’ve never had a need for what you described so I’ve just never done it, but maybe that’ll be a good weekend project for me. My initial thoughts are to either add more “load” methods or just make a subclass which handles non-http images. Since the caches are externals they could be shared between a http loader and a url loader. Just kind of free thinking and typing…..

  • 3 Kiran Rao // May 14, 2013 at 10:11 am

    From the top of my head, I don’t see any downsides with the “add more load methods” approach. For every load method that takes a URL as parameter, you’d just need to add a couple more:

    1) One that takes an integer representing the drawable resource ID as parameter. The implementation of this method would use BitmapFactory.decodeResource instead of using an HTTP client to download the image

    2) One that takes a File Path as parameter. The implementation of this would use BitmapFactory.decodeFile

    As you mentioned, the great thing about the architecture of EssentialsLoader is that the caches are external – this makes sharing the caches trivial!

  • 4 Bill Donahue // Jul 17, 2013 at 6:30 pm

    Another interesting post. I too found all the image loading libraries where lacking and wrote my own that was based on Googles lazy loading tutorial sample project. Unfortunately I wrote it for a company that later decided against open sourcing it.

    I have however also written a HorizontalListView that is stable and used in an application with a few million users that may be of some use to you.

Leave a Comment