Getting started with Android ViewBinding

Learn how to get started using the new feature for faster and safe view bindings on your Android projects

Android Studio 3.6 Canary 11 revamped launch screen

View Binding on Android: a brief story

The Era of findViewById()

On early ages of Android, developers were used to inflate views by calling findViewById(). However, this task could become really cumbersome in an instant. For instance, declaring 3 views it would require at least 3 additional lines just for the sake of views inflation. Now imagine a more complex UI on real projects. Often, we needed to add a bunch of boilerplate code like the following one (along with Java's verbosity):

The Rise of View Binding Libraries

In order to improve our productivity and get rid of repeated inflation tasks, community have been developing great libraries, such as the well known ButterKnife (thanks, Jake👏) which among other cool features, allowed us to bind views using annotations.

Kotlin Android Extensions Synthetic Properties

As Kotlin popularity grows on Android community, we claimed for a more concise and cleaner way to bind views. A suitable approach came with Kotlin Android Extensions plugin, via synthetic properties which generates a bunch of properties to allow accessing views directly by referencing layout id from code. Although this approach brings a cleaner development, it has some caveats:

  • It’s really tricky to reference same view ids from different layouts in a single class. A very common and useful workaround is to add some aliases and update your code to use them in favour of the real view id.

Albeit the above approaches have helped us on getting rid of findViewById(), all its productivity comes with a cost. They rely on annotation processing under the hood, thus adding overhead that might affect the build time.

Introducing ViewBinding: a faster and safe way to bind views

During the "What’s New in Android" session presented on I/O 2019, Google has announced a new faster and safe fashion to bind views, a tool called ViewBinding. As the time of this article writing, it's an experimental tool available as of Android Studio 3.6 Preview Canary 11, that you can already start playing with.


  1. Download Android Studio 3.6 Preview Canary 11

But if you want to start from scratch, create a sample Android Project and update activity_main.xml with the following XML layout content:

4. Enable ViewBinding by adding viewBinding task in your build.gradle (app module) file

Note: If you already have dataBinding enabled on your project, you don’t need to add viewBinding support.

4. Sync your project and wait to finish building.

How ViewBinding works under the hood?

ViewBinding engine generates a 1:1 relationship between the binding class and the layout file. Regarding the sample project, a class ActivityMainBinding was "automagically" generated according to the activity_main.xml, containing references to nameField , surnameField and bindUserButton views that have id defined.

Besides, a getRoot() method is also generated to retrieve the root view for the underlying layout, the ConstraintLayout in our case. The code below shows MainActivity after updating it to call ActivityMainBinding.

We pretty much need to switch this code:

To this one:

Oh…wait, no more need to call R class? Yay! 🎉

ActivityMainBinding.inflate(LayoutInflater) inflates the whole layout hierarchy to access views. The ViewBinding mechanism abstract us about the real layout file access through the old R class. Instead, we pass binding.root as parameter to setContentView().

And after binding all views from ActivityMainBinding we get this result code:

Thanks to Kotlin conciseness nature, we can improve this code and avoid repeated call from binding by calling either with or apply functions:

What makes ViewBinding a so promising feature?

The new ViewBinding feature has some advantages compared to approaches aforementioned that makes it so promising to turn into a de-facto standard for view binding:

  • null-safety: The binding class is comprised by all view references that have ids defined in layout. And if the View can be nullable for a specific context (i.e. if a view is missing in some layout configuration), the view reference is generated with a @Nullable annotation for that view, thus avoiding catching NullPointerException.

ViewBinding vs. DataBinding

The main difference between the DataBinding approach is that we do not need to add <layout> tag via XML to enable data binding process. However, as the tool name suggests, the ViewBinding is supposed to bind only views but not data.

Wrapping up

We’ve just scratched the surface about the overall potential of ViewBinding feature. Looking forward to seeing community trying it out and improving it prior to AS 3.6 release. Some cool things that I'll try to explore on upcoming posts:

  • ViewBinding on Custom Views


If you enjoyed this post, please don’t hesitate to give 👏 to help spread it across community.

Happy code! :)

Ramon Ribeiro Rabello

Written by

Father, Speaker, Android Engineer @ Involves & Star Wars fan!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade