7

Are Fragments and Fragment Activities inherently faster than Activities?

If I don't need to load my activity in fragments, should I be using FragmentActivities and Fragments over Activities?

Reason I am asking is because I have been using Activities, exclusively, for years, and the Facebook SDK as well as Google Maps 2.0 have forced me to use Fragments, and I wonder now if they are inherently "better" or not, versus some other implementation.

If this "not constructive" or "too open ended" then obviously the answer is "no". But if there are some Google developer documents or blog on this exact subject, then I would like to be aware of it

CQM
  • 42,592
  • 75
  • 224
  • 366
  • 2
    Fragments aren't there for speed. Quoting the documentation, "You can think of a fragment as a modular section of an activity, which has its own lifecycle, receives its own input events, and which you can add or remove while the activity is running (sort of like a "sub activity" that you can reuse in different activities)." http://developer.android.com/guide/components/fragments.html – CommonsWare May 08 '13 at 22:57
  • More than a comment, that's the answer ;) – Snicolas May 08 '13 at 23:35
  • @CommonsWare I just don't understand what problem they solve. Can you elaborate on that? – CQM May 08 '13 at 23:40
  • They are there to help developers support multiple screen sizes (e.g., phones, tablets) from a single code base, by subdividing the UI into pieces that can be recombined as needed based on available screen space. Please read http://developer.android.com/guide/practices/tablets-and-handsets.html#Fragments, http://developer.android.com/training/basics/fragments/index.html, and books by balding guys. – CommonsWare May 08 '13 at 23:48
  • Also, Maps V2 does not force you to use fragments. You can use a Maps V2 `MapView` if you wish, so long as you forward all the lifecycle methods to it, as is explained in the Maps V2 documentation: https://developers.google.com/maps/documentation/android/map#mapview – CommonsWare May 08 '13 at 23:50

3 Answers3

11

I became a believer in Fragments in my last application. Whether or not they are computationally faster, they feel faster because you can swap them in and out basically instantaneously, including full support for the back stack if you do it right (call addToBackStack() on the transaction, or something very similar).

I now use Fragments / Fragment activity for all navigation I want to feel very quick, like clicking on a row to get more details. I only launch new activities for when I want to do a fundamentally different thing and have a clean slate to work with. For instance, I usually have a LoginActivity that deals exclusively with logins/registrations, and at least one more that is the core of the app.

But the fundamental benefit of Fragments still remains their flexibility. I can show fragments on top of other fragments, re-arrange them on different screen sizes, etc. But there are loads of other benefits. It just takes a while to feel natural (just like Activities did at first).

One caveat, I always regret embedding fragments in my layouts. I can't give exact reasons here off the top of my head, but essentially you just lose some flexibility. Instead, I build a normal layout for each fragment, and add a placeholder view in the activity layout, create the fragment programmatically, and use transaction.replace() to add it to the layout. Perhaps because this is the main way I swap fragments in and out of that placeholder view, and prefer to just have a single way of doing things where possible.

Jay Bobzin
  • 1,020
  • 8
  • 14
  • Ah, another reason I don't embed fragments in layouts is I very often use Bundle arguments. (Caveat to those new to fragments, you want to use frag.setArguments(Bundle args); instead of a constructor, as when your Fragment gets rebuilt, it will be done by calling the default constructor and then passing the same args bundle. – Jay Bobzin May 09 '13 at 14:32
  • Are you still a believer in fragments? Im not and use conductor or some other kind of viewgroup to swap things in and out of one activity – CQM Aug 13 '17 at 16:08
1

yeah, fragments are introduced exclusively for supporting large screens to use the area efficiently.handling fragments is very easy and in terms of memory.but nested fragments makes trouble

GvSharma
  • 2,632
  • 1
  • 24
  • 30
0

Fragments are very useful if you want to split a screen. So you can have different views within the same screen. Another way of using fragments, lets say you've got tabs to categorise items. Could have clothes, shoes as your tabs. Each tab will have a fragment to hold the products. The tabs could either held in activity or a fragment. I do find fragments a slightly faster than activities but really its not something you would really notice in most cases. Regardless if they was intended for speed or not they still seem/feel little quicker.

The downside of using fragments, is certain callbacks like onBackPressed is only in an activity. Fragments has no access to this. I often find its best to minimise how much activities as possible. Also don't forget Activities aren't just views, they're also a screen. Whereas fragment is only a view and doesn't have a screen. tool/action bars etc. are also only for Activities however if your using a custom toolbar, you can use this in a fragment by implementing onTouch(if not button but some object) or onClick(buttons) the method for these will give you what you need. So really there are some drawbacks but there is almost a workaround for at least some of them.

I do agree Fragment transition is awesome and pop the stack when working with back buttons and onBackPressed Does the trick.

I always use a switch in parent activity etc. to see, which fragment needs to be in view, i often update it using interface passing bundle etc. Not sure if anyone else has found a more efficient way or not. But I do find it really useful when switching views.

Yep fragments are top brass for most things.

James Smith
  • 73
  • 10