Hmm, that's an interesting repro for this recurring issue. There's likely not a good way around it inside Glide, I suggest one of these workarounds (in descending order of quality):

1. Pass in a Glide object: new HomeFeedAdapter(Glide.with(this))

   class HomeFeedAdapter extends Adapter {
       private final RequestManager glide;
       HomeFeedAdapter(RequestManager glide) {
           this.glide = glide;
       }
       @Override public void onBindViewHolder(ViewHolder holder, int position) {
           glide.load....
       }
   }

   This is a handy workaround, and it also makes your adapter flexible to use with fragment and activity as well; and the code cleaner: view.getContext() is usually a long way to access Glide.
   See http://stackoverflow.com/a/32887693/253468 why it's even an improvement.

2. list.setAdapter(null) in onDestroy() or onStop(), which is incovenient to do all the time

3. Check for ((Activity)view.getContext()).isDestroyed() or similar method, which may be unsafe and is even more inconvenient to do all the time

4. Use Glide.with(context.getApplicationContext()), see http://stackoverflow.com/a/32887693/253468 why it may not be a good idea.

Curious: How do you "quit the app" quick enough that the items are binding too late?

There's an OnScrollListener attached to the RecyclerView that loads more data from the server as you scroll to the bottom. To reproduce this issue simply scroll really fast and press the back button.

Ah, I see, so your lazy loading delivers data to a dead activity, it's the same issue as the others: there was always a rogue async call involved.

I might be wrong on this, but doesn't the first option create a memory leak?

I think at worst there's a reference cycle, which doesn't prevent GC from doing its job.

• Activity references RecyclerView
• Views reference Activity (getContext)
• RecyclerView references Adapter
• Adapter references RequestManager
• RequestManager references Activity (not sure)
• Activity references RequestManager through hidden RequestManagerFragment

RequestManager is aware of the activity/fragment lifecycle so any request will be cleared when they die, see linked SO. I don't think anything will be kept after destroy as the fragment is also destroyed.

Ahh ok thanks for clearing that up! The issue is now fixed.

hii...m stuck with java.lang.IllegalArgumentException: You cannot start a load for a destroyed activity
at com.bumptech.glide.manager.RequestManagerRetriever.assertNotDestroyed

i have three activities in my app..so when i am starting 2nd activity there are some images which are loaded by glide in AsyncTask then i m going to further activity...again i came back to 2nd activity("no error") then i come back to 1st activity now again when i am going to 2nd activity app crashes with that exception...i tried glide.clearMemory()..but it dosent work :( please help me out

@kuldiep I can only say the usual: make sure you don't start a load when the activity is destroyed or being destroyed. You can cancel the async task when the activity ia finishing (e.g. onStop). Please open a new issue with some code and more details, if you want more help.

thanks for help....i think i come up with another solution and it works..i m just clearing glide.get(this).clearMemory in onResume, onRestart nd onDestroy methods..as of now i am not getting any error :)

@kuldiep You might as well just disable memory cache altogether (similar applies to bitmap pools): use MemoryCacheAdapter as seen in wiki; and remember, this is a not a solution you found, but a hack hiding the real problem.

ya my approach is not a solution but i'll keep your approach of stopping async task in onStop method for letter use..thanks