Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the pros and cons of android data-binding?

Both of my colleague and I have experience in MVVM of Web App, while we are new to native android development. Now we have contrary opinions about android data-binding -- I'm a fan of it while he is not.

My Arguments:

  • Reduces boilerplate code which in turns brings
    • Less coupling
    • Stronger readability
  • Powerful, easy to implement custom attribute and custom view
  • Even faster than findViewById (details)

His Arguments:

  • The auto-generated .class increases app size.
  • Harder to debug

I've made some investigation but there are not many discussions about it. Now I want to collect the pros and cons of android data-binding.

Aspects of discussion include but are not limited to:

  • unit test
  • app size
  • performance
  • learning curve
  • readability
  • coupling
like image 803
lzl124631x Avatar asked Jan 04 '17 11:01

lzl124631x


People also ask

What is the advantage of data binding in Android?

Using data binding can lead to faster development times, faster execution times and more readable and maintained code. Android data binding generates binding classes at compile time for layouts.

Which is better view binding or data binding in Android?

View binding and data binding both generate binding classes that you can use to reference views directly. However, view binding is intended to handle simpler use cases and provides the following benefits over data binding: Faster compilation: View binding requires no annotation processing, so compile times are faster.

Should I use DataBinding or ViewBinding?

In short you can use ViewBinding to replace findviewbyid() effectively. If your project is however more complex and you need to add features like binding data to views, binding adapters e.t.c, use DataBinding.

Is data binding deprecated Android?

Kotlin Android Extensions is deprecated, which means that using Kotlin synthetics for view binding is no longer supported.


1 Answers

I will comment on your arguments first then I will state my opinion:

1.Remove boilerplate code - it will remove some it will just move some in the xml or it will require additional classes. So you have to be careful and balance the use of data binding.

2.Stronger readability - depends if you are a new developer then you may find it easy to learn it but if you previously worked on android you will need extra time to learn it.

3.Powerful - the code has more power, you can implement whatever you like in code. Think about it like this, everything you implement using data binding has a code equivalent (it might be longer and more code to write), but the revers is not valid.

4.Even faster than findViewById - comparing the speed between these two, in my opinion is useless, you will never notice the difference, if you see some difference, then one of the implementation is wrong.

5.Auto generated class - it's true it will increase the app size, but again only if you have tons of it it will matter. It's true that on the android dev web site they state that it's kind of bad to use libraries that create autogenerated code or annotations that will generate extra code.

6.Hard to debug - depends, like readability, of what you are used to, heck debugging is hard either way for some problems, and you will get better by debugging not by using a different library.

So this is pure my opinion, I've developed many apps using different libraries and different approaches, and they all had pros and cons, but what I've learn: balance everything, don't use tons of libraries, don't waste time implementing things that are implemented already and work well, don't "decouple everything", don't "couple" everything, don't use code only, don't try to "generate" everything.

I think it's quite wrong, and you can get a wrong idea, if you ask for 'pros & cons' about some library/implementation, because usually it won't be impartial, you will get a lot of pros from somebody who used the library in a specific way and it worked and others will give you cons because they used different and it didn't work.

So in conclusion, I think you should check what the library can do for you and what can't do for you and decide if it's good for your setup. In other words, you should decide if a library is good for you not other people ;).

Update - 8 August 2018

First of all I still stand with my initial conclusion, balance is the key in these kind of situations, but in my case, data-binding speed-up a little bit the development process and also improved it. Here are a few new points that you should all think about.

  1. Testing the UI -- with data-binding it's much more easy to test the UI, but data-binding it's not enough for that, you also need a good architecture and using the Google suggested architecture will show the actual power of data-binding.

  2. The most visible changes were provided for points 2 & 5 from my original answer. It kind of was easier to read the code after we decided to use data-binding, and the most important thing here is: we as a team decided that we will use data-binding and after that, we kind of expected to have most of the trivial and basic UI setup in the XML file.

For the debugging part, here's a little bit tricky, Android Studio has a lot to improve on the errors and autocomplete for the data-binding but the most common errors you'll get them after the first 2-3 occurrences. Also I've learned that a "clean project" form time to time, helps A LOT.

  1. Another point that you'll have to take in consideration is the project configuration to use data-binding, right now AS (3.1) supports by default data-binding (just set a flag in graddle) for Java, but I had some issues with Kotlin, after a bit of search here on SO, I managed to fix everything.

As a second conclusion (from my original post), if you can and the project deadline/requirements/etc allows you to try data-binding, go for it it will worth (unless you do some really stupid stuff :)) ).

like image 97
danypata Avatar answered Oct 04 '22 01:10

danypata