Although Fragments have been part of the Android API for nearly three years, I find that developers still often struggle to understand their value and purpose.
A common explanation of Fragments, and one I sometimes even use myself, is:
Fragments group user interface components and their associated logic.
That explanation is accurate. However, if someone is struggling with how to apply Fragments in a practical sense, that explanation is about as useful as teaching someone how to tell time by explaining the finer details of Swiss watch construction … sometimes you just want to know what time it is.
So in the spirit of just wanting to know what time it is, here are four places where Fragments prove useful.
1. Dealing with device form-factor differences
The Activity class is often thought of as the main UI class in Android. It is true that Activities do render the UI for an application but Activities also have a lot of other responsibilities such as lifecycle management, platform interaction, etc.
Putting all of this burden within the Activity class creates difficulties in dealing with device form factor differences. Ultimately one of two things happen.
A single Activity has to provide a lot of special case handling for various form factors
A separate Activity is created for each form factor with the non-UI details duplicated or otherwise shared across each Activity
Fragments eliminate this problem by taking on the UI details and leaving the other responsibilities to the Activity. This way a separate Fragment can be created for each form factor with the form factor specific UI details being theonly responsibilities of each Fragment. The Activity is then free to delegate the UI responsibility to the appropriate Fragment for the current form factor.
2. Passing information between app screens
Historically each screen in an Android app was implemented as a separate Activity. This creates a challenge in passing information between screens because the Android Intent mechanism does not allow passing a reference type (i.e. object) directly between Activities. Instead the object must be serialized or a globally accessible reference made available.
By making each screen a separate Fragment, this data passing headache is completely avoided. Fragments always exist within the context of a given Activity and can always access that Activity. By storing the information of interest within the Activity, the Fragment for each screen can simply access the object reference through the Activity.
3. User interface organization
Two of the most common UI metaphors for organizing application screens are Tabs and Dropdown Lists. Tabs are great when there are just a few screens and Dropdown Lists work well when there are several, as when selecting a folder from the Android email app as shown here.
Fragments make implementing these UI metaphors easy. In both cases you simply put the Android ActionBar into the appropriate navigation mode, implement the appropriate interface, and then use a FragmentTransaction to switch between the currently displayed Fragments.
Tabs use ActionBar.NAVIGATION_MODE_TABS and ActionBar.TabListener
Dropdown Lists use ActionBar.NAVIGATION_MODE_LIST and ActionBar.OnNavigationListener
4. Advanced UI metaphors
As the use of Fragments matures, they are an increasingly important part of rich UI design and are becoming the foundation of some of the more advanced UI metaphors. One of my favorites is swipe-based navigation where you move between screens in an application by drawing your finger from one side of the display to the next.
To add swipe navigation to an app, simply implement a Fragment for each screen, place a ViewPager in the UI layout and connect the ViewPager to a FragmentPagerAdapter.
Fragments are a powerful feature of the Android platform and like a Swiss watch have a lot of sophistication and complexity behind them. But just like that Swiss watch, you don’t have to understand all of that sophistication and complexity to begin taking advantage of them.