Callback leaks: cancel your Picasso requests!

Because canceling the request means we can save network related resources

Thanks for your reply. I agree with your point that it is best practice to cancel the request once the ImageView is ready to be destroyed to save the network/cpu resource.

My concern here is

1. onDetachedFromWindow is the callback on View instead of Activity/Fragment. So it might be an issue when the ImageView is inside one of the ViewPager. Refer to "Android view - onAttachedToWindow and onDetachedFromWindow - when are they called in the activity lifecycle" in StackOverFlow.

2. Besides, I tried to understand why the leak happens here. The root cause seems to me that the ImageView instance gets referenced by the callback which is encapsulated into ImageViewAction. For example, if we did show a snackBar inside the callback instead of imageView.setBackgroundColor(), it would not be a memory leak because imageView is garbage collected properly and the callback too I think.

In my mind, the root cause is exactly the WeakHashMap warning you mentioned. But it is the best solution to cancel the request when Activity/Fragment arrives in the destroyed state.