While I totally agree with the fact that Kotlin An...

# android

[tseisel]

While I totally agree with the fact that Kotlin Android Extensions were unsafe, I found them easier to use than ViewBinding.
ViewBinding requires you to manually clean up references to views in Fragment.onDestroyView(), unless you are not storing binding object as class field. As a Kotlin developer, what approach are you using to avoid repeating this boilerplate for all fragments ? Delegated property ?

[gildor]

unless you are not storing binding object as class field

which sounds like a good idea

[ephemient]

doesn't help with boilerplate, but as far as correctness goes, my team's using with a custom lint check that ensures any viewbinding fields are nulled by onDestroy/onDestroyView

[ephemient]

most of the time you only need it in onCreate

[gildor]

but why set ViewBinding fields to null? Isn’t it enough to clear view binding object itself

[ephemient]

I mean, any fields of ViewBinding type

[gildor]

yes, I got it, but why sorry, misunderstood you

[efemoney]

Co-ask. You shouldn’t have to manually null out ViewBinding refs in Fragment unless you’re doing something hacky (eg retaining the Fragment using setRetainInstance) (And is worse ergonomically cos now you have to access your Views via a nullable binding?.(...) )

[arekolek]

@gildor what do you mean by "clear view binding object itself"?

[gildor]

I just mean that if only ViewBinding keep references to views, why clear it fields? Why do not clear reference on ViewBinding itself. Isnt’t it shoud be created every time when view is created

[efemoney]

He means doing

override fun onDestroyView {
  super.onDestroyView()
  binding = null
}

I believe he misunderstood @ephemient first statement

[gildor]

yeah, I see now, it was meant that fields which hold viewBindings should be cleared

[gildor]

I wouldn’t say that it big boilerplace, any other solution would require probably more code to clean it up (of course until Fragments lifecycle will not be changed

[efemoney]

Personally dont see why you have to clear ViewBinding references still. When a Fragment is destroyed, it is guaranteed that the instance is gone. Unless you are using setRetain Instance or have a leak (ie some other longer living object references the fragment), then the binding references will be gone alone with the destroyed fragment

[arekolek]

Fragments can be detached and re-attached, which destroys and recreates the view

I think that happens every time you call for example replace on the FragmentManager?

[gildor]

As I understand it’s not related on replace, but on does fragment is part of back stack or not. Replace fragment without back stack will destroy it

[efemoney]

Yeah thats true @arekolek, but in the case of a reattach, the binding reference will still be replaced in onCreateView when the fragment is reattached. Nulling it out earlier is a sort of optimisation (which may not be necessary)

[arekolek]

Nulling it out earlier is a sort of optimisation (which may not be necessary)

You could say that about a lot of memory leaks then I guess?

[gildor]

But it means that Fragment view is leaked until Fragment is reopened

[gildor]

imagine deep stack of fragemnts, with your approach all views will leak, until user press back (which may never happen), so it’s not a theoretical problem

[efemoney]

Yeah in the case of detach and reattach, I can see a need for nulling out the binding ref

[efemoney]

Yeah and whether or not its a leak depends on a case by case basis but I guess it doesnt hurt to be careful

[tseisel]

So here is the TL;DR solution:
Prefer storing bindings in a local variable in `onCreate`/`onCreateView`, and if needing it in other lifecycle methods, then store as nullable class field and manually null-out reference on `onDestroy`/`onDestroyView` ?

[arekolek]

You can strike-out the `onCreate`/`onDestroy`, because this applies only to Fragments and their view

Otherwise I'd say that's accurate

[arekolek]

I saw some property delegates people created for this, but also that they got some issues with initial implementations, not sure if they ended up with a bulletproof solution