Kotlin Android View Binding: findViewById vs Butterknife vs Kotlin Android Extension

问题

I'm trying to figure out the best way to do Android View Binding in Kotlin. It seems like there are a few of options out there:

findViewById

val button: Button by lazy { findViewById<Button>(R.id.button) }

Butterknife

https://github.com/JakeWharton/butterknife

@BindView(R.id.button) lateinit var button: Button

Kotlin Android Extensions

https://kotlinlang.org/docs/tutorials/android-plugin.html

import kotlinx.android.synthetic.main.activity_main.*

I'm pretty familiar with findViewById and Butterknife in java land, but what are the pros and cons of each view binding approach in Kotlin?

Does Kotlin Android Extensions play well with the RecyclerView + ViewHolder pattern?

Also how does Kotlin Android Extensions handle view binding for nested views via include?

ex: For an Activity using activity_main.xml, how would View custom1 be accessed?

activity_main.xml

<...>
    <include layout="@layout/custom" android:id="@+id/custom" />
</>

custom.xml

<...>
    <View android:id="@+id/custom1" ... />
    <View android:id="@+id/custom2" ... />
</>

回答1:

kotlin-android-extensions is better for Kotlin. ButterKnife is also good but kotlin-android-extensions is a better and smart choice here.

Reason : Kotlin uses synthetic properties and those are called on demand using caching function(Hence slight fast Activity/Fragment loading) while ButterKnife binds all view at a time on ButterKnife.bind()(that consumes slight more time). With Kotlin you don't even need to use annotation for binding the views.

Yes it also plays good with RecyclerView + ViewHolder pattern, you just need to import kotlinx.android.synthetic.main.layout_main.view.*(if layout_main.xml is Activity/Fragment layout file name).

You do not need to do any extra effort for layout imported using include. Just use id of imported views.

Have a look at following official documentation notes:

Kotlin Android Extensions is a plugin for the Kotlin compiler, and it does two things:

Adds a hidden caching function and a field inside each Kotlin Activity. The method is pretty small so it doesn't increase the size of APK much.

Replaces each synthetic property call with a function call.

How this works is that when invoking a synthetic property, where the receiver is a Kotlin Activity/Fragment class that is in module sources, the caching function is invoked. For instance, given

class MyActivity : Activity()
fun MyActivity.a() { 
    this.textView.setText(“”)
}

a hidden caching function is generated inside MyActivity, so we can use the caching mechanism.

However in the following case:

fun Activity.b() { 
    this.textView.setText(“”)
}

We wouldn't know if this function would be invoked on only Activities from our sources or on plain Java Activities also. As such, we don’t use caching there, even if MyActivity instance from the previous example is the receiver.

Link to above documentation page

I hope it helps.

回答2:

I can't flag this question as a duplicate, as you're asking multiple things that have been answered / discussed under different questions.

What are the pros and cons of each view binding approach in Kotlin?

This has been discussed here.

How does Kotlin Android Extensions handle view binding for nested views via include? ex: For an Activity using activity_main.xml, how would View custom1 be accessed?

All Kotlin Android Extensions does is call findViewById for you. See here.

Does Kotlin Android Extensions play well with the RecyclerView + ViewHolder pattern?

Yes, it does. However, you have to use save the Views you get from it into properties, as there is no cache for them like in Activities or Fragments. See here.

If you still have unanswered questions, feel free to ask for clarification.

回答3:

Take care of using

val button: Button by lazy { findViewById<Button>(R.id.button) }

I already confront the problem when the view is destroyed, and as the instance of your fragment survive(I think in the case of acitivities it doesn't apply), they hold the lazy property referencing to the old view.

Example:

You have an static value in the layout, let say android:text="foo"

//calling first time
override fun onViewCreated(view: View?, savedInstanceState: Bundle?) {
    button.setText("bar")
    // button is called for the first time, 
    // then button is the view created recently and shows "bar"
}

Then the fragment get destroyed because you replace it, but then ou comeback and it regenerated callin onCreateView again.

//calling second after destroyed
override fun onViewCreated(view: View?, savedInstanceState: Bundle?) {
    button.setText(Date().time.toString())
    //button is already set, then you are setting the value the to old view reference
    // and in your new button the value won't be assigned
    // The text showed in the button will be "foo"
}

回答4:

There are a lot of ways to access views in Android. A quick overview:

My advise would be:

findViewById: old school. Avoid.
ButterKnife: old school, but less boilerplate and some added functionality. Still lacks compile time safety. Avoid if possible.
Kotlin Synthetic: really a elegant cached version of findViewbyId. Better performance and way less boilerplate but still no compile time safety. Best option if compile time safety is not needed.
ViewBinding: Somewhere in between option 1-3 and Databinding. But lacks powerful options of DataBinding (like 2 way data binding and using variables inside XML files).
Data Binding: most powerful option. Integrates really nice with LiveData and ViewModels (JetPack) to create reactive UI's (similar to RxJava). Can slow down build times (uses annotation processor just like ButterKnife) on large projects/UI's. My strong personal preference.

See also: https://www.youtube.com/watch?v=Qxj2eBmXLHg

Funny to note that Jake Wharton (original author of ButterKnife) has now joined Google and works on ViewBinding.

回答5:

Now there is a fourth option which is called View Binding, available with Android Studio 3.6 Carnary 11

Quoting from docs.

View Binding

View binding is a feature that allows you to more easily write code that interacts with views. Once view binding is enabled in a module, it generates a binding class for each XML layout file present in that module. An instance of a binding class contains direct references to all views that have an ID in the corresponding layout.

In most cases, view binding replaces findViewById.

Differences from findViewById

View binding has important advantages over using findViewById:

Null safety: Since view binding creates direct references to views, there's no risk of a null pointer exception due to an invalid view ID. Additionally, when a view is only present in some configurations of a layout, the field containing its reference in the binding class is marked with @Nullable.

Type safety: The fields in each binding class have types matching the views they reference in the XML file. This means that there's no risk of a class cast exception.

Differences from the data binding library

View binding and the data binding library both generate binding classes that you can use to reference views directly. However, there are notable differences:

The data binding library processes only data binding layouts created using the <layout> tag.

View binding doesn't support layout variables or layout expressions, so it can't be used to bind layouts with data in XML.

Usage

To take advantage of View binding in a module of your project, add the following line to its build.gradle file:
android {
    viewBinding.enabled = true
}
For example, given a layout file called result_profile.xml:
<LinearLayout ... >
    <TextView android:id="@+id/name" />
    <ImageView android:cropToPadding="true" />
    <Button android:id="@+id/button"
        android:background="@drawable/rounded_button" />
</LinearLayout>
In this example, you can call ResultProfileBinding.inflate() in an activity:
private lateinit var binding: ResultProfileBinding

@Override
fun onCreate(savedInstanceState: Bundle) {
    super.onCreate(savedInstanceState)
    binding = ResultProfileBinding.inflate(layoutInflater)
    setContentView(binding.root)
}
The instance of the binding class can now be used to reference any of the views:
binding.name.text = viewModel.name
binding.button.setOnClickListener { viewModel.userClicked() }