# Replacing Custom Views with View Binding

DevFeed: [Replacing Custom Views with View Binding](<https://devfeed.tech/articles/replacing-custom-views-with-view-binding-25976.md>)

Original publisher: [Read original article](<https://proandroiddev.com/replacing-custom-views-with-view-binding-7836c34185fb?source=rss-8efc0359e234------2>)

Author: Jossi Wolf

Published: 2020-04-19T12:31:58Z

Content type: tutorial

Language: en

Sources: [Stories by Jossi Wolf on Medium](<https://devfeed.tech/sources/stories-by-jossi-wolf-on-medium.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [XML](<https://devfeed.tech/topics/xml.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Boilerplate](<https://devfeed.tech/topics/boilerplate.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [code](<https://devfeed.tech/tags/code.md>), [custom-view-android](<https://devfeed.tech/tags/custom-view-android.md>), [dockerignore-usage](<https://devfeed.tech/tags/dockerignore-usage.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [view-binding](<https://devfeed.tech/tags/view-binding.md>), [xml](<https://devfeed.tech/tags/xml.md>)

## AI overview

This tutorial explains how a codebase replaced reusable custom views with Android View Binding when custom rendering was unnecessary. It covers generated binding objects, lifecycle-scoped instantiation, reusable binding extension functions, and passing data models to reusable components.

## Source excerpt

How we used View Binding to replace Custom Views In our codebase, we use a lot of custom views for reusability -- but most of the time, a custom view was overkill. Here's how we used View Binding to replace some of our custom views. View Binding 101 If you are not familiar with View Binding yet, here is a great post by Sean McQuillan about it. In short: View Binding is a better alternative over Kotlin Synthetics, findViewById and good old Butterknife. It allows you to access the views in a layout in a type-safe and null-safe way. For each XML layout, View Binding generates a binding object. For a layout fragment_login.xml, you'd get a binding object called FragmentLoginBinding. Instantiating the binding objects requires a bit of boilerplate to make sure it is scoped to the components' lifecycle. We use a delegate class as suggested in this post to make the code cleaner and easier to read. About Our Custom Views We used many custom views for our reusable components. Like this one: https://medium.com/media/0d681c4bb6b7d1f682a84aa2e58801ba/href Custom views are awesome if they are used right, but they bring quite a bit of boilerplate and are harder to maintain then XML layouts. For cases where we don't do any custom rendering, View Binding made more sense to use as we could cut down on the boilerplate. Using View Binding for Reusable Components As View Binding generates a binding object for each layout, the first step for migrating was to create a layout: https://medium.com/media/b9c9bf94e38e1b30923d741f6e85d7c4/hrefPreview of the layout Now for our card_user_data.xml, View Binding generates a CardUserDataBinding.java which we can use. Binding the data First, we need to include the card layout in our fragment's layout. https://medium.com/media/1af56e360407fe6f1eaef366f18e6401/href View Binding will automatically cast the type of the <include> to CardUserDataBinding, so we can use it in a type-safe way. That also means we can reuse those bindings across layouts. Beware t