hello, Eric!

how can I help you today?

mark, nice to see you again

I was wondering about a leakcanary trace I saw

um, OK -- not sure if I can help with that, but if you can provide the trace (ASCII text or screenshots, I guess), I can try

my activity contains fragment A and fragment B. fragment A contains a strong reference to an adapter. If I navigate to fragment B and don't null my adapter I see 2 leaks. 1 for recyclerview and 1 for a ConstraintLayout. My confusion is because my app layouts do not use ConstraintLayout but leakcanary says it is a leak

is something still holding a reference to fragment A after you navigate to fragment B?

no, and my fragment A layout lacks a ConstraintLayout.

then I'd at what is holding onto fragment A

actually, I made an assumption which may not be correct

what is Leak Canary saying has the reference to the RecyclerView and the ConstraintLayout?

after my recylclerview leak it points to a constraintlayout leak and states "ObjectWatcher was watching thiw because Fragment A received Fragment onDestroyView callback (references to its views should be cleared to prevent leaks"

Fragment A adapter contains a ObservableData-->Observers-->my recyclerview

I do not know what ObservableData is -- is that from a library?

or do you mean Observable from RxJava?

it is a member type inside RecyclerView.Adapter from Android sdk

that search comes up empty

so there does not appear to be anything named ObservableData in the Jetpack

It is actually spelled AdapterDataObservable and exists as a member of nested class Adapter inside of RecyclerView

ah, OK, now I see it

and your fragment A is holding onto the adapter? if so, then I'm back to my earlier recommendation: identify what is holding onto fragment A

or, null out the field that holds the adapter in onDestroyView()

in principle, if nothing has a reference to fragment A, Leak Canary should not care, though I have not been using its latest version and it may be getting more sensitive than I am used to

but, the message of the complaint is fairly accurate: ideally, after onDestroyView(), your fragment does not have any direct or indirect references to views created in onCreateView() or during the operation of the fragment

if the fragment is going to get garbage collected right away, usually there is no harm in ignoring onDestroyView()

my recyclerview leaks because AdapterDataObsewrvable contains observers, one being my recyclerview. To fix both leaks I set my adapter to null. I don't see this ConstraintLayout being referred to by LeakCanary. Just trying to understand it

To my understanding nothing is referring to fragment A

are your item layouts for the RecyclerView using anything from the Jetpack or Material Components for Android? perhaps they are using the ConstraintLayout

nope, AppCompatTextViews

¯\_(ツ)_/¯

it is very difficult for me to help on something like this, that is tied to some debugging output that I cannot see

true. One last question

why do people write constants inside of a companion object?

the approach that I take depends on who needs the constant

a private constant I will usually just put outside the class at the top of the Kotlin source file

but if other classes need the constant, then I put it in a companion object to avoid polluting the top-level namespace across the project

personally I do not see the value in having private constants in a companion object, but that's just me

if I put it outside my class, and a different class needs to use it, I use a wider access modifier. I don't know why it is bad to put it in a top-level namespace ("polluting it")

how many developers are working on your project?

I ask because I see it all the time and I don't see any benefit. It varies but it's a fairly large group of people

in my experience, the bigger the team, the more likely it is that you are going to want to have some structure around naming things

you're certainly welcome to do that solely by looking at the name of the constant itself, but I would rather see Thingy.COUNT than THINGY_COUNT

but, again, it's a matter of personal taste and team policies

in my case, if I rename Thingy to OtherThingy, I would rather have its associated constant follow along automatically (OtherThingy.COUNT) rather than also have to remember to rename a lightly-associated constant (OTHER_THINGY_COUNT)

I guess belonging to a class if it is a companion gives you some context

right -- for private constants, the context is the file, and ideally you don't have massive individual source files

ok I appreciate it mark

take it easy

happy to help!

you too!