Hello ViewBinding, goodbye findViewById
It is often said that developers are lazy and that is (usually) a good thing. It just means that instead of repeating the same task or code over and over they tend to find ways to prevent that repetition and optimising their time.
Android developers for several years have tried to avoid the boiler plate code regarding findViewById . Let’s imagine you have the following layout:
If you needed to access the views above in your code and use the good old Java you would probably do something like this:
Sounds familiar ? 😅
findViewById — “the old way”
In order to skip this boiler plate many developers start using Butter Knife or even the old RoboGuice (a Dependency injection framework that allowed also the injection views — no longer maintained).
I believe that Butter Knife is still being used in many applications and its Github is still active but the library development will be winding down in favor of view binding.
If you are already using Kotlin in your applications you are probably using Kotlin Android Extensions 🎉
The libraries mentioned before require annotating fields for each exposed View. Kotlin Android Extensions is more easy to use, since it allows us to obtain the same final result of these libraries but without having to add any extra code. Let’s see:
Accessing the views and setting the texts are as easy as this. 😃
But enough of other view injection libraries and let’s see the ViewBinding.
findViewById — “the new (cool😎) way”
ViewBinding was announced at the Google I/O 19 has a new faster , simple and type/null safe way to bind views.
At this moment this is an experimental feature only available in Android Studio 3.6 Canary 11+.
So after downloading the Android Studio Canary 12 in order to start using ViewBinding you’ll need to enable it in the build.gradle file
Although official documentation does not mention it, you will also need to upgrade your Android Gradle Plugin to the 3.6.0-alpha11 or higher
Please take notice that the Gradle version to be used should be 5.6.1 or higher, take a look at your gradle-wrapper.properties and check if it is correct.
And now we are ready to start using ViewBinding!
Considering the previous example, using ViewBinding our code would look like this:
The binding class name is generated by converting the name of the XML file into camel case and adding the word “Binding” to the end. So in our case it would be ActivityMainBinding .
Our ActivityMainBinding class has two fields: a TextView called mainTitble and another TextView called subTitle. Any View in the layout which does not have an ID, there will be no reference to it in the binding class.
In order to access the root view of the corresponding layout file each binding class also includes a getRoot() method that provides a direct reference. In our example getRoot() method in the ActivityMainBinding class would return the RelativeLayout root view.
The generated binding class contains a static ActivityMainBinding.inflate(LayoutInflater) method that allows to retrieve an instance of the class. Basically what it does is inflating the whole layout hierarchy to access the views.
After that you just need to call setContentView passing the root view in order to make it the active view on the screen.
Main advantages
The new ViewBinding feature has some advantages compared to the traditional approach and some of the libraries:
- Null safety: view binding creates direct references to views, there’s no risk of a
NullPointerExceptiondue to an invalid view ID. Also, when a view is only exists regarding some conditions, the field containing its reference in the binding class is marked with@Nullable. - Type safety: All the View binding fields are generated matching the same type as the ones referenced in XML, so there’s no need to typecast. This means that the risk of a class cast exception is much lower, since If for some reason your layout and code doesn’t match, the build will fail at compile time instead at runtime.
- Speed: it doesn’t have any build time speed impact since it does not use annotation processors like ButterKnife or DataBinding.
ViewBinding vs DataBinding
At this point you are probably asking isn’t ViewBinding and DataBinding the same?
Both generate binding classes that you can use to reference views directly, but the are differences.
- DataBinding approach needs you to add
<layout>tag to your xml layout in oder to enable the data binding process; - ViewBinding doesn’t support layout variables or layout expressions, so it can’t be used to bind layouts with data in XML.
This was just a brief introduction to the ViewBinding and since it is an experimental feature it seems to have a lot of a potential.
References
Hope you enjoy this post and please don’t hesitate in sharing across the community 👏 🙂
