# android-view-binding

Published articles for android-view-binding.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## An update to the FragmentViewBindingDelegate: the bug we've inherited from AutoClearedValue

DevFeed: [An update to the FragmentViewBindingDelegate: the bug we've inherited from AutoClearedValue](<https://devfeed.tech/articles/an-update-to-the-fragmentviewbindingdelegate-the-bug-we-ve-inherited-from-autoclearedvalue-25927.md>)

Original publisher: [Read original article](<https://itnext.io/an-update-to-the-fragmentviewbindingdelegate-the-bug-weve-inherited-from-autoclearedvalue-7fc0a89fcae1?source=rss-7a8d96da8cb6------2>)

Author: Gabor Varadi

Published: 2021-01-24T00:40:53Z

Content type: article

Language: en

Sources: [Stories by Gabor Varadi on Medium](<https://devfeed.tech/sources/stories-by-gabor-varadi-on-medium.md>)

Topics: [Jetpack](<https://devfeed.tech/topics/jetpack.md>), [bug](<https://devfeed.tech/topics/bug.md>), [navigation](<https://devfeed.tech/topics/navigation.md>)

Tags: [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [android-view-binding](<https://devfeed.tech/tags/android-view-binding.md>), [bottom-navigation](<https://devfeed.tech/tags/bottom-navigation.md>), [bug](<https://devfeed.tech/tags/bug.md>), [fragments](<https://devfeed.tech/tags/fragments.md>), [jetpack](<https://devfeed.tech/tags/jetpack.md>), [jetpack-lifecycle](<https://devfeed.tech/tags/jetpack-lifecycle.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [navigation](<https://devfeed.tech/tags/navigation.md>)

### AI overview

The article identifies a bug in an AutoClearedValue-based FragmentViewBindingDelegate. A fragment can move directly from view creation to view destruction without becoming active, so the observer never runs and the binding is not cleared. The proposed fix is to observe the view lifecycle without using the fragment as the lifecycle owner.

### Source excerpt

Jetpack Lifecycle is quite powerful. We can extract logic, and make it lifecycle-aware. In fact, this allowed us in a previous article to simplify viewbinding and make it a single line. However, I need to provide a quick heads-up: all is not as it seems. The provided gists and code snippets assumed that the code in AutoClearedValue is always correct. In this article, I'll show you how to break it. The original sourcehttps://medium.com/media/74ef2eaf8bac6a656cece1f95796034a/href The general idea behind AutoClearedValue is that a value hidden by this delegate would only be created when it is set (in our case, when it is accessed), and when viewLifecycleOwner becomes DESTROYED, it would null out the value. Makes sense, right? In order to access the view lifecycle, the code waits until Fragment.onCreate(), and registers the lifecycle observer there. Then, using the fragment as the lifecycle owner (!), it attempts to register a lifecycle observer on the view lifecycle owner. The bug hiding in plain sight The problem is that it is possible for the view lifecycle to be initialized in such a way that fragment.onStart() and therefore viewLifecycleOwner.lifecycle.addObserver never actually happens. The fragment goes directly from onViewCreated to onDestroyView. Meaning, fragment.onStart() and fragment.onStop() never happen. This means that fragment.viewLifecycleOwner.observe(fragment) will NEVER be ACTIVE, and therefore the observe block will never be called. The viewLifecycle reaches DESTROYED without it being observed. When does this happen? If a fragment is added with commitNow(), but then is detach()ed. This would mean that this could happen with FragmentPagerAdapter, as that also uses attach/detach under the hood. In my case, the bug surfaced when using the binding along with the following construct: https://medium.com/media/942d1d2a1b2b4bbdc77e4d11ef112b97/href In case of a bottom navigation view, where fragments were added but attached/detached, the view in the binding