Does anyone here feel that using DataBinding is he...
# android-architecture
s
Does anyone here feel that using DataBinding is heavy (apk Size) and slow to build?
r
Well you use the code gen more with databinding. As far as APK size, that's pretty trivial, and depends how you write your code. But the benefits out weigh the cost
g
I'm still waiting for that moment :) Until then I'll use synthetics.
g
DataBinding is heavy
Why?
slow to build
For sure
s
Why?
=> APK size, and after changing XML I compared the 2 projects (medium project) together, and found that the project using databinding took a long time to run + compile + build, and my laptop also ran very slowly + the sound of the laptop’s running really loud.
g
APK size? Runtime library is not so big, especially comparing to many other libraries. Of course generated code of every binding increase size, but it is code that you do not write manually, also it has better changes handling than simple manual implementation What exactly do you comparing? 2 different projects? What is "a long time to run"?
s
What exactly do you comparing? 2 different projects?
=> I mean the same code base. What are the cons of android data-binding you have faced to in your project ?
r
None lol. Databinding is good
The component itself is good .
There are just bad code lol... The thing is about build speeds, is whenever you have generated code build speeds will also be affacted
Reason being is that the actual processor goes thru one upto several rounds of code generation. But that would be the same for using anything with a code gen backing it(butterknife, dagger, ect..).. but alot of databinding code gen happens on the fly, so even that is improved.a
g
@Sam a lot of cons. Bad IDE support for Databindings, sometimes you can navigate it, sometimes not, it's often red in your xml because you need to recompile 10 times, not easy to copy&paste layouts because of VM dependency. Compatibility issues with gradle plugin, when bindings are broken and don't complie. Learning curve: Observable, Adapters (useless, because of kotlin extensions), BR file, notifyProperty, etc. Compile time of course, verbosity... What for? To do
label.text = text
? Nah, thanks. Throw synthetics to your project and move on, spend your time on something meaningful.
g
Bad IDE support for Databindings
Agree, but it’s finally improved a lot in AS 3.6
s
Thanks guys. really good insight about databinding…
Noted for next project.
r
Lol that's not true @ghedeon there is IDE support for databinding. And it's never red in your XML, unless your doing something wrong..
And there is no gradle conflict , it automatically works once you add the add the one line enabled databinding
g
Honestly, @rkeazor, I don't remember a single case when you didn't advocate for whatever google is pushing in their docs: Databindings, LiveData, Navigation, etc., and it's always "perfect, not a single downside". Eventually I just started to label your posts as promotional in my head, lol 🙂. Anyhow, I'm glad that it always works for you! Different people, different experiences.
r
@ghedeon And your my alter ego. Because your agianst anything Google releases 😂 ... I would be surprised if there is a single Google API you like lol. I dont claim things are perfect but I can see where there devs are trying to go with things and they have made drastic improvements... When I started android , people were creating headless fragments and just to retainInstance and eventbus asyntask where in everybody's codebase. But the ecosystem has improved drastically since then
And the jetpack components where a good addition. But alot people just hate on google no matter what they release. Even if they have never used that component 😂... its not really about different people and different experience, just toggle databinding on and try it for yourself lol. There is IDE support.if you click alt enter in any layout you will get a option to convert to a databinding layout, you can auto complete variable declarations, you can click into any standard and it will take you to the binded variable in the source.. Only time things turn red is when you haven't imported a namespace. You dont have to rebuild your project.
s
I’m facing with this problem when convert java to kotlin with databinding ….. really tired :)))
g
so, it cannot resolve type, what exactly are you converting?
s
I convert the whole Java project to Kotlin, and its happen, I’m digging into these code to find the way to fixing it .
r
When you switch from Java to Kotlin did you add the plugin for kotlin kapt?
If so try check the variables your actually binding and make sure there types actually still make sense,-Something might have got messed up if you just used the convert Java to kotlin tool
s
When you switch from Java to Kotlin did you add the plugin for kotlin kapt?
=> not this error
If so try check the variables your actually binding and make sure there types actually still make sense,-Something might have got messed up if you just used the convert Java to kotlin tool
=> yes, a lot of variables is not suitable for lasted kotlin version
r
Alot of versions are not suitable for the latest kotlin version?That's not true lol.Its just the conversion tool. You should manually look at the code and make sure it came out correctly
Migrating a whole project from java to kotlin is not just using the conversion tool.There are things you need to consider. Like using kapt instead of java's annotation processor