105

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?

Ehsan Mashhadi
  • 2,568
  • 1
  • 19
  • 30
Rinav
  • 2,527
  • 8
  • 33
  • 55
  • I created [somewhat similar question](https://discuss.kotlinlang.org/t/viewbinding-vs-kotlin-android-extensions/14691) on discuss.kotlinlang. If anyone has thoughts on the topic, feel free to respond :) – xinaiz Oct 17 '19 at 07:10
  • 1
    Take a look at [_The Argument Over Kotlin Synthetics_](https://proandroiddev.com/the-argument-over-kotlin-synthetics-735305dd4ed0) for some more background. – Cheticamp Oct 19 '19 at 14:19
  • 1
    Kotlin Android Extensions will be deprecated with Kotlin 1.4.20: https://proandroiddev.com/migrating-the-deprecated-kotlin-android-extensions-compiler-plugin-to-viewbinding-d234c691dec7 – Henning Nov 05 '20 at 13:25

4 Answers4

156

Let's review the two.


Configuration

Kotlin Android Extensions

  1. Import appropriate layout synthetic extensions: import kotlinx.android.synthetic.main.<layout>.*
  2. Reference views in code via their ids: textView.text = "Hello, world!". These extensions work on: Activities, Fragments and Views.

View Binding

  1. Create binding reference inside your class: private lateinit var binding YourClassBinding
  2. Inflate your binding 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
  3. Reference views in code via binding using their ids binding.textView.text = "Hello, world!"

Type safety

Kotlin Android Extensions and ViewBinding are type safe by definition, because referenced views are already casted to appropriate types.


Null safety

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:

enter image description here

So you just treat it as any other nullable type in Kotlin, and the error will disappear:

enter image description here


Applying layout changes

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


Incorrect layout usage

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.


Summary of KAE vs ViewBinding

  • Type safety - Draw.
  • Null safety - Draw.
  • Boilerplate code - KAE wins. From Kotlin Android Extensions documentation:

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.

  • Applying layout changes - KAE wins. Changes are instant in contrast to ViewBinding.
  • Incorrect layout usage - ViewBinding wins

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 :)

xinaiz
  • 7,744
  • 6
  • 34
  • 78
  • Why didn't you say anything about using variables in `DataBinding`? I think it's essential feature to stop using view references at all. By the way, you can "throw" your view model through `` tags, which is another big advantage. – Ircover Oct 21 '19 at 07:22
  • 4
    @Ircover The question was about comparsion of KAE and ViewBinding. DataBinding is not a part of that question. – xinaiz Oct 21 '19 at 08:06
  • Whoops, sorry) Simple misunderstanding. – Ircover Oct 21 '19 at 08:29
  • Allow me to point out that synthetic imports can lead to null pointer exceptions. Given an asynchronous task that doesn’t take advantage of LiveData you can end up with a null view and the compiler won’t warn you in any way. – Camarero Feb 13 '20 at 17:54
  • @EnricCamarero Isn't is the same with ViewBinding? The problem is that view is no longer attached, and none of the 2 utilities handle that. – xinaiz Feb 13 '20 at 18:03
  • @xinaiz I haven’t tried viewbinding yet as synthetic imports really do the trick for me. Idk if viewbinding is lifecycle aware but surely kotlin extensions aren’t (yet). – Camarero Feb 13 '20 at 19:05
  • Really nice explanation btw! @xinaiz – Camarero Feb 13 '20 at 19:05
  • 2
    ViewBinding definitely has an advantage in terms of null safety. Take the Fragment lifecycle for example: you can reference views in KAE in onCreateView before creating the parent layout. This is will go undetected at compile time but throw an NPE at runtime. With ViewBinding you must have a reference to the parent layout before referencing its children – Ben Lewis Feb 24 '20 at 20:39
  • 3
    @BenLewis if your binding defined as lateinit you still have the same problem. That means no meter what you use KAE or ViewBinding you have to follow some strict rules when writing code in the fragment. – Flavio Feb 24 '20 at 21:33
  • 3
    "Applying layout changes" - When using ViewBinding, you dont have to build your project, after adding a new view with an id, you can instantly do "binding.myTextView..". – Tayyab Mazhar Mar 01 '20 at 13:36
  • I think it's much more likely that you reference a single synthetic property wrongly than inflating a completely wrong binding layout. Because in the latter case no view would work anymore. So I find that View Binding has the upper hand in terms of null-safety – Florian Walther Jul 18 '20 at 16:02
