t

gistfile1.txt

So now you know where Fragments are used, and where we’re going to use them in our app -- you’re probably starting to ask, why use Fragments at all? If we want to group UI components couldn’t we just use a Viewgroup or create a reusable XML layout definition?


Yes -- *but* the real power in Fragments goes beyond grouping UI elements - they allow us to fully modularize our Activities -- including [draw] the lifecycle events they receive and [draw] the app state they maintain.
Fragments were first introduced in Honeycomb to solve a particular problem. Honeycomb was the first Android release to support tablet -- and it turned out the best way for most apps to create a great tablet UI was to put two (or more) of their phone Activities alongside each other.
For example, if you had a phone app that started with a List Activity [Draw], which when you clicked an item would open a detail Activity [Draw] in what we refer to as the master-detail flow.
A good tablet UI would put them side-by-side [Draw] like this. Functionally, clicking an item on the list now replaces the “Activity” on the right rather than starting a new one as it would have on a phone.
Unfortunately, Android didn’t support embedding Activities within other Activities. Or at least it *didn’t* -- until we introduced Fragments.
If you just look at the UI elements, you could be excused for thinking you could achieve the same thing using an Activity, one that built the same UI using View Groups and layouts without bothering with Fragments, which is true. Up to a point. But you’d then have to pass through all the Activity lifecycle events, manage the state of each peice of the UI, keep track of the state of each portion as it changed, and remember which screen elements were on screen at any time to maintain app state.
All of which is exactly what the Fragment Manager does for you when you use Fragments -- allowing you to take a step back and treat each Fragment as though it were a mini-Activity.
For example, in the world of Activities, you start one Activity from another and the transaction is recorded on the back stack, hitting the “back” button, undoes the transaction and returns to the previous Activity.
The same thing happens with fragment transactions -- rather than starting a new Activity, we could replace the List Fragment with the Detail Fragment, with the back button switching them back.
So in theory, you could take all apps with multiple Activities and replace them with a single Activity with multiple Fragments.