1

I have been researching this for about an hour and cannot figure out whether to use fragments within an activity or start a new fragment activity.

Some sites make it sound as if you should have 1 activity and EVERYTHING else is a fragment. Is that the more proper way now? I can't figure out when you use an Activity (or fragment activity) and when you use a fragment.

I have an app for a conference with: -Speakers (and sub views/activities/fragments) for each speaker. -Schedule (different sections for each day) -General info -Sessions (different sections for each session).

So do I have 4 activities each with their own fragments or do I just use 1 activity with fragments and nested fragments?

dewyze
  • 979
  • 1
  • 7
  • 21

3 Answers3

4

You could do it either way, but generally it is best to use an Activity (or FragmentActivity) for each "screen".

If the user sees your app as logically a single screen that has little panels appearing/disappearing for different kinds of data, then use one activity with a lot of fragments. If the user sees it as "going to different screens", then you probably want multiple activities.

If you go with the one-activity-many-fragments model, you may find that your activity's code gets really complicated dealing with all the possible configurations of fragments. That is a good sign that you may want to split it into multiple Activities. Similarly, if you go with the many-activities model, but find that things get complicated as you pass shared data between activities, consider merging the activities.

Kristopher Johnson
  • 81,409
  • 55
  • 245
  • 302
0

Converting from Activity to FragmentActivity is as simple as changing the extends and nothing else needs changing.

My conclusions:

  • I stopped using Activity and only use FragmentActivity as it is more flexible and more up to date and backwards compatible (Using the support library).

  • If the FragmentActivity has a component that is large enough to be a standalone component, or needs to be one, then I make it as Fragment.

  • I haven't come across something that would require a complete separate activity to be within another activity, but that should only be used if that component is large enough and completely standalone enough to need an activity for itself.

I don't fully understand your app to be able to make a specific call on which you should use, if you want my opinion, can you provide more details on what you are working on and how are those components connected.

Regards

LuckyMe
  • 3,820
  • 2
  • 27
  • 35
  • My question was more about when does something go from being a fragment to an activity. If my fragment has subfragments, do I just do nested fragments or is that the time to make it an activity. I always use fragment activity, I have just been confused as to when something becomes another (fragment) activity or when it's just a fragment. – dewyze Jul 01 '13 at 06:36
  • That is, as far as I am aware, is a design aspect. It is whatever the designer sees most fitting. There isn't a solid line between keeping a fragment or an activity, it goes back to the software developer. But the way I see it, when you have a portion of the screen that is so standalone that it would also work as a complete separate activity then I would promote it to an activity otherwise no promotion. Cheers. – LuckyMe Jul 01 '13 at 22:47
0

Another consideration in choosing a more decomposed architecture (many Activities) might be the cost of destruction / creation in the Activity Lifecycle. Do you plan to use Explicit/Implicit intents to leverage existing apps? More death. So, you might have only one activity in a dispatch oriented model and clearly see your apps logic in one place, but how much state will you have to save/restore? Are there performance penalties for re-inflating or populating data resources?

kandinski
  • 860
  • 1
  • 8
  • 13