Detailed explanation of Android using View Binding

Preface

The stable version of Android Studio released version 3.6, which brought about one new change: first, the appearance and startup page changed, and logo changed and became more modern; Add Multi Preview function, which can preview the display effect of multiple sizes of screens at the same time; The simulator supports multiple screens; Finally, it supports the new view binding component View Binding;; Wait.

Previously, we interacted with views in findViewById. After Android, Kotlin and Extensions were introduced into kotlin, we accessed them directly through id. The former is seriously templated and has many duplicate codes; The latter is the most convenient. Now there is a new choice View Binding, official explanation:

With the view binding function, you can write code that interacts with views more easily. When view binding is enabled in a module, one binding class is generated for each XML layout file in the module. An instance of the binding class contains a direct reference to all views that have ID in the corresponding layout.

In most cases, view binding will replace findViewById.

Use

View Binding can be enabled by module. To enable it in a module, add the following configuration to the module's build. gradle:

android {
  ...
  viewBinding {
   enabled = true
  }
 }

Usage

When View Binding is enabled for a module, one binding class is generated for each XML layout file included in the module. Each binding class contains references to the root view and all views with id. The class name of the bound class is the name of xml followed by "Binding".

For example, suppose a layout file name is, for example, activity_main. xml:

<LinearLayout ... >
  <TextView android:id="@+id/tvName" />
  <TextView android:text="no id"/>
  <Button android:id="@+id/btnOpen"/>
</LinearLayout>

Then the generated binding class name is ActivityMainBinding. This class has two member variables, tvName and btnOpen, and contains an getRoot () method that returns the root view, in this case LinearLayout.

To get an instance of the bound class, you can use the static inflate () method.

private lateinit var binding: ActivityMainBinding

@Override
fun onCreate(savedInstanceState: Bundle) {
 super.onCreate(savedInstanceState)
 binding = ActivityMainBinding.inflate(inflater)
 setContentView(binding.root)
}

Now, an instance of the bound class can be used to reference any view:

binding.tvName = "name"
binding.btnOpen.setOnClickListener{
 Log.d(TAG,"btnOpen click")
}

Difference

Different from findViewById: Null-safe and type-safe, there is no null pointer exception or type conversion exception caused by referencing 1 error id. Difference from databinding: databinding only handles the use of < layout > Data binding layout created by code; View Binding does not support layout variables or layout expressions, so it cannot be used to bind layout to data in xml. Difference from Android Kotlin Extensions: In use, the latter is simple and rude, which is accessed directly by id, while View Binding needs to create an instance of binding class; The latter has some unfriendly points. For example, the same id exists in multiple xml, which is easy to lead wrong packets. If the packets are led wrong, it is possible that other View uses the wrong id to lead to null pointers, but View Binding obviously does not have this situation.

Summarize

If you choose with findViewById or other View injection frameworks, it is recommended to choose View Binding for simpler and safer code.

If it is a project using databinding, you can use View Binding as a supplement to deal with non- < layout > Is the xml of the root label. (ps: It seems impossible to have such a scene? This scenario should also be avoided, after all, too many classes will affect the speed of build and increase the size of the installation package.)

Choose with Android Kotlin Extensions. At present, there is no optimal solution, and both of them are very good, depending on whether developers want to maximize development efficiency, concise and easy to use (Android Kotlin Extensions) or tend to be robust and minimize error probability (View Binding).

By the way, View Binding currently does not support xml introduced by include tag. We still need to pay close attention to its subsequent versions for the improvement of View Binding's functions, its position and role in the future, and whether it can surpass Android Kotlin Extensions.