View Binding Tutorial for Android: Getting Started

In this tutorial, you’ll learn how to use View Binding to find and configure your views.

Since its origins, the Android framework has provided a way to find and configure views. You can achieve this by using findViewById() in Activities, Fragments and Views.

On one hand, while there’s nothing wrong with that method, and you can still use it in your code. On the other, there are alternatives that are used more than this built-in Android mechanism nowadays. Finally, each of these alternatives have pros and cons for elegance, compile time safety or build speed impact. You’ll explore and compare them to findViewById().

Using Different Approaches

So, what are all the approaches to working with Views? Well, I’m glad you asked! Here’s a quick breakdown of the various approaches as well as some of their pros and cons.

In Android 8, API 26, Google made a change to the findViewById() signature. findViewById() now uses generic typing, and instead of returning a plain View object, it returns a type that extends from View.

That means that you can return any concrete type without having to cast the result explicitly. Using findViewById() also isn’t null safe since this method can return null if the referenced view is not available for use at the time of access. Using such a View, without adding null checks can lead to a NullPointerException.

A good thing about findViewById() is that it doesn’t have any impact on build speed, because it works in the runtime.

While this approach provides an elegant interface, it doesn’t give you compile-time safety, as you can bind any view ID to any View type. Moreover, if you bind the wrong type, you’ll get an exception in the runtime. It also impacts the build speed because it runs an annotation processor to generate code. You can check out this approach at the following link.

Additionally, ButterKnife’s development is coming to an end. Jake Wharton, the creator of this library, is deprecating it in favor of View Binding.

It should take all the best parts of each of the other approaches while avoiding their flaws. View Binding’s impact on build speed is almost negligible.

• findViewById: It’s verbose and thus not elegant. In the past, this method returned a View object, and you had to explicitly cast it to a specific type. As a result, it didn’t provide compile-time safety.
• ButterKnife: This is an annotation-based approach, where you can annotate all the Views you want to bind. Similar to Dagger2, or Room, the compiler then generates the required code, to bind these views.
• Data Binding: This approach generates a class for you to use. This provides an elegant interface as well as compile-time safety. But, it lowers the speed of your build because of the annotation processing. You can check this approach in the official documentation.
• Kotlin synthetic properties: This is a simple and easy-to-use API. While it doesn’t impact the build speed, it also doesn’t provide compile-time safety. And you can only use it in Kotlin. Check out the official documentation, if you want to try it out.
• View Binding: This new approach to finding views has an elegant interface, like Data Binding. Google designed it to avoid the performance issues of Data Binding and to provide compile-time safety.

According to Google, this new approach has the best of all the worlds. So, you should use it wherever you can.

But, it’s not the best choice for one specific case. You’ll see an example later in the sample project.

Getting Started

To get started, download the begin and end projects by clicking the Download Materials button at the top or bottom of the tutorial.

Throughout this tutorial, you’ll work with an app called BMICalc. By providing height and weight, BMICalc lets the user calculate his or her Body Mass Index (BMI). It also shows a color indicating if the user is either healthy or overweight.

To use View Binding, you need to upgrade to the Android Gradle Plugin version 3.6.0-alpha11 or later. This version of the Android Gradle Plugin requires Gradle 5.6.1 or higher. Also, you need to use Android Studio 3.6 Canary 11+ or newer because older versions of Android Studio won’t open a project that uses the Android Gradle Plugin version 3.6.0-alpha11 or higher.

You’ll find BMICalc already configured using the appropriate versions.

For the tutorial, you’ll use the canary version of Android Studio 4.0. Since the canary versions may change from the time of writing the tutorial, make sure you have the latest installed. If you haven’t already, click here to download that version. Once downloaded, open the begin project, from the materials, by selecting Open an existing Android Studio project from the welcome screen.

Build and run BMICalc and become familiar with it:

Set up your profile and add a few weight logs.

Project Structure

The project contains the following main files:

• MainActivity.kt contains the main screen. It shows all the weight logs with their calculated BMIs.
• LogActivity.kt lets the user to create a new weight log.
• ProfileActivity.kt lets the user to provide his or her birthdate and height.
• BMIApplication.kt provides a dependency for the activities, in your case a Repository.
• Person.kt and WeightLog.kt represents the data of a person as well as his or her weight logs.
• PersonAdapter.kt adapts the person’s data and his or her weight logs so they show in the main screen.
• Repository.kt saves and retrieves the user and his or her weight logs data.
• MainViewModel.kt, LogViewModel.kt and ProfileViewModel.kt have operations called by their associated activities, which observe LiveDatas exposed by the ViewModels.

Notice that some Activities use findViewById(). Others use Data Binding and Kotlin synthetic properties to find and configure views.

You’ll migrate these to ViewBinding later in the tutorial. First, you’ll enable View Binding.