Develop Reference

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

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

I am working on a huge Android project and the team has decided to phase out Data Binding library. Why? The primary reason is that it is exacerbating build time(10+ mins), by generating a lot of classes in the build process.

Even if i like danypata's answer i would like to add/edit some of his statements to android databinding.
1.Remove boilerplate code - As written in danypatas answer it removes some code and adds some code somewhere else like in layouts. That doesnt mean that the boilercode isnt reduced because usually it is reduced.
For example you may want to create a bindingadapter, which handles several custom arrayadapters for your spinner/recyclerview/listview/.. but requires only one simple adapter. You may want to use the adapter in your layout by using e.g.
app:myCoolAdaptersData="#{model.mydata}"
Now you can create your generic adapter and (re)use your bindingadapter in all your layouts instead of using for example:
ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);
This is just one simple example which recudes the code alot in larger projects. Another sample to recude code is, that you bind your model to your layout. Updating field-values of your model usually updates your model aswell (if its at least a BaseObservable/ObservableField).
That means that you dont need to find all your views, update your views, update your models, ...
2.Stronger readability - The extra time spent for learning databinding doesnt really matter. Since the layouts are not really different except that you wrap them into a layout tag and put your namespaces there, it doesnt really differs from "regular" layouts. Using bindingadapters and accessing the model in the layout may take some time, but usually you can start beginning with the basics which are easy and beautiful to use aswell. Learning new stuff always takes time, but you will easy overhaul the time when using databinding after a while.
3.Powerful - Yes, its very powerful. Its easier to reuse existing code, reuse existing bindingadapters and may lead to more generated code but thats not always true. For example you may create multiple adapters within several classes instead of creating one bindingadapter, it may be hard to "optimize" it later. Optimizing the Bindingadapter means that it gets updated everywhere. Optimizing may decrease the "lines of code" since the boilerplace is reduced anyway.
I agree to 4. and 5.
6. Hard to Debug Since AS 3.0+ outputs useful hints like syntax issues in your layout (line number and file) its easy to debug databinding generated code. If you have problems finding the issue you may also want to check for errors in the generated code. Some librarys like dagger 2 or android architecture library may confuse you because the error lines doesnt match with the real "error". This is due generated code by other annotation processors. If you know that those annotation processors may get in trouble with databindings error outputs, you can easy fix that.
7. Unit Testing Its possible like if you dont use databinding by using executePendingBindings.
8. Readability Readability may be better without databinding. Since you put some business logic into your layout, some into your real code, it may lead to spaghetti-code. Another problem is that using lambdas in your layout may be very confused if the "layout-designer" doesnt know which param may be used.
Another very big problem is that bindingadapter can be everywhere. Using BindingAdapter annotation generates the code. That means that using this in your layout may lead to problems to find the proper code. If you want to update a bindingadapter you need to "find" it.
When should you use what? For larger projects it is a really good idea to use databinding together with the mvvm or mvp pattern. This is a really clean solution and very easy to extend. If you just want to create a small simple application you'r fine using MVC Pattern without databinding. If you have existing generic bindingadapters which can be used from other projects you may want to use databinding, because its easy to reuse this code.

Data binding, concept wise looks promising to me, but I do not like the implementation part.
I would appreciate a bit more simpler and direct approach to it.
Thus I feel lot more comfortable in keeping it old school.
Model classes, mutable objects, observers feel like too much to me, if some how the data variables used for binding are received as Objects that are mutable and observable directly in a class , then that would make the process lot more cleaner, simpler and concise.

Code Audit for Android/iOS

I have just been given a task at work to help audit a code base for a mobile app. I am not a mobile app programmer, although I've been a software developer for many years now, but know nothing about mobile apps. I was wondering if there's any tips or tools that I can use for this code audit.
I have seen the replies to this older post for a Java EE application, which can't be applied to my case since they're mostly based on having maven to build the app and in my case they use Gradle. Also these replies are from 2011 and perhaps there are more recent ones I'd really be very grateful to hear about.

