Brand new view binding tool — ViewBinding user guide

Preface

In the process of Android development, we always need to get the ViewId in the XML layout in order to assign a value to it for display. In the early days, we could only use the findViewById API, which would cause a lot of template code to appear. Around 2013, the Android world god Jake Wharton open sourced the Butter Knife framework, which makes it easy for developers to obtain ViewId through Bind ("viewid"). Due to Google's support for Kotlin in the past two years, we have started to use Android Kotlin extensions. Import the layout file in the file and directly reference the viewId. No need to do other additional operations, the most convenient.

Currently, Google has added a new view binding tool ViewBinding in Android Studio 3.6 Canary 11 and higher.

Let's take a look at the specific use.

Use ViewBinding

We are now developing many projects that use modularity to develop. ViewBinding is also very smart and can be enabled according to the module. If you want to enable ViewBinding in a module, you need to add the following configuration in the module's build.gradle:

android {
    
    ...
    
    viewBinding {
        enabled = true
    }

}

If the developer does not want to generate a binding class for a certain layout file during use, he can use the following attributes to add it to the root view of the layout:

<LinearLayout
        ...
        tools:viewBindingIgnore="true" >
        
    ...
    
</LinearLayout>

When the module opens the view binding function, the system will generate the corresponding binding class for each XML file in the module. Each binding class contains a reference to the follow view and all views with IDs defined.

The name generation rule of the binding class is to end the name of the XML file according to the camel case naming rule plus Binding.

For example, our activity_main.xml file.

<LinearLayout ... >
    <TextView android:id="@+id/name" />
    <ImageView android:cropToPadding="true" />
    <Button android:id="@+id/button"
        android:background="@drawable/rounded_button" />
</LinearLayout>

Then the binding class name produced is ActivityMainBinding. This class has two fields: one is a TextView named name, and the other is a Button named button. The ImageView in this layout has no ID, so there is no reference to it in the binding class.

Each binding class also contains a getRoot() method, which provides a direct reference to the root view of the layout file. In this example, the getRoot() method in the ActivityMainBinding class returns the LinearLayout root view.

The automatically generated binding class is not complicated, mainly two inflate overload methods and a bind method. The reference to viewId we get is done in the bind method, and the internal view is actually obtained through findViewById.

We usually set the layout file through setContentView("layoutId"), but after using ViewBinding, we need to set the layout as follows:

class MainActivity : AppCompatActivity() {

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

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

         //获取name进行赋值
        binding.name.text = "viewBinding"
    }
}

This can be used directly. Is it very simple?

But it should be noted that if our layout file is divided into layout and layout-land, we may have different viewIds when we define the layout. If we use findViewById or Butter Knife, then it must be abnormal.

When we use ViewBinding, the binding class intimately made relevant judgments for us. Use the two annotations @Nullable and @NonNull to tell developers which views may be empty. And added related gaze instructions on the view that may be empty.

  /**
   * This binding is not available in all configurations.
   * <p>
   * Present:
   * <ul>
   *   <li>layout/</li>
   * </ul>
   *
   * Absent:
   * <ul>
   *   <li>layout-land/</li>
   * </ul>
   */
  @Nullable
  public final TextView mAppTv;

Remind developers to pay attention to exception handling when using. ​

to sum up

At present, the function of ViewBinding is not perfect. For example, when the inClude tag is used in XML, the view cannot be referenced. But overall it is pretty good. Compared to findViewById and Butter Knife, it is much more convenient. And there is no type conversion and null pointer exception in the process of using ViewBinding. Because all have been defined in the binding class. Developers can use it directly. Compared with Android Kotlin extensions, I think they are similar. Can't say who is better. Compared with databinding, the data binding library only deals with data binding layouts created using code. It has limitations.

Currently Jake Wharton also added the following sentence to the Butter Knife open source library:

Attention: Development on this tool is winding down. Please consider switching to view binding in the coming months.

Presumably, the status and role of ViewBinding in the future will be self-evident.

Original: https://segmentfault.com/a/1190000021280566?utm_source=tag-newest