Take the 2-minute tour ×

There are a lot of discussions about whether you should use Activities or Fragments. For example:

Most of the discussions I found were released before Android 4.2.
With Android 4.2 Google invented nested Fragments.

Therefore I actually don't see any reason anymore to use more than one Activity.

In the early stage of Fragments they were supposed to use within Apps for supporting Tablets and Smartphones in a comfortable way at the same time.

Thus for example you have a ListView which can open a detail View on click on an item. On a Smartphone we would replace the ListView and show the detailed View instead. Whereas a Tablet instead of replacing the List with the detail View can show both Views at the same time.

Now with nested Fragments there are a lot of other possibilities. In case you want to use a single Activity, you could store general information in the Activity and every Fragment would have access to it.

Besides this, Fragments who have nested Fragments, could also store information for their children Fragments.

With Fragments I can easily reuse the Views, I can show more than one Fragment at the same time and I can easly form a dialog out of a Fragment. This all would take me probably not more than just some copy & paste actions.

If I use Activities instead I seriously have to change a lot to get this done.

I recently implemented an Application where I easily could use two Fragment-ViewPager to get things really beautiful and dynamic (Some kind of: Today's Information - Yesterday's Information). In my opinion Fragments make our life a way easier :)


  • Why should I use more than one Activity?

Could you provide any good example in which the usage of multiple Activities makes more sense instead of using Fragments?

  • Are there any good examples where you don't have any choice but to use Activities?

I think most of the bigger frameworks like Maps, YouTube and co already support Fragments. So we don't have to rely on Activities. Also is it quite easy to deal with NavigationBar, TabHosts, ViewPager, ActionBar in case you use Fragments.

share|improve this question
I never thought of using only one Activity. Android architecture suggests that Application is made of Activities and Activity is made of Fragments, so I was stuck to this. Looking forward to some interesting answers. –  Gustek Nov 12 '13 at 11:18
Hey, I hope some experts will answer on this question :) Like I said, I just started to use Fragments instead of Activities and couldn't see any disadvantages yet. In the last week a customer said that he would like to have a Popup instead of an extra View. He was really suprised when I said him that I just have to change two lines of code :). –  Frame91 Nov 12 '13 at 11:26
You assume that nested fragments are implemented well. I have seen more than enough tweets and other comments, from experts and non-experts alike, to put nested fragments into the "in case of emergency" bucket. –  CommonsWare Nov 12 '13 at 12:24
But why should I seriously ever use more than one Activity? What for advantages do I get from this? I just see a big disadvantage: I can only use one Activity at the same time. Is there any performance issue with using only Fragments? And you can clearly implement Activities wrong aswell ;) –  Frame91 Nov 16 '13 at 16:33
my android-book proclaims the methodology "AUF!" --> Always use fragments! The authors mainly state the Pros that fragments save resources and that they make it easier to add changes late in the development of an app. –  bofredo Nov 19 '13 at 15:16

4 Answers 4

up vote 46 down vote accepted

First off, I will agree with you that it is possible to write a huge application using only one activity and nested fragments. That's the fun of software - you can achieve the same functionality using a variety of approaches. For me, the choice to use multiple activities comes down to my personal preferences for encapsulation, reusability, and testability.

If I have a widget that can be reused in other applications, I make it a Fragment. For example, my app features a "sync with server" button and I have created a custom Fragment that uses Progress Bars to visually show the synchronization process. It's easy to imagine another application being able to use this widget, so that's why I developed it as a Fragment.

If I am switching tasks within my app, such that the new task is conceptually independent of the previous task, then I use a new activity. For example, the first page of my app asks you to select a user. Once you've clicked on a user, I send you to the main menu for that user. This main menu for the user is displayed in a new activity.

Now let's imagine a large, complex app, and a team of developers assigned to develop that app. If the app can be divided into separate activities, it is conceptually very easy to divide up the tasks. Each activity is its own sandbox, so parallel development is simple and unit-testable. If there are any common needs, the team should still develop Fragments and reuse them, of course. I should add that code reuse does not happen often enough in software development, but if done right, there should be a lot of reusable Fragments.

Now suppose it is time to test the app. Your testing team can treat each activity as its own black box. This is easier to test than a single huge app that relies on a single activity and tons of nested fragments. This is especially important if a bug exists. If a bug exists that is not obvious, at least I know the scope of the bug is limited to a single activity out of many.

In summary, my guess is that you are developing your app as an individual, and therefore your development decisions do not affect anybody else. Your perspectives would likely change if you were developing an app with a larger team, and I hope my response makes a lot of sense in that light.

share|improve this answer
Thank you Steven! Really useful information :) –  Frame91 Nov 20 '13 at 1:02
Thanks. It's nice to be appreciated! –  Steven Nov 21 '13 at 0:51
I've given you the bounty because it would have been expired tmw... But I still like to hear some more advantages and disadvantages for fragments / activities ;) –  Frame91 Nov 25 '13 at 1:35
Here is the thing though, fragments load a lot quicker than launching new activities! –  mattblang May 15 at 18:39
It's my opinion that if one is having trouble testing fragments, they need to improve their testing framework or refactor their code. As I see it, the fragment is a memory store for data and handling the UI; the business logic, database access, and API calls should be in (easily testable) service classes. –  anthropic android Aug 29 at 2:39

