I know that Activities are designed to represent a single screen of my application, while Fragments are designed to be reusable UI layouts with logic embedded inside of them.

Until not long ago, I developed an application as it said that they should be developed. I created an Activity to represent a screen of my application and used Fragments for ViewPager or Google Maps. I rarely created a ListFragment or other UI that can be reused several times.

Recently I stumbled on a project that contains only 2 Activities one is a SettingsActivity and other one is the MainActivity. The layout of the MainActivity is populated with many hidden full screen UI fragments and only one is shown. In the Acitivty logic there are many FragmentTransitions between the different screens of the application.

What I liked about this approach is that because the application uses an ActionBar, it stays intact and does not move with the screen switching animation, which is what happens with Activity switching. This give a more fluent feel to those screen transitions.

So I guess what I'm asking is to share your current development manner regarding this topic, I know it might look like an opinion based question at first look but I look at it as an Android design and architecture question... Not really an opinion based one.

UPDATE (01.05.2014): Following this presentation by Eric Burke from Square, (which I have to say is a great presentation with a lot of useful tools for android developers. And I am not related in any way to Square)

http://www.infoq.com/presentations/Android-Design/

From my personal experience over the past few months, I found that the best way to construct my applications is to create groups of fragments that come to represent a flow in the application and present all those fragments in one Activity. So basically you will have the same number of Activities in your application as the number of flows. That way the action bar stays intact on all the flow's screens, but is being recreated on changing a flow which makes a lot of sense. As Eric Burke states and as I have come to realize as well, the philosophy of using as few Activities as possible is not applicable for all situations because it creates a mess in what he calls the "God" activity.

251 upvote
  flag
For all who voted to close this question as opinion-based, it's not really true... It's a Android design and architecture question... Not really an opinion based one. – Emil Adz
upvote
  flag
I like the question. – user1914692
9 upvote
  flag
Agreed. True; there are many right ways to answer this question, but, as can be seen in many ridiculous answers to questions, just because something will "work" does not make it a desirable solution. This is not a matter of opinion. We are looking for the best right answer, or at least one that is roughly equivalent to the other "best" solutions. – brainmurphy1
1 upvote
  flag
Agreed. This is not subjective or "primarily opinion-based"... We can all come to say that this is a practical, answerable question based on actual and genuine problems that the OP faced. – Rohit Tigga
1 upvote
  flag
I find it really strange that this question gets so much interest from the SO community and yet it had not been opened. So that Google developers (that do answers on questions here) and other developers could provide their incites and their development methodologies on this topic. – Emil Adz
upvote
  flag
Voted to reopen - if answers can be objective. As in ice cold (non-biased) pros and cons of either approaches. E.g. you can do this with activities but not with fragments and so on... – Gishu
2 upvote
  flag
Check out my post at SO - //allinonescript.com/questions/24647078/… – My God
upvote
  flag
I agree on your experience, per activity per flow or per activity per action bar. Besides, if there is no need to change page under one action bar, I would like to use activity without fragment inside. After all, fragment management is a little tricky. – peacepassion
upvote
  flag
thanks for the question! I benefited a lot and he really provided a lot of concrete proof for many of the design issues that are not really addressed anywhere – Odaym
3 upvote
  flag
Now, the only thing left for me to do, is to determine what a flow should be like and not be like. – Stephane
upvote
  flag
@StephaneEybert I think that here the creativity of the developer and the design team comes in play... I don't think there is right or wrong here as long as it user friendly and understandable. – Emil Adz
upvote
  flag
@EmilAdz To give us an example, would user management including crud, profile editing and email validation constitute a flow, or would email validation be one flow and profile editing another one ? – Stephane
2 upvote
  flag
@StephaneEybert, I think this depends on the design of the application. usually all those configurations would be part of the settings screen flow. So in this case all those options come under the same flow (activity) with different fragments that are swapped in order to progress the flow. In case those options are part of the navigation drawer. maybe each of those options should be a separate flow. – Emil Adz
2 upvote
  flag
@EmilAdz I'll take this home: 1- a flow can represent several related user stories 2- a navigation drawer entry should lead to a flow – Stephane
1 upvote
  flag
@StephaneEybert, at least that's how I see it when I develop applications :) – Emil Adz
upvote
  flag

14 Answers 11

Well, according to Google's lectures (maybe here, I don't remember) , you should consider using Fragments whenever it's possible, as it makes your code easier to maintain and control.

