Kotlin Synthetics and View Binding

Last week I wrote about some of the advantages of using Kotlin instead of Java for Android app development. In it I listed “synthetic imports” as one of the advantages, saying:

Synthetic imports. Particular to Android development, Kotlin has direct access to views in the layout XML through synthetic imports whereas in Java you’d need to “findViewById” to  access each individual element. I find this very reminiscent of the jump from vanilla JS to React: React allows for direct access to other React components through imports, largely avoiding the need to use “querySelector” or “getElementById” which are ubiquitous in vanilla JS DOM manipulation.

However when I tried to implement this into my Android app I was surprised to learn this functionality is already deprecated! This sent me down a rabbit hole of research into the not-so-distant history of the rapidly-changing landscape of Android development. Resources scantly a couple years old indicate this was the preferred if not ubiquitous means of achieving direct access to Android components (Views) at that time, and yet Kotlin Android Extensions, the plugin which enabled synthetic imports, is indeed deprecated as of Kotlin 1.4.20 (released November 2020).

So what are we supposed to do now? Revert to the trusty old findViewById which carried Android development through its entire Java adolescence? Not so.

Introducing View Binding, a built in feature of Android Studio as of 3.6. View binding evolved out of Data Binding, and it is important not to confuse the two. Data Binding is several years older and has a much broader scope than View Binding. Data Binding is comparatively heavy, leading to longer compile times, and comes with specific requirements for the structure of your XML layout files so if you just want direct access to Views and have no need of the other advanced features of Data Binding you should choose View Binding instead.

Though View Binding is a built in feature, it must be enabled in your project’s Module build.gradle file before it can be used:

android {
    ..
    buildFeatures {
        viewBinding true
    }
}

Data Binding can be enabled in precisely the same way (swapping data in place of view). In some cases you may even want to enable both within the same project if you want to use the full power of Data Binding in some areas and the more streamlined View Binding in others.

So now that it’s enabled, how do we use View Binding? A variable, by convention named binding, will grant us direct access to our Views in our Activity’s layout by their id with simple dot notation like so:

binding.viewId

To get access to the Views, the binding variable must be bound to the Activity’s layout file. This is accomplished in the Activity’s onCreate override, just after the super.onCreate call, where we will declare our binding variable and setContentView to it:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    val binding = ActivityMainBinding.inflate(layoutInflater)
    setContentView(binding.root)
}

Replace Main with the name of the Activity you are working in. Note that it is ActivityMainBinding and not MainActivityBinding— this makes sense because we are trying to bind to the XML layout and as we know the layout filenames always lead with Activity rather than end with it like so: activity_main.xml.

So in the code block above we can see that we are inflating the XML layout, saving that to a variable, and then setting the content view to the root level of that variable. This understandably places our binding variable at the intersection between the inflated layout and our app code, granting us easy, null-safe access to our Views for whatever purpose we require, for example setting an event listener to a button:

binding.addBtn.setOnClickListener {
    ..
}

And there we go. View Binding is I think quite intuitive and streamlined and I can appreciate why Kotlin synthetics were deprecated in favor of it. I continue to be fascinated by the rapid change and evolution ongoing in Android development such as the jump from Java to Kotlin and other major reworkings. It creates the impression that we are still in early days with Android and I look forward to the improvements and advancements to come over the next decade.