You are right. One could do alot with fragments alone. However, according to the Activity class, an activity is a single, focused thing that the user can do. I always tend to compartmentalize my application into activities at the top level and furthermore into fragments.

For example, here is a situation where multiple activities make sense. Our applications has a certain functionality that can be extended if the user logs in. However, the user might still use this limited functionality before signing in. Say, you can not comment on items except when you are logged in. In this case, our MainActivity might show the whole functionality. If the user wants to comment, we ask him to login by saving his request and starting an activity LoginActivity that handles login/registration and sets the right result when he is done. In our calling Fragment or Activity, we check if the result is LOGIN_SUCCESS or if the user is currently logged in and serve the pending request. What I am trying to say is that the action flow of Login should be a separate activity. Otherwise, handling would probably be messed up. In this way, any action that requires login can call startActivityForResult(LOGIN) and saves itself as a pendingAction. Then the after setting the result we could implement the handling in the super.onActivityResult. This is all theoretical of course, one could implement Login in a fragment with no trouble. However, the code will definitely turn up to be FUed.

Another situation where you need an Activity is when your activity provides an exported Service. For example, say you are a developer of a "File Uploader" and you receive intents to upload files. It is very convenient in this case to create an Activity that can consume requests of uploading a file.

Yet, with the current updates, Fragments' functionality span most of the features of android apps and therefore can be used alone with a single host activity to fulfill the requirements of an app.

However, your whole "a single activity host" with data there is rather a weak defense. Activities and closely Fragments has the whole lifecycle that include the save/restore instance via bundles. A single host activity can be long lasting and host multiple fragments that might be recycled multiple times in a single lifetime of their activity. It is therefore highly probable that an activity holding all these instances over time to exceed its budget of resources. It is the responsibility of the developer to keep data in a shared context when they are really shared among multiple objects. This is a drawback of this approach. It does not make sense in our example for the MainActivity to consume an extra byte of data because it hosted the Login fragments when it could have slept and freed its memory if needed.

In the end, a good programmer can manage to do the same task likewise.

share|improve this answer
great example with the logging! But if we would use a fragment for this instead, we could easily implement a FragmentDialog for the login so the user doesn't have to switch the activity and can stay at the site where he needs further permissions. In my opinion this would provide a better workflow, even if it's like you said probably result in a totally messed up code (There are also ways to deal with this case without messing up the code. E.g. letting all fragments implement from an interface "UserPermissionInterface" with a method like login or logout which we could call out of the activity –  Frame91 Nov 20 '13 at 1:01
I'm curious, have you implemented a navigation drawer? And if so, how did you handle it across multiple activities so not to write a bunch of duplicate code? –  mattblang Mar 7 at 22:13
@mattblang Actually I never implemented a navigation drawer with activities: I find that weird. I see your point though. –  Sherif elKhatib Mar 10 at 7:45

You are totally right!

Why should I use more than one Activity?




Always using Fragments is not good for inflating the data to UI, especially in case

  • ConnectionTimeOut (or low internet) since it took much time to initialize the data. So, sometimes using each activity to inflate few data is better than each fragment.

  • Or for using method onActivityResult for more flexible, using activity is also better than. Ex. You can call FileDialogChooser in your application.

That is some cases,


share|improve this answer

For your questions i can only say that sometimes, with a complex User Experience or complex app that must use a different hardware component you need to use activity instead of fragment.

For example, if you have to create an app with some form that have a step that take a photo and then use this photo for some work hard memory task ( face detection for example ) that use memory you need to separate this task from the main task activity and personalise the permission on manifest to use more memory only on this activity.

Another example is if you want to use weak memory activity ( in manifest you can set properties that the clear the activity stack and force the Garbage Collector to clean memory when the activity finish )

The most probably situation that requires to use more activity and fragment is the User Experience of the app. If you need a right drawer custom that contains a menu and every fragment of the menu contains a listView and every list view must go in a detail. You can do a lot of trick to hide the right drawer and create animation to slide from fragment to the detail, but the best and simplest way is to make a new activity for the detail and manage it with a separate logic/lifecycle from the main activity with the drawer. I've done this choose in two of my apps:

iMeal - https://play.google.com/store/apps/details?id=it.fullsix.chiccopappe

GGRugby - https://play.google.com/store/apps/details?id=it.f6.template

In this app the Drawer is in the Main Fragment Activity, every menu change the content fragment. The list view in the content fragment change activity context with intent and go in another activity.

Finally there are some situation that i think you should work with more that one only fragmentActivity...but this a my pattern of work, probably you can find a trick/way or scope to do something with only an Activity and fragment.

share|improve this answer
Please clarify the meaning of "best". It could very well be the simplest way, but I am unable to find something (such as the memory consumption you talk about) that could justify that kind of list/detail separation in the applications you linked to. –  Giulio Piancastelli Nov 12 '13 at 12:15
The application i've listed is for the User Expreience case. The app that use a lot of memory are not on the store but installed on ad hoc hardware used for creation of some PhotoBox that i can't post here. Simply i think that an app that have some scope must have some activity that can be personalised on manifest with all the attribute that you can find here: developer.android.com/guide/topics/manifest/… –  phemt.latd Nov 12 '13 at 13:13

Your Answer