In itself, the fact of appointing someone with no experience in the target environment seems like a complete nonsense to me, so I'd question the management here.
I do hope for you that you know at very least the languages these apps are written in: probably Java for Android & Objective-C for iOS (your question didn't mention what technologies your past experience concerned). If not, you're bound to just make remarks about comments, file size, and maybe some about naming conventions, which is of little interest compared to a real audit.
Beyond programming languages, iOS and Android are designed in very different ways, with different conventions & patterns. I actually know very few people who are really good in both environments, and there's a reason for this: these are different worlds, each of which you can easily spend your whole time on to learn APIs, common libraries, design philosophy, work-arounds for common issues, and understand a bit of how the internals work.
I don't know how much time you have to perform this task, but I'd suggest you learn how to code a basic app on the target environment, and learn about the key components.
My approach is generally:
gather some context from the team
get the source
build the app & get a taste of what it's doing (I usually hand-draw a screen flow diagram at this stage, it's useful later when you navigate in the code), also take note of bugs, slow features, non-user-friendly stuff (feedback is important to the team)
go to the source code, examine it's macroscopic layout:
. look at the build scripts to see what external libs it's using
. take note of the general package hierarchy, check that the naming is consistent, that packages are not overloaded with junk
. look generally at the class naming: is it consistent? do class names help figure out what's actually inside
. do some basic stats about file sizes: it's something that can quickly indicate some design flaws
now about the code in itself:
. read it until satisfied that you understand the general way it works (drawing a technical flow diagram helps), I like to start by the app entry-point (generally an activity in Android)
. make sure you spot how what you read achieves what you saw while testing the app
. take note of bad coding habits you spot while reading (naming, comments, it can be anything: there's no limit to how bad the code can be ^^)
. take note of unreadable/overly-complex bits of code (but don't spend days just to understand them)
. if you had noticed slow features in the app, it might be worth looking at those bits of code a little more carefully
. have a good night sleep, then re-read all your notes, and try to extract some high-level remarks about the application design
Now, specifically for Android, here the most common list of things to look for, based on my experience:
components life-cycle handling issues (for components like activities, services, fragments and such): symptoms include device rotation and application switches causing issues
thread handling issues (things done on the UI thread, when they should really run in background)
massive activities / services (many people think that creating activities / fragments / services is all that's required in terms of architecture - it is true only for very simple apps)
I won't enter more into the specifics, because people a lot more intelligent than me wrote books about this. And you have to code apps to really get a grasp of those subjects: a lot of them, so that's what you should start with: code apps yourself, otherwise: 1/ your audit will be irrelevant 2/ the team will spot your lack of skills pretty fast - depending on the aim of this audit, you might have a very hard time facing them...

The library approach to release a free and paid version

I am going to release multiple versions of an app to the Android market / Google Play Store. Now I am looking into the best way to do this.
I've read a lot of questions here about how this is achieved in the easiest way.
I do not want to create application version specific activities, because this could easily lead to code inconsistencies between the different versions. So I want to use the library approach. This also seems to be the easiest way, instead of all the examples I've seen which require hefty amounts of ANT scripting etc
For argument's sake I am going to have:
com.app.library
com.app.free
com.app.paid
com.app.paidmore
My idea is to base code in the library on the package name.
Parts of my activities would not show, or disable functionality based only on package name.
What are the downsides to this approach? I can't seem to find any, but I am curious about the opinions. Ofcourse all application versions would in a sense contain all functionality, but the functionality is disabled on the fly by code. I think it would be a lot of work to modify the code to hack the app to obtain full functionality, but am I right?
This approach seems wrong, in that it would be very easy to modify the apk and distribute it in the modified way.

What are the downsides to this approach?
Your app winds up bigger than it needs to be (e.g., paid functionality residing on a free user's device). And, as you note, it puts all the functionality on the user's device.
I think it would be a lot of work to modify the code to hack the app to obtain full functionality, but am I right?
If it takes more than five minutes, the script kiddie is typing too slow. Decompile, search-and-replace your package name, recompile.
This approach seems wrong, in that it would be very easy to modify the apk and distribute it in the modified way.
That approach actually might take more time -- to perhaps ten whole minutes -- as it may take longer for the script kiddie to figure out exactly what resource needs changing.
Of course, the script kiddies can just grab your paidmore version and attack that, so the fact that your free and paid apps happen to have paidmore functionality is not much of a problem. So, the biggest difference IMHO is APK size, and only you'll know how much that differs between the versions and whether or not it's a problem.

Android .designer.cs equivalent?

I've just coded android for a few months, and I really enjoy it, but I find myself writing the same "(TextView)findViewById(R.id.mytextview)" code over and over again.
Coming from asp.net I can't help but wonder why there's no auto-generated class from which I can access my xml-declared views(controls) strongly typed?
Actually I kind of solved it for myself by creating a "viewshelper"-class for complex activities, so I can do "_views.mytextview" when I need the textview, but I still have to maintain these classes by hand each time I add or remove views.
Am I missing something, or should the android sdk do this for me?

Take a look onto roboguice, it looks like the library takes care about the problem.

IMHO, You are missing the Java approach for application development.
This is quite normal for those that use Eclipse (with out plugins) at the beginning this seam to be very problematic, but now i think that that show only the developer limitation.

How do you release two versions of an app on the Market?

I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.

This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/

People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.