Preface
During Android development, we always need to obtain the ViewId in the XML layout to assign values to 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 master Jake Wharton opened the Butter Knife framework, which facilitates developers to obtain ViewId through Bind ("viewid"). In the past two years, due to Google's support for Kotlin, we have started using Android Kotlin extensions. Import the layout file into the file and directly refer to the viewId. No additional operations are required, it is most convenient.
Currently, Google has added a new view binding tool ViewBinding in Android Studio 3.6 Canary 11 and later.
Let's take a look at the specific use.
Use of ViewBinding
Many projects we are developing now are developed using modularity. ViewBinding is also very clever to enable it according to the module. If you want to enable ViewBinding in a module, you need to add the following configuration to the module:
android {
...
viewBinding {
enabled = true
}
}
If the developer does not want to generate a binding class for a layout file during use, you can add it to the root view of the layout using the following properties:
<LinearLayout ... tools:viewBindingIgnore="true" > ... </LinearLayout>
When the module enables the view binding function, the system will generate the corresponding binding class for each XML file in the module. Each binding class contains references to the root view and all views whose ID is defined.
The name generation rule for binding classes is to end the name of the XML file according to the camel naming rules plus Binding.
For example, our activity_main.xml file.
<LinearLayout ... > <TextView android: /> <ImageView android:cropToPadding="true" /> <Button android: android:background="@drawable/rounded_button" /> </LinearLayout>
Then the name of the binding class 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 that 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 classes are not complicated, mainly two inflate overload methods and one bind method. The reference to viewId we obtain is performed in the bind method, and the relevant 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?) {
(savedInstanceState)
val binding = (layoutInflater)
setContentView()
//Get name for assignment = "viewBinding"
}
}
This way you can use it directly. Isn't it very simple?
But it should be noted that if our layout files are divided into layout and layout-land, we may have different viewIds when defining the layout. If we use findViewById or Butter Knife, it will definitely be abnormal.
When we were using ViewBinding, the binding class made relevant judgments for us. Tell the developer which views may be empty through the annotations @Nullable and @NonNull. And added relevant gaze instructions on the possible empty view.
/** * 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 it.
Summarize
At present, the functions of ViewBinding are not perfect enough. For example, when the inClide tag is used in XML, the view cannot be referenced. But overall it's already pretty good. Compared with the two methods of findViewById and Butter Knife, it is much more convenient. Moreover, there is no problem of type conversion or null pointer exception during use of ViewBinding. Because it has been defined in the binding class. Developers can use it directly. Compared with Android Kotlin extensions, I think the two are similar. Can't say who's better. Compared with databinding, the data binding library only processes data binding layouts created using <layout> code. It has limitations.
Currently, Jake Wharton has 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.
Supplement: The difference from findViewById
View binding has important advantages over using findViewById:
•Null Security: Since view binding creates a direct reference to the view, there is no risk of null pointer exceptions due to invalid view IDs. Additionally, when the view exists only in some configurations of the layout, the fields that contain its reference in the binding class will be @Nullable
• Type Security: The fields in each binding class have a type that matches the view it references in the XML file. This means there is no risk of class cast exceptions.
These differences mean that incompatibility between layout and code will cause compilation to fail at compile time rather than at runtime.
The difference from the data binding library
Both view binding and data binding libraries generate binding classes that can be used to directly reference views. However, there are obvious differences:
•The data binding library only handles data binding layouts created with tags.
•View binding does not support layout variables or layout expressions, so it cannot be used to bind layouts to XML data.
This is the article about the detailed usage of the new view binding tool ViewBinding in Android Studio 3.6. For more related contents of the Android view binding tool ViewBinding, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!