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 Activity
logic there are many FragmentTransitions
between the different screens of the application.
What I like 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.
January 5, 2021. According to the Android documentation, a fragment is a part of applications user interface that is bound to an activity. Fragments have their lifecycle and layouts or UI components. Fragments help enrich your UI design, pass data between different screens, and adapt to different device configurations.
Fragments allow such designs without the need for you to manage complex changes to the view hierarchy. By dividing the layout of an activity into fragments, you become able to modify the activity's appearance at runtime and preserve those changes in a back stack that's managed by the activity.
Fragment can't be initiated without Activity or FragmentActivity.
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.
My philosophy is this:
Create an activity only if it's absolutely absolutely required. With the back stack made available for committing bunch of fragment transactions, I try to create as few activities in my app as possible. Also, communicating between various fragments is much easier than sending data back and forth between activities.
Activity transitions are expensive, right? At least I believe so - since the old activity has 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With