Should I use Fragment or Activity in Android

This seems like a rather simple topic to talk about, however, in general, people seem to fall into one of two camps.

• Fragments are awesome and I use them blindly.
• Activity, because that’s all I need.

Indeed this is reflected in the code I see out there, not just professionally, but also in various open source libraries and their demo apps. Demo apps are a rather interesting barometer for these things. Mostly because when making a demo app, nothing really matters other than showing how the library or feature works. Yet, people go through the trouble of creating a Fragment or conversely, do not create a Fragment when there is a lot of code.

Some out there would point out that this may be because IDE’s now generate a lot of this code for you, so you can start with an empty project that the IDE sets up for you with a Fragment. That being said, those same IDE’s can also create blank projects without Fragments so it is largely the programmer’s choice what they want. That begs the question:

When should we use Fragments and when should we not?

If you read the “Design Philosophy” behind a Fragment, it certainly seems to imply that unless you want to create a bad app, you should be using a fragment. However, I’m pretty sure that’s not really how it’s meant to read. The best insights we have as to what Google recommends is firstly, by looking at Android code samples by Google. Do look at the date when you look at some of this example code. The reason for this is that Fragments were introduced in API 11 and there is a lot of code that was added before that or soon after that which may not use Fragments. The second area where we can get an idea of what Android best practices are, is by looking at some of the code templates generated code by the Android Studio IDE.

So, what are some of the insights? The first thing we see is that Activities are still alive and well and not just a zombie container for Fragments. Everyone knows that Fragments are supposed to communicate with each other through the Activity. We also see that a lot of logic for managing the menu items and the action bar is in the Activity. The reason for this is that having a central point to control those will save you a lot of headache later. We also see a lot of code for retrieving data and manipulating data before it is handed over to a Fragment. This may be a good idea if you have more than one Fragment which is supposed to display the same data.

We also see activities being used as a way to add logical flow to an application. Take a look at the Email app source for example. This is exceedingly important in large apps. If you try to do everything in one Activity with Fragments, you’ll find that there is a certain amount of code you have to add to everything for every Fragment you add after a certain point to keep things flowing smoothly. That reason for this is mostly that a lot of unrelated functionality is being bundled together. Adding and removing menu items, changing action bar titles and application flow when clicking back are among the first challenges to come up. In order to minimize the headaches, if the functionality is significantly different, it probably belongs in a different Activity (it can still be in it’s own Fragment, just added to a different Activity).

None of this changes the fact that Fragments are reusable and as such they are the best place for your UI and logic if there is any chance that you may have to use the same layout/logic elsewhere. The takeaway seems to be that you shouldn’t forsake putting code in an Activity for the heck of it, rather, consider using a Fragment if there is a chance that your code may be reused elsewhere in the app, otherwise it’s okay to put it in an Activity.

On a side note, if you leak an Activity, you can potentially leak all Fragments that hold a reference to it. When a Fragment is destroyed, make sure to clear references to all callbacks to the Activity and any objects references from the Activity.

Originally published at www.linkedin.com.