# ViewBindingPropertyDelegate: a Kotlin delegate that clears the binding for you

> ViewBindingPropertyDelegate wraps Android View Binding in a Kotlin property delegate that creates the binding lazily and drops the reference after the view lifecycle ends, in two artifacts, one with reflection and one without. The recommended artifact is dev.androidbroadcast.vbpd:vbpd at version 2.0.4.

**androidbroadcast/ViewBindingPropertyDelegate** — Make work with Android View Binding simpler

- Repository: https://github.com/androidbroadcast/ViewBindingPropertyDelegate
- Website: https://proandroiddev.com/make-android-view-binding-great-with-kotlin-b71dd9c87719
- Stars: 1,468 · Forks: 98
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/androidbroadcast-viewbindingpropertydelegate

## Three jobs: lifecycle, non null fields, lazy creation

The library lists exactly what it does for you, and the list is short. It manages the ViewBinding lifecycle and clears the reference to it to prevent memory leaks. It removes the need to keep nullable references to Views or ViewBindings. And it creates the ViewBinding lazily. The second point is the one Kotlin developers notice first. Without this, a fragment that inflates a binding has either a nullable binding field guarded by null checks at every use site, or a non null field that the fragment has to remember to null out. A delegate turns that into a single non null property, and the clearing happens on a lifecycle callback rather than in code you have to remember. The memory leak argument is the classic Android one: a binding holds its root view, and a fragment outliving its view is what keeps a destroyed hierarchy in memory.

## Pick vbpd, not vbpd-reflection, unless you need the factories

There are two variants and the README states a preference: prefer the one without reflection for better performance. The artifacts are dev.androidbroadcast.vbpd:vbpd and dev.androidbroadcast.vbpd:vbpd-reflection, and the reflection one is described as additional factories that use reflection under the hood. The performance argument is not subtle. Reflection resolves a binding type and its factory at runtime, which costs a lookup and hides the dependency from the compiler's view. The plain artifact takes the binding call as a function reference, so nothing is resolved by name at runtime. The repository layout confirms the split: vbpd/ and vbpd-reflection/ sit beside vbpd-core/, which is where the shared delegate lives. Take the reflection artifact only if you specifically need one of those factories.

## Add the dependency and enable View Binding per module

The library ships to Maven Central under the dev.androidbroadcast.vbpd namespace. The README's dependency block shows both coordinates, with the non reflection one marked recommended:

```kotlin
dependencies {
    // recommended
    implementation("dev.androidbroadcast.vbpd:vbpd:2.0.4")
    
    // additional factories that use reflection under hood
    implementation("dev.androidbroadcast.vbpd:vbpd-reflection:2.0.4")
}
```

One prerequisite comes before that and is flagged as IMPORTANT in the README: every Gradle module that needs View Binding must be configured for it, following the official Android guide. The library does not enable View Binding for you, so a module that has not declared it will fail before the delegate is ever called.

## The delegate takes the bind function as a reference

The sample shows the whole usage pattern in one fragment. The property is declared with the by viewBinding infix and the generated bind function is passed in, and the comment marks it as the recommended form because no reflection API is used underneath:

```kotlin
class ProfileFragment : Fragment(R.layout.profile) {
   private val profileBinding: ProfileBinding by viewBinding(ProfileBinding::bind)

   override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
       super.onViewCreated(view, savedInstanceState)
       with(profileBinding) {
          firstName.text = person.name
          lastName.text = person.surname
          email.text = person.email
       }
   }
}
```

Passing ProfileBinding::bind rather than a class name is what keeps the non reflection path working, and it also means the reference to the binding class is a compile time one. There is no inflate call, no lateinit, and no null check inside the layout block.

## The reference is dropped after onDestroyView, which changes where cleanup goes

The sample's onDestroyView override is where the design pays off, and it is also where the behaviour change lives:

```kotlin
override fun onDestroyView() {
   super.onDestroyView()
   // profileBinding will be cleared after onDestroyView()
}
```