However, I think that on some cases it can get too complex, as the activity that hosts the fragments need to navigate/communicate between them.

I think you should decide by yourself what's best for you. It's usually not that hard to convert an activity to a fragment and vice versa.

I've created a post about this dillema here, if you wish to read some further.

3 upvote
  flag
Thanks for you answer and sharing you experience So you think it's a good practice in android to limit application to one Activity and use Fragment for all screen if the application architecture permits it? – Emil Adz
upvote
  flag
It depends on the project, but if it gets too complicated to you, you can separate to multiple activities too. Don't be afraid to use any of the methods. You could also use them both. Maybe sometimes it would be too hard for you to use fragments instead of activities. I think you should try to use fragments, but don't force it to be everywhere if it gets too much in your way... – android developer
upvote
  flag
what if I want to keep this affect of the ActionBar staying intact and all the content is being switched? Is it possible to achieve this with Activities? – Emil Adz
upvote
  flag

My philosophy is this:

Create an Activity only if it's absolutely absolutely required. With the backstack made available for committing bunch of fragment transactions, I try to create as minimum of Activities in my app as possible. Also, communicating between various fragments is much easier rather than sending data back and forth between activities.

Activity transitions are expensive, right? At least I believe so - since the old activity as to be destroyed/paused/stopped, pushed onto the stack and then the new activity has to be created/started/resumed.

It's just my philosophy since fragments were introduced.

upvote
  flag
true, but as you've written, sometimes it is needed to use activities. one example is a camera screen, where it's better to use it in landscape mode. another example is the configuration screen that is shown when you put a customized appWidget (on the "desktop"- the launcher app). – android developer
upvote
  flag
Thanks for you answer and sharing you experience So you think it's a good practice in android to limit application to one Activity and use Fragment for all screen if the application architecture permits it? – Emil Adz
upvote
  flag
@EmilAdz Yeah. I think so. Limit your app to use as minimum activities as possible - architect it in such a way if possible. – VJ Vélan Solutions
upvote
  flag
Then how do you solve the issue of fragments needing to pass eachother "state"? All of the state across all of your fragments need to live in the one activity, otherwise you're forced to use a singleton. – Mr_E
4 upvote
  flag
I'm not convinced that communicating between various fragments is much easier rather than sending data back and forth between activities. – Denny

Experts will tell you: "When I see the UI, I will know whether to use an Activity or a Fragment". In the beginning this will not have any sense, but in time, you will actually be able to tell if you need Fragment or not.

There is a good practice I found very helpful for me. It occurred to me while I was trying to explain something to my daughter.

Namely, imagine a box which represents a screen. Can you load another screen in this box? If you use a new box, will you have to copy multiple items from the 1st box? If the answer is Yes, then you should use Fragments, because the root Activity can hold all duplicated elements to save you time in creating them, and you can simply replace parts of the box.

But don't forget that you always need a box container (Activity) or your parts will be dispersed. So one box with parts inside.

Take care not to misuse the box. Android UX experts advise (you can find them on YouTube) when we should explicitly load another Activity, instead to use a Fragment (like when we deal with the Navigation Drawer which has categories). Once you feel comfortable with Fragments, you can watch all their videos. Even more they are mandatory material.

Can you right now look at your UI and figure out if you need an Activity or a Fragment? Did you get a new perspective? I think you did.

4 upvote
  flag
do you have a link to the youtube feed you mentioned? I search for "Android UX experts" and "Android UX" but am not entirely sure which videos you're talking about. – me--
2 upvote
  flag
Not any more, watched it over a year ago. Search for Android developer official talking about UX – sandalone
1 upvote
  flag
One example of consideration: activity has parentActivity so we can synthesize backstack while entering from notification, but I don't think there's such parentFragment. – BornToCode

Don't forget that an activity is application's block/component which can be shared and started through Intent! So each activity in your application should solve only one kind of task. If you have only one task in your application then I think you need only one activity and many fragments if needed. Of course you can reuse fragments in future activities which solve another tasks. This approach will be clear and logical separation of tasks. And you no need to maintain one activity with different intent filter parameters for different sets of fragments. You define tasks at the design stage of the development process based on requirements.

There's more to this than you realize, you have to remember than an activity that is launched does not implicitly destroy the calling activity. Sure, you can set it up such that your user clicks a button to go to a page, you start that page's activity and destroy the current one. This causes a lot of overhead. The best guide I can give you is:

