The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Fragments are an optional layer you can put between your activities and your widgets, designed to help you reconfigure your activities to support screens both large (e.g., tablets) and small (e.g., phones).
This chapter will cover basic uses of fragments.
In the world of journalism, the basics of any news story consist of six questions, the Five Ws and One H. Here, we will apply those six questions to help frame what we are talking about with respect to fragments.
Fragments are not activities, though they can be used by activities.
Fragments are not containers (i.e., subclasses of
ViewGroup), though typically
they create a
Rather, you should think of fragments as being units of UI reuse. You define a fragment, much like you might define an activity, with layouts and lifecycle methods and so on. However, you can then host that fragment in one or several activities, as needed.
Android does not precisely implement UI architectures like Model-View-Controller (MVC), Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), etc. To the extent that you wish to shove Android into the MVC architecture, fragments and activities combine to be the controller layer. Fragments serve as a local controller, focused on their set of widgets, populating them from model data, and handling their events. Activities will serve as more of an orchestration layer, handling cross-fragment communications (e.g., a click in Fragment A needs to cause a change in what is displayed in Fragment B).
Functionally, fragments are Java classes, extending from a base
As we will see, there are two versions of the
Fragment class, one native
to API Level 11 and one supplied by the Android Support package.
Since fragments are Java classes, your fragments will reside in one of your application’s Java packages. The simplest approach is to put them in the same Java package that you used for your project overall and where your activities reside, though you can refactor your UI logic into other packages if needed.
Typically, you create fragment implementations yourself, then tell Android when to use them. Some third-party Android library projects may ship fragment implementations that you can reuse, if you so choose.
Some developers start adding fragments from close to the outset of application development — that is the approach we will take in the tutorials. And, if you are starting a new application from scratch, defining fragments early on is probably a good idea. That being said, it is entirely possible to “retrofit” an existing Android application to use fragments, though this may be a lot of work. And, it is entirely possible to create Android applications without fragments at all.
Fragments were introduced with Android 3.0 (API Level 11, a.k.a., Honeycomb).
Ah, this is the big question. If we have managed to make it this far through the book without fragments, and we do not necessarily need fragments to create Android applications, what is the point? Why would we bother?
The primary rationale for fragments was to make it easier to support multiple screen sizes.
Android started out supporting phones. Phones may vary in size, from tiny ones with less than 3” diagonal screen size (e.g., Sony Ericsson X10 mini), to monsters that are over 5” (e.g., Samsung Galaxy Note). However, those variations in screen size pale in comparison to the differences between phones and tablets, or phones and TVs.
Some applications will simply expand to fill larger screen sizes. Many games will take this approach, simply providing the user with bigger interactive elements, bigger game boards, etc. Any one of the ever-popular Angry Birds game series, when played on an tablet, gives you bigger birds and bigger pigs, not a phone-sized game area surrounded by ad banners.
However, another design approach is to consider a tablet screen to really be a collection of phone screens, side by side.
Figure 252: Tablets vs. Handsets (image courtesy of Android Open Source Project)
The user can access all of that functionality at once on a tablet, whereas they would have to flip back and forth between separate screens on a phone.
For applications that can fit this design pattern, fragments allow you to support phones and tablets from one code base. The fragments can be used by individual activities on a phone, or they can be stitched together by a single activity for a tablet.
Details on using fragments to support large screen sizes is a topic for a later chapter in this book. This chapter is focused on the basic mechanics of setting up and using fragments.
Well, answering that question is what the rest of this chapter is for, plus coverage of more advanced uses of fragments elsewhere in this book.
Most developers will use the implementation of fragments that has been part
of Android since API Level 11. You will use
android.app.Fragment and have them
be hosted by your regular activities.
However, there is a backport of the fragment system available in the Android
Support package. This works back to API Level 4, so if your
lower than 11 and you want to use fragments, the backport is something that
you will wish to consider. You will need to add the
support-v4 JAR to your
project (e.g., via
compile 'com.android.support:support-v4:...' in your
build.gradle, for some value of
You will also need to use
android.support.v4.app.Fragment instead of
android.app.Fragment. Also, you will
need to host those fragments in an activity inheriting from
android.support.v4.app.FragmentActivity (as the regular
base class does not know about fragments prior to API Level 11).
This book focuses mostly on using the native API Level 11 implementation of fragments, with the occasional example of using the backport where the backport is necessary for one reason or another.
The preview of this section left for Hollywood to appear in a reality TV show.
The preview of this section is in the process of being translated from its native Klingon.
The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.
The preview of this section was eaten by a grue.
The preview of this section apparently resembled a Pokémon.
The preview of this section is off trying to sweet-talk the Khaleesi into providing us with a dragon.