The override does nothing except call super, because the delegate handles the clearing itself. The consequence for your code is that a listener registration or a pending callback touching profileBinding must be torn down inside that window, not after it, since the reference is gone once the callback returns. Anything that previously relied on holding the binding past the view's life is exactly the kind of code that turns this convenience back into a leak. Version 2 also removed the old manual hook in favour of moving that code to a proper lifecycle callback, such as Fragment.onDestroyView() or Activity.onDestroy().

## Migrating from 1.x is a package rename and a callback move

The migration section is short because the API barely moved. Versions 1.x and 2.x can be used in the same project without replacing code, which removes the usual all or nothing upgrade risk. Two changes matter: the package com.github.kirich1409.viewbindingpropertydelegate becomes dev.androidbroadcast.vbpd, and onViewDestroyed is replaced by moving that code into the proper lifecycle callback. The coordinate rename is also a namespace change on Maven Central, so a Gradle cache with the old artifact will not satisfy the new one. The changelog is at the repository root if you need the version by version detail.

## Against keeping a nullable binding field by hand

The alternative is what the platform gives you without a dependency: a binding field in the fragment, inflated in onCreateView or onViewCreated, nulled in onDestroyView, and null checks or a safe call at every use. Some teams also reach for an abstract base class that wraps that pattern, which is the same idea implemented once but tied to a base class and a specific view lifecycle. This library's approach is a property delegate, so it attaches to one property instead of a class hierarchy, and it works for any binding you can pass a bind reference for. The cost is a dependency in every module that uses it, and the loss of the old package name when upgrading. Which trade you prefer depends on whether your team already has a base fragment convention, since that convention makes the manual approach cheap.

## Conclusion

ViewBindingPropertyDelegate fits a Kotlin Android codebase that adopted View Binding and found itself writing nullable fields plus a manual clear in every fragment, because the delegate does both in one line and keeps the reference from outliving the view. Skip it if your screens are not using View Binding, or if a Java team would need the reflection artifact for no benefit, since the README asks you to prefer the non reflection variant. Before upgrading an existing project, read the migration notes: version 2 changes the package from com.github.kirich1409.viewbindingpropertydelegate to dev.androidbroadcast.vbpd and removes onViewDestroyed in favour of the standard lifecycle callbacks, though 1.x and 2.x can coexist in one project. The last push was on 2026-06-06 and 2.0.4 was released on 2025-02-13.

## FAQ

### How do I add ViewBindingPropertyDelegate to an Android project?

Add the Gradle dependency dev.androidbroadcast.vbpd:vbpd:2.0.4 from Maven Central, using the vbpd-reflection artifact only if you need its factories. View Binding must be enabled in every Gradle module where you use the library, per the official Android guide.

### What is the difference between vbpd and vbpd-reflection?

The library comes in two variants: vbpd and vbpd-reflection. The README recommends the one without reflection for better performance, and describes the reflection artifact as additional factories that use reflection under the hood.

### How do I migrate from version 1.x to 2.x?

Replace the package com.github.kirich1409.viewbindingpropertydelegate with dev.androidbroadcast.vbpd and move any onViewDestroyed code into the proper lifecycle callback such as Fragment.onDestroyView() or Activity.onDestroy(). Both versions can be used in the same project during the migration.

## Sources

- [androidbroadcast/ViewBindingPropertyDelegate on GitHub](https://github.com/androidbroadcast/ViewBindingPropertyDelegate)
- [License: Apache-2.0](https://github.com/androidbroadcast/ViewBindingPropertyDelegate/blob/master/LICENSE)
- [Project website](https://proandroiddev.com/make-android-view-binding-great-with-kotlin-b71dd9c87719)
- [README](https://github.com/androidbroadcast/ViewBindingPropertyDelegate/blob/master/README.md)
- [Releases](https://github.com/androidbroadcast/ViewBindingPropertyDelegate/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/androidbroadcast-viewbindingpropertydelegate