IMHO, Fragments didn't simplify my work or make it more manageable. Fragments mostly added new weird things to remember, and, for all that complication, I don't seem to reuse them all that much.
Fragments have their own lifecycle events which are like those of an Activity, but not exactly. They also interact with the Activity lifecycle in ways that I found a bit confusing, personally.
To get access to your Fragment instances, you're supposed to rely on the FragmentManager (and/or FragmentManagerCompat, depending on what minimum version of Android you support), which puts you at arm's length from them, making life a bit awkward. Fragments also exist in another flavor, from the compat library, so that sometimes results in mismatched types which can be confusing.
Then you have to get used to the idea that you're only supposed to create trivial constructors for your Fragments.
If a Fragment needs to know something interesting, you're supposed to pass parameters to it, not through a constructor, but, with setArguments. That way the system can resupply those arguments if it has to destroy and recreate your Fragment on your behalf in certain circumstances. This could be better documented, IMHO.
But wait, there's also a lifecycle callback named "onViewStateRestored" which supplies a savedInstanceState Bundle to your Fragment which it can use to bring itself back to the desired state. This is more like what Activities do, kind of. But it doesn't seem to interact usefully with Activity state restoration, which I found counterintuitive.
And when I think about how smart these Android SDK programmers are (and I have no doubt that they are super bright people), I wonder why this is what they came up with. It makes me feel dumb. And if your goal is to create a product your customers will love, maybe you should avoid making them feel dumb.
IMHO, Fragments didn't simplify my work or make it more manageable. Fragments mostly added new weird things to remember, and, for all that complication, I don't seem to reuse them all that much.
Fragments have their own lifecycle events which are like those of an Activity, but not exactly. They also interact with the Activity lifecycle in ways that I found a bit confusing, personally.
To get access to your Fragment instances, you're supposed to rely on the FragmentManager (and/or FragmentManagerCompat, depending on what minimum version of Android you support), which puts you at arm's length from them, making life a bit awkward. Fragments also exist in another flavor, from the compat library, so that sometimes results in mismatched types which can be confusing.
Then you have to get used to the idea that you're only supposed to create trivial constructors for your Fragments.
If a Fragment needs to know something interesting, you're supposed to pass parameters to it, not through a constructor, but, with setArguments. That way the system can resupply those arguments if it has to destroy and recreate your Fragment on your behalf in certain circumstances. This could be better documented, IMHO.
But wait, there's also a lifecycle callback named "onViewStateRestored" which supplies a savedInstanceState Bundle to your Fragment which it can use to bring itself back to the desired state. This is more like what Activities do, kind of. But it doesn't seem to interact usefully with Activity state restoration, which I found counterintuitive.
And when I think about how smart these Android SDK programmers are (and I have no doubt that they are super bright people), I wonder why this is what they came up with. It makes me feel dumb. And if your goal is to create a product your customers will love, maybe you should avoid making them feel dumb.
</rant>