---
title: "Discussion on \"Callback leaks: cancel your Picasso requests!\" | Hashnode"
description: "Discussion on \"Callback leaks: cancel your Picasso requests!\". 👋 Hi, this is P.Y., I work as an Android Engineer at Block. Every month I organize an internal Ensemble Leak Hunting session where we look at the top leaks reported by LeakCanary to learn how to read"
url: "https://hashnode.com/posts/callback-leaks-cancel-your-picasso-requests/63c70dc6420d9d2bc9e723b6"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Callback leaks: cancel your Picasso requests!](https://blog.p-y.wtf/callback-leaks-cancel-your-picasso-requests?utm_source=hashnode&utm_medium=feed)

👋 Hi, this is P.Y., I work as an Android Engineer at Block. Every month I organize an internal Ensemble Leak Hunting session where we look at the top leaks reported by LeakCanary to learn how to read

Jan 17, 2023 · 6 min read · blog.p-y.wtf  
Updated Mar 26  
Read the article

-   [#android](https://hashnode.com/tag/android)
-   [#android-app-development](https://hashnode.com/tag/android-app-development)
-   [#memory-leak](https://hashnode.com/tag/memory-leak)
-   [#performance](https://hashnode.com/tag/performance)
-   [#picasso](https://hashnode.com/tag/picasso)

## Written by

[Pierre-Yves Ricau](https://hashnode.com/@py)

@py · San Francisco

  
[View profile](https://hashnode.com/@py)

Deep dives

My pronouns are he / him. Android Engineer at Square / Block. A few things I enjoy: Publishing Open Source libraries (LeakCanary, Curtains, Radiography, square/logcat) Rollerblading Writing technical blogs (previously on dev.to/pyricau) Cooking Giving tech talks Reading sci-fi

## Responses

Markdown supported · ⌘↵ to post

[Feng Zheng](https://hashnode.com/@engx2)

[Feb 4, 2023](https://hashnode.com/posts/callback-leaks-cancel-your-picasso-requests/63c70dc6420d9d2bc9e723b6/comment/63dea377870f1899b96ee68b)

Nice article! Good explanations!

Why not to make the imageView in the callback as a weak reference?

[Pierre-Yves Ricau](https://hashnode.com/@py)

[Feb 4, 2023](https://hashnode.com/posts/callback-leaks-cancel-your-picasso-requests/63c70dc6420d9d2bc9e723b6/comment/63dea377870f1899b96ee68b#reply-63deb8cd870f1899b96ee96e)

Because canceling the request means we can save network related resources

[Feng Zheng](https://hashnode.com/@engx2)

[Feb 5, 2023](https://hashnode.com/posts/callback-leaks-cancel-your-picasso-requests/63c70dc6420d9d2bc9e723b6/comment/63dea377870f1899b96ee68b#reply-63df1363870f1899b96ef18a)

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.