How does the new ViewBinding compare with the Kotlin Android Extensions with synthetic views bindings?
Apart from the NullSafety and TypeSafety provided by new ViewBindings, why should we consider ditching the Kotlin way of using synthetic bindings on Views?
Is the new ViewBinding more performant since it generates the Binding class beforehand?
Synthetic properties to access views were created as a way to eliminate the common boilerplate of findViewById calls. These synthetics are provided by JetBrains in the Kotlin Android Extensions Gradle plugin (not to be confused with Android KTX).
Kotlin Android Extensions is deprecated, which means that using Kotlin synthetics for view binding is no longer supported.
If your app uses Parcelable you can use 'kotlin-parcelize' instead of 'kotlin-android-extensions' . If your app uses Kotlin synthetics for view binding, use this guide to migrate to Jetpack ViewBinding or Data Binding.
findViewById. Recently Android has announced that with Kotlin 1.4. 20, their Android Kotlin Extensions Gradle plugin will be deprecated and will no longer be shipped in the future Kotlin releases.
Kotlin Android Extensions is deprecated, which means that using Kotlin synthetics for view binding is no longer supported. If your app uses Kotlin synthetics for view binding, use this guide to migrate to Jetpack view binding. If your app does not already use Kotlin synthetics for view binding, see View binding for basic usage information.
Kotlin Android Extensions are officially deprecated. The biggest blow from that for most is the loss of Synthetics, which allowed you to replace calls to findViewById () with the view’s id from the layout file.
Now for Kotlin synthetics, which have ruled the Android development world for the last three years in terms of importing views. Synthetics are part of the Kotlin Android extension developed by JetBrains. Synthetics make it much simpler and easier to bind the views in code.
According to android’s documentation: View binding is a feature that allows you to more easily write code that interacts with views. You can think of viewBinding as a replacement for findViewById function. You enable it first in the build.gradle file and after that it will generate binding classes for your XML layouts.
Let's review the two.
import kotlinx.android.synthetic.main.<layout>.*
textView.text = "Hello, world!"
. These extensions work on: Activities
, Fragments
and Views
. private lateinit var binding
YourClassBinding
binding = YourClassBinding.inflate(layoutInflater)
inside Activity
's onCreate
and call setContentView(binding.root)
, or inflate it in Fragment
's onCreateView
then return it: return binding.root
binding.textView.text = "Hello, world!"
Kotlin Android Extensions and ViewBinding are type safe by definition, because referenced views are already casted to appropriate types.
Kotlin Android Extensions and ViewBinding are both null safe. ViewBinding doesn't have any advantage here. In case of KAE, if view is present only in some layout configurations, IDE will point that out for you:
So you just treat it as any other nullable type in Kotlin, and the error will disappear:
In case of Kotlin Android Extensions, layout changes instantly translate to generation of synthetic extensions, so you can use them right away. In case of ViewBinding, you have to build your project
In case of Kotlin Android Extensions, it is possible to import incorrect layout synthetic extensions, thus causing NullPointerException
. The same applies to ViewBinding, since we can import wrong Binding
class. Although, it is
more probable to overlook incorrect import than incorrect class name, especially if layout file is well named after Activity
/Fragment
/View
, so ViewBinding has upper hand here.
The Kotlin Android Extensions plugin allows us to obtain the same experience we have with some of these libraries, without having to add any extra code.
I think there is big misconception about ViewBinding being replacement for KAE. People hear big keywords and repeat them without verifying it beforehand. Sure, ViewBinding is best option for Java development right now (replacement for ButterKnife), but there is no or little advantage over KAE in Kotlin (see Incorrect layout usage section).
Side note: I'm sure DataBinding people will like ViewBinding :)
ViewBinding
solved the biggest problem of kotlinx.android.synthetic
. In synthetic
binding if you set your content view to a layout, then type an id that only exists in a different layout, the IDE lets you autocomplete and add the new import statement. Unless the developer specifically checks to make sure their import statements only import the correct views, there is no safe way to verify that this won’t cause a runtime issue. But in ViewBinding
you should use your layout
binding object to access its views so you never invoke to a view in a different layout and if you want to do this you will get a compile error not a runtime error. Here is an example.
We create two layouts called activity_main
and activity_other
like so :
activity_main.xml
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:id="@+id/message_main"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
/>
</RelativeLayout>
activity_other.xml
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
>
<TextView
android:id="@+id/message_other"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
/>
</RelativeLayout>
Now if you write your activity like this:
import android.os.Bundle
import android.support.v7.app.AppCompatActivity
import kotlinx.android.synthetic.main.activity_other.*
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
//Application will crash because "message_other" doesn't exist in "activity_main"
message_other.text = "Hello!"
}
}
your code will compile without any error but your application will crash at runtime. Because the view with message_other
id doesn't exist in activity_main
and the compiler didn't check this. But if you use ViewBinding
like so:
class MainActivity : AppCompatActivity() {
private lateinit var binding: ActivityMainBinding
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
binding = ActivityMainBinding.inflate(layoutInflater)
setContentView(binding.root)
//This code will never compile and the IDE shows you an error
binding.message_other.text = "Hello!"
}
}
your code will never compile and Android Studio
shows you an error in the last line.
Kotlin Android Extensions was deprecated with Kotlin 1.4.20 so I would recommend to use ViewBinding.
https://proandroiddev.com/migrating-the-deprecated-kotlin-android-extensions-compiler-plugin-to-viewbinding-d234c691dec7
kotlinx.android.synthetic is no longer a recommended practice, said by google in one commit message "one of Reddit thread
https://android-review.googlesource.com/c/platform/frameworks/support/+/882241 "
Synthetics is not developed by google, it's a part of kotlin android extension crafted by JetBrains and gradually google android developers started replacing the Synthetics with the ViewBindins in their demos and source-codes.
"Now question comes, which one we have to take it in consideration."
According to google (View binding, ButterKnife, Kotlin synthetics) these libraries are used successfully by many apps and solve the same problem.
But for most of the apps google recommend trying out view binding instead of these libraries Because view binding provides safer, more concise view lookup.
Attached reference image to clear things quickly.
However if you would like to go in dept you can follow the given below link. https://medium.com/androiddevelopers/use-view-binding-to-replace-findviewbyid-c83942471fc
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With