Some of what is in this article isn't correct:

> Because fragments create, bind, and configure views, they contain a lot of view-related code. This effectively means that business logic isn't decoupled from view code — making it hard to write unit tests against fragments.

Put the business logic somewhere else. You CAN'T put it in Fragment objects, except in trivial cases, for other reasons, like you'll have different Fragments for different layouts for different screens, and different combinations of Fragments. Assuming you have a REST-backed app architecture, you can put business logic in front of your REST calls or, if data is sync'ed locally, in the ContentProvider or in a bound service wrapping the ContentProvider.

I have seen other big companies build big teams that over-engineer Android apps. I think that's what happened at Square.

I've just started learning about Android. This article is really disheartening. The Google course on Android Development (on Udacity) pushes Fragments from the very beginning.

Compared to learning how to program for the web, Android seems like a complete mess--the exact opposite of simple and easy to understand. Android seems to have lots of abstractions, and the introductory course just seems to throw one method after another at students, without explaining why those methods need to be called.

After spending some time to understand the reason Fragments exist, its sort of upsetting to learn that developers think they are a waste of time and a source of bugs.

You will always find some developers who disagree with the status quo - don't let it turn you off.

Fragments have their place. They're not a silver bullet, and they're by no means perfect, but they do a job adequately. Some people will struggle more with fragments, it depends on what you're trying to achieve really.

Fragments are just the current 'Android way' of handling this type of scenario. It doesn't mean you have to do it that way, or that there's no other way to do it. It's just a convention and one which you're free to use or lose as you see fit :) The fact that fragments exist at all is at least some kind of help - imagine how shitty support for different form factors would be without them.

As for my own experience, I don't particularly LOVE working with Android UI, but it's not like it's the worst thing in the world. It's bearable.

Basically I think the issue is that by its nature, Android UI is going to be difficult. The Android devs have to support a huge variety of form factors, and they have to make some effort to abstract all of that so that app developers don't have to worry so much about it. It's a fundamentally difficult thing to achieve - there's never going to be a 'one true way' that works for all scenarios.

If you have got an half competent designer, building an UI that works well from 3 to 10" screens is a bit more work than doing it once for a 4" screen, but I have never found it difficult.

The Android Team always chooses flexibility over simplicity. It means that almost everything is doable with the framework but at the cost of ease of learning.

I agree with Square on most of Fragment issues but I strongly disagree on their conclusions. 1- Fragment is hard to use at first, but it is not very manageable and not a source of hard to diagnose bugs if you use them well. 2- I don't see how introducing yet another framework to do the same thing but with less documentation and support is going to make things better.