Android: Loading images Super-Fast like WhatsApp – Part 1

Zingoo is a new promising app that will rock your weekends, outings and any happening that you want to easily enjoy watching its moments over & over again (we are now doing the Android version, then the iOS one). Because we want Zingoo to be born strong, it has to deliver the best possible [UX] to all awesome-moments lovers around the world, which means we have to do our best in loading the images.

Because we (at Begether) do listen to our users, we heard a lot of comments on how WhatsApp is loading images super-fast, so we dug deeper to know what we can do about it, & here is what we find,

What does WhatsApp do?
WhatsApp is doing the following (numbers are approximate):

  • Photos sizes range around 100KB, which loads the images pretty fast on most common mobile-network speeds. (part 2 explains how to achieve this)
  • Photos are cached, so no need to load them every time you open the app (almost no need to mention this 🙂 ).
  • They first show a very small thumbnail (about 10KB or less) until the real image is loaded, & this is the real pro-tip for their better UX.

The last tip has a different variance by calculating the image dimensions & the approximate color of the image that will be shown & applying it to its placeholder, like the coming 3 minutes in this video:

but still, the thumbnail is away more cooler, right? 😉

How is it done?
To achieve the caching there are some good Android libraries out there that are doing a good job, but one of them is doing a way better than the others, which is Picasso. Both caching on disk & on memory are built under the hood, with a very developer-friendly API, I just love what Jake Wharton & his mates did for all of us, thanks guys.
Using Picasso is pretty easy, just like this example one-liner:


you just need first to add Picasso to your gradle files with the urlConnection library (according to this issue), like this:

compile 'com.squareup.picasso:picasso:2.4.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.0'

After solving the caching issue, we need to apply the thumbnail great tip, we need to use Picasso 2 times, one for loading the thumbnail and the other for loading the real image like the comment I made on this issue. Also to avoid the thumbnail’s pixlation effect (due to its small size), it would be better to make a blurring effect on it,
WhatsApp's Thumbnail Loading Effect

and here is how it is done:

Transformation blurTransformation = new Transformation() {
    public Bitmap transform(Bitmap source) {
        Bitmap blurred = Blur.fastblur(LiveImageView.this.context, source, 10);
        return blurred;

    public String key() {
        return "blur()";

    .load(thumbUrl) // thumbnail url goes here
    .resize(imageViewWidth, imageViewHeight)
    .into(imageView, new Callback() {
        public void onSuccess() {
                    .load(url) // image url goes here
                    .resize(imageViewWidth, imageViewHeight)

        public void onError() {

We used the Callback() functionality to start loading the full image after the thumbnail is completely loaded, with using the blurred thumbnail’s drawable as the new placeholder for the real image, & this is how the magic is being done right here :).
Also the blurring made here is Blur.fastblur(), thanks to Michael Evans & his EtsyBlurExample example, you can find this class here.

The only remaining part is how to compress the large images (which could be 2 to 4 MB) to be only about 100 KB, which is discussed in Part 2.


All Node.js frameworks in one page

Do you wanna use Node.js but don’t know which framework that suits your needs ?

well, this page has all available frameworks known today categorized by:

So, this is all you need to start choosing the framework that suits your needs, good luck.

Tip: look for how many github stars the framework has got, it shows you how much it is trusted by people like you 😉 , which brings us to the incredible record by Meteor which is 22,337 stars till now!!

Solved: Restarting node server may stop recurring Agenda jobs

Node is the future, it is that simple. With that being said, one of the important things one will look for is how to start cron-jobs, is it by just using cron-tab to start a stand-alone script, or could it be a plugin inside the code base itself, like what is available in Node with its great npm set of packages that you can choose from,
one of the very good packages for managing the cron-jobs is Agenda which comes with a great feature for visualizing your jobs by using Agenda-UI which looks like this:
enter image description here

After starting using Agenda (0.6.27), I faced a serious issue when restarting my node server, because the recurring jobs (i.e agenda.every '30 minutes') may stop working for no reason, my code was like this:

agenda.define 'my job', my_job_function
agenda.every '30 minutes', 'my job'

for a while, I thought in leaving Agenda for good, & using the widely known Cron instead, which is a really great alternative by the way, it is almost an imitation of the linux’s cron-tab interface, with an incredible number of downloads (95,483 downloads in the last month),
The only thing kept me trying to find a solution is Agenda’s superior advantage by monitoring the jobs easily using its Agenda-UI interface, so I opened an issue on Agenda’s github page & digged in a little more until I found the solution.

Solution 1
Since redefining our jobs on server start didn’t solve it, so I managed to remove the old broken recurring jobs when shutting down the server like this (you can add the following to your startup scripts like putting it in app.js):

graceful = ()->
    agenda.cancel repeatInterval: { $exists: true, $ne: null }, (err, numRemoved)->
        agenda.stop ()->
            process.exit 0

and with server start, the jobs will be redefined again & voila,
I’m using this workaround now, & it is working like a charm.

Solution 2
While observing the broken jobs & what causes them to stop working, I found that they are locked, because restarting the server while they are still running prevented them from releasing the lock, so droppedoncaprica has proposed the following solution to release all locks when starting the server:

agenda._db.update {lockedAt: {$exists: true } }, { $set : { lockedAt : null } }, (e, numUnlocked)->
    if e
        console.log e
    console.log "Unlocked #{numUnlocked} jobs."
    # redefine your jobs here

Once Agenda solves this issue, I’ll update the post with the version containing the fix isA.