3

There are many popular Image loader available in Github for image loading and caching and Managing Image Request.

  1. Universal Image Loader
  2. Volley
  3. Picasso
  4. Fresco (added enhancement )

I came across the requirement if the Imageview if no longer attached to window the request (batch and flight ) will be cancelled .

However the scrolling widget like Listview and Gridview the Imageview is frequently attached and detached from window and so the request in queue are canceled respectively .

My concern is that their no mechanism to trace the progress of image request in all above library .If Imageview is detached the request should be cancelled on the basis of progress , if the byte stream a had already done 75% of work then it should not be cancelled , which in turn will reduce the network bandwidth and decrease network call , as usually user always scroll a lot in Scrolling Widget like Listview and Gridview etc ..

Here is my understanding with Volley :

public boolean removeContainerAndCancelIfNecessary(ImageContainer container) {

    /* logic to check progress of Request */
    mContainers.remove(container);
    if (mContainers.size() == 0) {

        mRequest.cancel();
        return true;
    }
    return false;
}

Here is my understanding with Picasso :

private void cancelExistingRequest(Object target) {

    checkMain();
    Action action = targetToAction.remove(target);
    if (action != null) {

        action.cancel();
        dispatcher.dispatchCancel(action);
    }
    if (target instanceof ImageView) {

        ImageView targetImageView = (ImageView) target;
        DeferredRequestCreator deferredRequestCreator = targetToDeferredRequestCreator.remove(targetImageView);
        if (deferredRequestCreator != null) {

            deferredRequestCreator.cancel();
        }
    }
}

Here is my understanding with Universal Image Loader : I did not figure Universal image loader permits cancelling the inline request .

void cancelDisplayTaskFor(ImageAware imageAware) {

    cacheKeysForImageAwares.remove(imageAware.getId());
} 

Please let me know the possibility to solve it for Network Request only . In case the image is already cached then we will cancel the request .

Battery performance is really important in Android

Vipin Sahu
  • 1,441
  • 1
  • 18
  • 29
  • I think instead of cancelling request before or upto 60%, try cache image one time and use it after word so it may take less internet usages compare to cancelling request and again when need freshly get same image and yes you have try AndroidQuery for async image loading instead this three library :http://code.google.com/p/android-query/ – Haresh Chhelana Nov 26 '14 at 10:51
  • the request is for network call , not for Cached images . – Vipin Sahu Nov 26 '14 at 10:52
  • Yes i know that but if not cache image one time then it will load from net every time and as per your requirement it will waste if image request not get 75% byte data so it is indirectly wast to network usages. – Haresh Chhelana Nov 26 '14 at 10:55
  • Hey Haresh Caching works for all image loading library . so I am not concerned for caching. My point is when the first request is made it should be checked before cancelling when detached and user keep on scrolling to and fro frequently then a lot of request is also generated and cancelled in intermediate state . – Vipin Sahu Nov 26 '14 at 11:01

1 Answers1

2

I can't say about Volley and Picasso but I can say how UIL works.

UIL constantly checks ImageView during task processing. If task becomes non-actual (ImageView is recycled (reused) or it's collected by GC) then UIL stops task for this ImageView.

What about if task becomes non-actual while downloading image? UIL aborts downloading if there was downloaded less than 75% of image data. If more than 75% - then UIL completes downloading (i.e. UIL caches image file in disk cache) and then cancels task.

nostra13
  • 12,377
  • 3
  • 33
  • 43