If you're wondering why I ask this in a kotlin rel...

# android

[Fredrik Larsen]

If you're wondering why I ask this in a kotlin related channel, it is because I see multiple examples where people use lazy or lateinit which will retain the instances. The same goes for views, unless you use synthetics which in itself is a bit "hacky" imo.

[ghedeon]

Why would you go an extra mile to mess with adapter instance instead of letting the GC to do its work? It's a field (probably lateinit) in the fragment like many others. It will go, once the fragment is destroyed. Do you face any particular issues with that?

[Fredrik Larsen]

Because the fragment is not destroyed. Only the view. When you navigate and put the fragment in the backstack it's retained. Meaning GC will not collect the adapter.

[ghedeon]

yes, that's how it should be

[ghedeon]

also, adapter doesn't keep views, only items.

[Fredrik Larsen]

So you're saying the recyclerview adapter will not retain the viewholders?

[Fredrik Larsen]

In that case you're right, there is no need to manually release/recreate the adapter.

[ghedeon]

adapter is kind of a viewmodel for the view (recycler). Normally you don't clean the model when the view is destroyed.

[ghedeon]

Holders are kept in the RecyclerView, not in the adapter.

[Fredrik Larsen]

That's true. Thank you for clearing that up.

[Fredrik Larsen]

On a similar note though, If I did not use synthetics but rather

lateinit var recyclerView: RecyclerView

then I would be retaining that view even after onDestroyView()

[Fredrik Larsen]

which in the case with recyclerViews full of images would retain a lot of memory

[Fredrik Larsen]

I didn't phrase that as a question, but I do wonder how other deal with that use case.

[Fredrik Larsen]

Apart from the obvious - making it nullable and setting it to null in onDestroyView().

[ghedeon]

yes, you'd need to set it to null manually. Or call unbind() from ButterKnife. Or just use synthetics, it's so simple, I can't see myself going back 😏

[Sam]

@Fredrik Larsen I had similar issues. I don't use members to keep a reference to views anymore
https://medium.com/@debuggingisfun/fragments-in-2019-1d9898239ebb

[Sam]

Also, when in doubt, just enable leak canary fragments, that will give you a hint when there is a leak

[Sam]

// Optional, if you use support library fragments:
debugImplementation 'com.squareup.leakcanaryleakcanary support fragment1.6.3'

[Fredrik Larsen]

I did some more digging and ViewHolders are retained by the LayoutManager, så destroying the recyclerview doesn't release them. You need to destroy the LayoutManager as well.

[Fredrik Larsen]

In other words if you add a lot of fragments to the backstack (navigation) and you deal with many images, then this essentially a memory leak:

private lateinit var layoutManager: RecyclerView.LayoutManager

[ghedeon]

I don't think any of discussed cases qualify as proper leaks, once the fragment is gone it will go as well. But yes, if you keep it in a field then it won't be released onDestroyView. Thus, if you don't nullify your references, you retain views longer than you'd want.

[Fredrik Larsen]

It's nice to be aware of it as memory builds up. But I agree, not a leak per say.