3

I've been developing for Android for a couple of years now, and I still find myself going back and forth on this issue: when should I be using fragments on a backstack versus putting each fragment into its own activity?

In the Android Fragment documentation, they show this diagram:

I understand the tablet use case perfectly, but for the Handset use case, I don't get why you would put each fragment into its own activity. I typically create one activity and add the fragments to the backstack (via FragmentManager). Is either one of these approaches considered the 'right' way to do it? If both are okay, what is a good rule of thumb to use for picking which approach to use?

This question is closely related, but I'm not totally satisfied with it. If you're supposed to use separate activities, what's the point of having a fragment backstack in the first place?

Community
  • 1
  • 1
Ryan J. Thompson
  • 650
  • 1
  • 6
  • 18

2 Answers2

3

I doubt there is a right way to do it. There are likely some ways that are better than others in some circumstances, but for the most part, the answer will be "it depends."

I have noticed in the latest version (22.x) of the SDK with Eclipse that every Activity that is generated is nothing more than a placeholder for a Fragment. The Fragment is auto generated and contains the view logic. It seems like they want to make Activities nothing more than a placeholder/controller for Fragments. I don't think I agree with that. While I definitely see the use case for Tablets, I feel like this pattern should be used more on an as needed basis than as a general rule. This is just my opinion, but I think moving ALL of the logic into the Fragment sacrifices some of the benefits you get from using an Activity, so it is only a useful pattern if you need to re-use that fragment specifically.

If you're supposed to use separate activities, what's the point of having a fragment backstack in the first place?

Good question. I personally prefer to use many Activities and only use Fragments where I need to re-use the logic/views in multiple places. I think the flow of using startActivity and startActivityForResult and allowing the system to manage your activity stack is just a little easier than trying to manage a huge Fragment back stack and one Activity (again, just my opinion).

So when would I ever use the Fragment back stack? There was actually a very good situation for me to use it recently. I had an Activity that needed to build a very complex object. The Object needed many fields input to the user, so I created a Workflow that walked the user through this process one step at a time. I created a single Activity to handle the creation of this logic. Each step of the UI was a Fragment that took input from the user, reported back to the Activity, then the Activity loaded the next Fragment. The Fragments were added to the back stack so the user could go back to previous steps in the workflow.

Object1CreationActivity

FragmentA --> FragmentB --> FragmentC --> FragmentD

Communication between the Fragments and the Activity should be done with interfaces. This is important if we want to re-use these anywhere else. Because of this, I could re-use much of this code to create another Object.

Object2CreationActivity

FragmentB --> FragmentD --> FragmentE

To summarize, Fragments, Activities, the back stack, these are all powerful tools you can use to make Android applications. There may not be a great rule of thumb for when and how to use them, but as long as you are well versed in how they work together, you can use them as appropriate for your application.

jacobhyphenated
  • 2,105
  • 2
  • 17
  • 27
  • Good point about startActivity/startActivityForResult. These could still be used if you were doing the 'Activity as a controller for Fragments' method, couldn't they? – Ryan J. Thompson May 07 '14 at 15:14
  • Fragments can call `startActivity` and `startActivityForResult`, so yes, you can use them perfectly fine with Fragments (Note that child fragments don't work correctly with `startActivityForResult`). – jacobhyphenated May 07 '14 at 15:23
0

fragments are light weight alternatives to activities....that is one way to look at it. e.g. i have my our app which has about 10-13 screens. Either

  • I create a new activity for each one of them. OR
  • I create only a few activities that are logically distinct in functional aspects ad swap view screens in them OR
  • I create 1 activity and delegate actual screen functional to fragments.

I find the third way much better and manageable. Its kinda saying that fragments allow reuse of view using the framelayout options. Further more you can devise an easy way to share data between fragments as against the heavy weight way of using a Parceable to share stuff between activities.

Also Android API folks are going to focus more on fragment based designs instead of activities so its better to stick with standards. Using fragments i a just a tad more complicated than using activities but is well worth the effort to learn them. Helps create scalable and quiet reusable screen views IMHO.

Nazgul
  • 1,892
  • 1
  • 11
  • 15