** Start a new activity only if it makes sense to have the main activity and this one open at the same time (think of multiple windows).

A great example of when it makes sense to have multiple activities is Google Drive. The main activity provides a file explorer. When a file is opened, a new activity is launched to view that file. You can press the recent apps button which will allow you to go back to the browser without closing the opened document, then perhaps even open another document in parallel to the first.

upvote
  flag
Re "Start a new activity only if it makes sense to have the main activity and this one open at the same time (think of multiple windows)." I don't think so. That situation is well solved using fragments attach/detach methods. – ToolmakerSteve

Thing I did: Using less fragment when possible. Unfortunately, it's possible in almost case. So, I end up with a lot of fragments and a little of activities. Some drawbacks I've realized:

  • ActionBar & Menu: When 2 fragment has different title, menu, that
    will hard to handle. Ex: when adding new fragment, you can change action bar title, but when pop it from backstack there is no way to restore the old title. You may need an Toolbar in every fragment for this case, but let believe me, that will spend you more time.
  • When we need startForResult, activity has but fragment hasn't.
  • Don't have transition animation by default

My solution for this is using an Activity to wrap a fragment inside. So we have separate action bar, menu, startActivityForResult, animation,...

1 upvote
  flag
Very useful points, thanks. Can you clarify "an Activity to wrap a fragment"? Did you make a separate Activity for each fragment? If so, do you need Fragment at all? – ToolmakerSteve
1 upvote
  flag
there is a way to restore title and stuff. use getSupportFragmentManager().addOnBackStackChangedListener to add a listener. get current fragment in that listener and then set title and stuff. – babay

Why I prefer Fragment over Activity in ALL CASES.

  • Activity is expensive. In Fragment, views and property states are separated - whenever a fragment is in backstack, its views will be destroyed. So you can stack much more Fragments than Activity.

  • Backstack manipulation. With FragmentManager, it's easy to clear all the Fragments, insert more than on Fragments and etcs. But for Activity, it will be a nightmare to manipulate those stuff.

  • A much predictable lifecycle. As long as the host Activity is not recycled. the Fragments in the backstack will not be recycled. So it's possible to use FragmentManager::getFragments() to find specific Fragment (not encouraged).

In my opinion it's not really relevant. The key factor to consider is

  1. how often are you gonna reuse parts of the UI (menus for example),
  2. is the app also for tablets?

The main use of fragments is to build multipane activities, which makes it perfect for Tablet/Phone responsive apps.

I use Fragments for better user experience. For example if you have a Button and you want to run let's say a webservice when you click it, I attach a Fragment to the parent Activity.

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

In that way the user won't have to move in another activity.

And secondly I prefer Fragments because you can handle them easily during rotation.

The one big advantage of a fragment over activity is that , the code which is used for fragment can be used for different activities.so, it provides re-usability of code in application development.

2 upvote
  flag
How? COuld you provide some example please? – user3705478

use one activity per application to provide base for fragment use fragment for screen , fragments are lite weight as compared to activites fragments are reusable fragments are better suited for app which support both phone & tablet

It depends what you want to build really. For example the navigation drawer uses fragments. Tabs use fragments as well. Another good implementation,is where you have a listview. When you rotate the phone and click a row the activity is shown in the remaining half of the screen. Personally,I use fragments and fragment dialogs,as it is more professional. Plus they are handled easier in rotation.

You are free to use one of those.
Basically, you have to evaluate which is the best one to your app. Think about how you will manage the business flow and how to store/manage data preferences.

Think about, how Fragments store garbage data. When you implement the fragment, you have a activity root to fill with fragment(s). So, if your trying to implement a lot of activities with too much fragments, you have to consider performance on your app, coz you're manipulating (coarsely speaks) two context lifecycle, remember the complexity.

Remember: should I use fragments? Why shouldn't I?

regards.

I think using fragments is better than using activities, but it's hard to manage the back stack button using frament

upvote
  flag
Dont guess what's better. If you know it though please explain yourself why you think what is better than the other. – L. Guthardt
upvote
  flag
Sorry, i find fragments better, because they're easy to manage and binding data between different pages, but my problem with them that the fragments can manage the backstack like activities does. – ayoub boumzebra
upvote
  flag
Then go ahead and put your reasons why you prefer fragments over activities in your answer. That's what people want to know and what answers are for. ;-) – L. Guthardt

Not the answer you're looking for? Browse other questions tagged or ask your own question.