47

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.

Squti
  • 4,171
  • 3
  • 10
  • 21
  • 1
    You also can use LayoutInflater to inflate View and then reference its defined fields via variable. – NapoleonTheCake Jan 16 '20 at 13:05
  • 22
    This seem very unlikely to happen in real life scenario. – Bencri Feb 17 '20 at 09:12
  • 11
    The example doesn't make sense. You used it incorrectly. Why would you import the incorrect thing (activity_other) ? Every framework that you use incorrectly can cause issues. – android developer Apr 02 '20 at 12:04
  • 1
    @Bencri It might happen by having different layout configurations. – John Jul 12 '20 at 10:27
  • 1
    as @Bencri said, this is very unlikely to happen, especially if you have your own naming conventions for the layouts, naming those views according to the screen it belongs. For example, you could rename `message_main` and `message_other` to both `main_message` and `other_message` to avoid ambiguity. – Dimas Mendes Jul 24 '20 at 21:38
  • 1
    Note that you should already be naming your ids uniquely for each layout, eg. `main_myText` vs `other_myText`, to avoid over-eager refactoring errors (and general ease of separating contexts). – Tom Aug 04 '20 at 18:34
14

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

Henning
  • 2,202
  • 1
  • 17
  • 38
  • 8
    This is the most reasonable reason why we should use viewBinding. lol – J.Dragon Nov 27 '20 at 15:09
  • Since I wrote that answer I started to refactor my code. There are things which were easier with synthetics but also more error prone. Discovered a few layout bugs I made with synthetics which aren't possible to make with ViewBinding. So it's a trade off speed and concisness for stability, I think it's a step in the right direction. – Henning Nov 28 '20 at 16:18
12

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. enter image description here

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

SourabhTech
  • 1,357
  • 12
  • 17
  • 25
    1. Always null-safe - View binding will still crash if used before inflation or after view lifecycle ends - nothing different from synthetics - should be RED for ViewBinding. 2. Only reference ids from current layout - that's true, but IDE points out from which layout you want to import given id, so it's not a big problem. 3. Supports Kotlin & Java - bad argument, if you can use Kotlin in android development then why use Java. 4. Amount of code needed - Kotlin synthetics has lowest amount, should be Very low in the table. – xinaiz Mar 11 '20 at 09:45
  • @xinaiz Why you are using it before inflating, follow the correct way to use it otherwise for sure you will face the issues. Have you gone through the link before downvote and posting the comment https://medium.com/androiddevelopers/use-view-binding-to-replace-findviewbyid-c83942471fc – SourabhTech Mar 11 '20 at 11:24
  • 6
    Yes, I have read it some time ago. I'm not using it before inflating, I'm just saying it's possible. "Correct way" implies that there are risks, right? Also, you skipped `or after view lifecycle ends` part? – xinaiz Mar 11 '20 at 11:38
  • @xinaiz 2.But there is a chance to use wrong id if project is bigger and also for same resource name if multi developer working on project. 3.Yes there could be a project requirement where you have to use java and kotlin both(If project is already developed in java and started intrigation with kotlin then definitely it helps) 4. For Synthetics you have to import separate library but for view binding it's already there in Gradle, So obviously it's took lesser code. – SourabhTech Mar 11 '20 at 11:38
  • @xinaiz So are you going to use the view id after view lifecycle end? Do you think id should be there and we have to follow that practices to knowingly to create the issues. – SourabhTech Mar 11 '20 at 11:41
  • Android development is asynchronous, so it's easy for background task to end when view is no longer available, f.e. your code tries to access the views in callback and boom, NPE. Sure, fixed by LiveData, but the safety is not associated with ViewBinding :) – xinaiz Mar 11 '20 at 11:44
  • 4
    In response to 4. What library? It's enabled by default. It's argument about `apply plugin: 'kotlin-android-extensions'` vs `viewBinding { enabled = true }`. Not much difference. – xinaiz Mar 11 '20 at 11:48
  • 1
    @xinaiz I think you have to go through the documentation for get the clearer picture. https://developer.android.com/topic/libraries/view-binding For your information you have to nullify the binding object when onDestoryView() gets called, it will prevent form crash during callback if. And gentleman you have to stick with one statement, in first comment you have replied synthetics has lowest code and in recent comment telling there is no much difference in both (Which is already mentioned in image). – SourabhTech Mar 11 '20 at 12:16