Why use Android Fragments?

Question

I have read the documentation and some other questions' threads about this topic and I don't really feel convinced; I don't see clearly the limits of use of this technique.

Fragments are now seen as a Best Practice; every Activity should be basically a support for one or more Fragments and not call a layout directly.

Fragments are created in order to:

allow the Activity to use many fragments, to change between them, to reuse these units... ==> the Fragment is totally dependent to the Context of an activity , so if I need something generic that I can reuse and handle in many Activities, I can create my own custom layouts or Views ... I will not care about this additional Complexity Developing Layer that fragments would add.
a better handling to different resolution ==> OK for tablets/phones in case of long process that we can show two (or more) fragments in the same Activity in Tablets, and one by one in phones. But why would I use fragments always ?
handling callbacks to navigate between Fragments (i.e: if the user is Logged-in I show a fragment else I show another fragment). ===> Just try to see how many bugs facebook SDK Log-in have because of this, to understand that it is really (?) ...
considering that an Android Application is based on Activities... Adding another life cycles in the Activity would be better to design an Application... I mean the modules, the scenarios, the data management and the connectivity would be better designed, in that way. ===> This is an answer of someone who's used to see the Android SDK and Android Framework with a Fragments vision. I don't think it's wrong, but I am not sure it will give good results... And it is really abstract...

====> Why would I complicate my life, coding more, in using them always? else, why is it a best practice if it's just a tool for some cases? what are these cases?

It is unclear what you are asking, could you please summarize the question, maybe below the enumeration of supposed advantages and your criticism of each? — logc, Jun 12 '14 at 10:58
I'm lost like @logc. How would you handle these cases without Fragments? — neontapir, Jun 13 '14 at 05:21
I gave what I would do without Fragments : (1) creating custom generic controls and reuse them where i want (2) using 2 Activities and navigate with startActivityForResult, or simply changing between views (showing/hiding , inflating/removing ...) without coding so much ... (3) you can use a callback even in Activities with views (4) It's an abstract answer that I always get when I discuss this topic... which needs more explication... — ahmed_khan_89, Jun 13 '14 at 08:08
Hmm. This Q&A shows the limitation of stackexchange's design where the original poster picks the "best" answer. (As opposed to slant.co, where everyone votes.) Not ideal for a broad question like this. Here, a vague question gets an accepted answer that obviously agrees with what the asker wanted to hear. If you see no reason to use *fragment* in your situation, then don't. A better question would be to ask for pros/cons of *fragment* vs *activity*. And there are many threads on that exact topic. — ToolmakerSteve, Sep 20 '16 at 17:11
Yes I agree,I asked this question a bit more than two years ago. I have seen many upvotes at some point so I posted another answer... There's no real "correct" answer... it's more a matter of choice, opinion, discusysion... — ahmed_khan_89, Sep 21 '16 at 07:44

score 5 · Accepted Answer · edited Jul 07 '14 at 20:27

Fragment is a modular section of an Activity that has it's own lifecycle, receives its own input events, which you can add or remove while the activity is running (sort of like a "sub activity" that you can reuse in different activities)

Apart from the obvious advantage of using fragments, UI optimization across different screens, it lets you manage activity's background processing without a visible user interface component.

Now...

====> Why would I complicate my life, coding more...??

Albeit recommended, you don't need to unless you plan to control the lifecycle of individual elements and/or reusing the stack-state or history of previous views.

score 5 · Answer 2 · answered Jun 25 '15 at 05:24

If there's a "gateway" use case for fragment skeptics, it's probably dialogs. The long-deprecated methods showDialog(...), onCreateDialog(...), etc., were nice in that the framework would call them to automatically destroy and recreate your dialogs when the hosting activity was destroyed and recreated. If you create your own dialogs directly, you have to manage all that stuff yourself. But if you use a DialogFragment, you can once again let the framework manage them for you. In this case, fragments can greatly simplify your coding.

score 1 · Answer 3 · answered Aug 03 '15 at 02:36

I asked this question more than one year ago.

I am using fragments everyday and I would recommend it.

First of all, I want to say that using fragments is just an options and will be a reflex to consider it once you start using them.

Advantages:

1/ it helps to modularize the code where you can have a full flow in one Activity, in separated fragments. Example: + list/grid & detail, + login & registration & forget password, + etc. This is awesome to get a reusable code, that you can always copy & past in different projects.

2/ you have a new lifecycle, full of of hassles that's true, but with advantages as well. Example: the retained instance fragment is awesome because it solves the problem of the orientation.

3/ you can manage the flow of your fragments by events and listeners from the Activity.

4/ a stack of your fragments in your Activity.

5/ use the same Action bar in many screens.

And many others...

I am still using the Activity as only container sometimes, especially for the Camera case. Some Android APIs and some third party libraries are not easy to implement in fragments.

Well, it's like any tool, you have to consider it, and judge by yourself if it's better to use it in a case or another.

I hope this can help!!!

Why use Android Fragments?

3 Answers3