
Advocating Against Android Fragments - yla92
http://corner.squareup.com/2014/10/advocating-against-android-fragments.html
======
Zigurd
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.

------
TheMagicHorsey
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.

~~~
powatom
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.

~~~
on_and_off
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.

