Ask Big Nerd Ranch: Why do Fragments Matter in Android Application Development?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Q: Why does your book Android Programming heavily advocate the use of fragments when developing Android applications? You can develop Android applications without using any fragments, so why bother? Why do fragments matter?
A: As Android developers, we have two main controller classes available to us: Activities and Fragments.
Activities have been around for a very long time and are used to construct a single screen of your application. When someone is using your Android application, the views that the user sees and interacts with are hosted and controlled by a single activity. Much of your code lives in these Activity classes, and there will typically be one activity visible on the screen at a time.
As an example, a simple activity may look like the following:
public class MainActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
}
When Honeycomb was released, the Fragment class was introduced. Fragments are another type of controller class that allows us to separate components of our applications into reusable pieces. Fragments must be hosted by an activity and an activity can host one or more fragments at a time.
A simple fragment looks similar to an activity, but has different life cycle callback methods. The fragment below accomplishes the same thing as the activity example above: it sets up a view.
public class MainFragment extends Fragment {
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
return inflater.inflate(R.layout.fragment_main, container, false);
}
}
As you can see, activities and fragments look very similar and are both used to construct applications. So, what are the advantages that come with the use of Fragments?
Device Optimization
As I mentioned before, fragments were introduced with the Honeycomb release of Android. Honeycomb was the first version of Android with official support for tablets. One of the original goals of the fragment concept was to help developers make applications that provide different user experiences on phones and tablets.
The canonical example of fragment use is an email client. Let’s take a look at the Gmail app. When running on a phone, the Gmail app will display a list of the user’s emails. Tapping on one of these emails will transition the screen to showing the detail view for that particular email. This process is composed of two separate screens.
When using the same app on a tablet, the user will see both the email list and the detail view for a single email on the same screen. Obviously, we can show much more information at once with a tablet.
Fragments make implementing this functionality easy. The list of emails would exist in one fragment, and the detail view for an email would exist in another fragment. Depending on the device size, our activity will decide to show either one or both of these fragments.
The beauty of fragments here is that we do not have to modify either of these Fragment classes for this to happen. Fragments are reusable components of our application that can be presented to the user in any number of ways.
)
Figure 1 Fragments in use on a tablet
So, this is great, but what if you aren’t developing an app that works on phones and tablets? Should you still use fragments?
The answer is yes. Using fragments now will set you up nicely if you change your mind in the future. There is no significant reason not to start with fragments from the beginning, but refactoring existing code to use fragments can be error-prone and will take time. Fragments can also provide other nice features besides UI composition.
ViewPager
For example, implementing a ViewPager is very easy if you use fragments. If you’re not familiar with ViewPager, it’s a component that allows the user to swipe between views in your application. This component is used in many apps, including the Google Play Store app and the Gmail app. Swiping just swaps out the fragment that the user is seeing.
ViewPager hits at one of the core ideas behind fragments. Once your application-specific code lives in fragments, those fragments can be hosted in a variety of ways. The Fragment is not concerned with how it’s hosted; it just knows how to display a particular piece of your application. Our activity class that hosts fragments can display one of them, multiple Fragments, or use some component like a ViewPager that allows the user to modify how the fragment is displayed. The core pieces of code in your app do not have to change in order for you to support all of these different display types.
Other Features
So, Fragments can help us optimize our applications for different screen sizes and they help us provide interesting user experiences. There are other features that Fragments can help with as well.
You can think of Fragments as a better-designed version of an activity. The life cycle of a Fragment allows for something that Activities do not: Separation of the creation of the View component from the creation of the controller component itself.
This separation allows for the existence of retained fragments. As you know, on Android, rotating your device is considered a configuration change (there are a few other types of configuration changes as well). This configuration change triggers a reload of Activities and Fragments so that resources can be reloaded for that particular configuration. During the reload, these instances are completely destroyed and then recreated automatically. Android developers have to be conscious of this destruction because any instance variables that exist in your activity or fragment will be destroyed as well.
Retained fragments are not destroyed across rotation. The view component of the fragments will still be destroyed, but all other state remains. So, fragments allow for the reloading of resources across rotation without forcing the complete destruction of the instance. Of course, there are certain situations where this is and is not appropriate, but having the option to retain a fragment can be very useful. As an example, if you downloaded a large piece of data from a web server or fetched data from a database, a retained fragment will allow you to persist that data across rotation.
Additional Code
When you use fragments to construct your Android application, your project will contain more Java classes and slightly more code than if you did not use fragments at all. Some of this additional code will be used to add a fragment to an activity, which can be tricky if you don’t know how the system works.
Some Android developers, especially those who have been developing Android applications since before Honeycomb was released, opt to forego using Fragments. These developers will cite the added complexity when using Fragments and the fact that you have to write more code. As I mentioned before, the slight overhead that comes with fragment use is worth the effort.
Embracing Fragments
Fragments are a game changer for Android developers. There are a number of significant advantages that come with Fragment-based architectures of Android applications, including optimized experiences based on device size and well-structured, reusable code. Not all developers have embraced fragments, but now is the time. I highly recommend that Android developers make generous use of fragments in their applications.