I\'m reading about how the MVVM architecture works and how to use Android Data Binding Library help.
In a very general way I understand that Android Data Binding creates
I strongly disagree with the points mentioned above. maybe because I hate writing logic in XML. so both comments mention the use of <data>
tags not found in Kotlin Android Extensions (KTX). with kotlin and KTX you can do better than data tag.
let's say we have
data class Person(val name:String,
val phone:String,
val isMale:Boolean,
val isMarried:Boolean)
in the activity or fragment, we can do
fun updateView(data:Person){
with(data){
nameTextField.text = if(isMale){
"Mr. $name"
} else {
if(isMarried){
"Mrs. $name"
}else{
"Miss $name"
}
}
phoneTextField.text = phone
}
}
in data-binding, you have to do
android:text='@{person.isMale ? "Mr."+user.name: ((user.isMarried ? "Mrs. " :
"Miss. ") + user.name)}'
KTX code is way cleaner than what you have to do with data binding to achieve the same result. when you need conditions to set values to view data binding gets ugly. so for me, Kotlin Android Extensions work better. I like my code clean. you can still use both the decision is yours to make.
Kotlin Android Extensions does not stand for only view binding. It contains other features as well. But I guess you’re talking about the view binding/caching features of Kotlin Android Extensions and wonder whether we still need data binding, since we already got rid of the findViewById calls with the synthetic properties of Kotlin. That was the question I asked to myself and my conclusion is, yes, data binding is still worth using.
From official documentation:
The Data Binding Library creates an immutable field in the binding class for each view that has an ID in the layout… The library extracts the views including the IDs from the view hierarchy in a single pass. This mechanism can be faster than calling the findViewById() method for every view in the layout.
So data binding doesn’t call findViewById on views one by one. Kotlin’s synthetic classes, on the other hand, still calls findViewById on the views under the hood, but it calls it only once for each view and caches the view reference for next calls. (Here is an article about it)
Besides, data binding has more to offer than only view caching. You can use data tags for passing data to the binding implementation and declare them in your xml, instead of setting them programmatically. This way you can get rid of the boilerplate code that you use for populating data, like those "setText"s, "setImageResource"s etc. You can set event listeners from xml using data binding. You can also come up with your own attributes using custom binding adapters. When used to its whole power, it can significantly reduce your Java/Kotlin code.
Edit: It seems that Google Android team recommends against use of kotlin synthetic properties. This article summarizes the discussion around this issue. And you can see in the new Udacity course prepared by Google that they use data binding as recommended practice.
Edit2: If you don't like the idea of "putting business logic in your xml", if you are not interested in setting or getting data from xml, if you simply want to avoid use of findViewByIds in a safe and efficient manner, than you can go with ViewDataBinding library instead. It is a simplified version of data binding library. It doesn't let you set data from your xml but it binds your views in a safe and efficient manner.
Both, Kotlin Android Extensions and Android Data Binding Library help to eliminate the use of findViewById
.
But there are also more things that these do, that can complement one another.
To elaborate, with the Android Data Binding library, you can 'set' models in your xml files, which can then directly be leveraged to set values for the views in the layout. See how a <data>
tag can be used with the data binding library.
Kotlin android extensions does not provide for this.
At the same time, Kotlin android extensions provides for some amazing features like @parcelize
annotation to make classes parcelable with almost no boilerplate code, etc.
To conclude, while they both eliminate the use of findViewById
, they have their own features too which can complement one another well.