Android navigation from sliding menu - fragments or activities?

Question

I'm upgrading an Android application that used the Dashboard pattern to the Sliding Menu, with a library by jfeinstein.

Originally I had a DashboardActivity that had 6 buttons, each of which started its corresponding Activity on tap. I also have about 30 other activities that can be started from those "top-level" activities.

Now, I have two possible approaches:

1. Define some kind of MenuActivity, which will include the SlidingMenu fragment, and launch activities on menu items selected, as in the old version.
2. Define only one activity and convert the existing activities to fragments, and show them in a content frame.

When looking at the examples for the sliding menu library, I got the idea that it might be the best approach, as it used switching fragments, but I still think that an Activity is better for a screen than a Fragment.

Is there any reason to use single activity and fragments for content?

Answer 1

Fragments API is your friend. No, Really.

(adapted from the interwebs and Glenn Bech's answer on SO)

1. Re-Usable

Fragments are Android's solution to creating reusable user interfaces. You can achieve some of the same things using activities and layouts (for example by using includes). However; fragments are wired in to the Android API, from HoneyComb, and up.

2. Light Weight

There is a lot of additional responsibility to an Activity since its a primary component. Like providing a context, etc. Without these additional responsibilities, fragments are lightweight and are especially beneficial as you have many of them (when activities are refactored to fragments). Did I mention they are lightweight?

3. Work with the API, not against it

The ActionBar. If you want tabs up there to navigate your app, you quickly see that ActionBar.TabListener inferface gives you a FragmentTransaction as an input argument to the onTabSelected method. You could probably ignore this, and do something else and clever, but you'd be working against the API, not with it.

4. Clever BackStack and customizable too

The FragmentManager handles "back" for you in a very clever way. Back does not mean back to the last activity, like for regular activities. It meeans back to the previous fragment state. This is more awesomed (yes, its a word) by the fact that you can control when and how the backstack is used.

5. Glitter and Glamour

Where the hell do you think all the Hollywood effects come from eh? You can use the cool ViewPager with a FragentPagerAdapter to create swipe interfaces. The FragmentPagerAdapter code is much cleaner than a regular adapter, and it controls instantiations of the individual fragments. The transition and swipe animations you can apply to fragments are a few things you can't do with Activities.

6. Tablets and phones

Bigger Phone? No it's a Tablet. Your life will be a lot easier if you use Fragments when you try to create applications for both phones and tablets. Since the fragments are so tied in with the Honeycomb+ APIs, you will want to use them on phones as well to reuse code. That's where the compatibility library comes in handy.

7. Phone only man huh?

You even could and should use fragments for apps meant for phones only. If you have portability in mind. I use ActionBarSherlock and the compatibility libraries to create "ICS looking" apps, that look the same all the way back to version 1.6. You get the latest features like the Actionbar, with tabs, overflow, split action bar, viewpager etc.

One more thing

8. Cross-Communication

The best way to communicate between fragments are intents. When you press something in a Fragemnt you would typically call StartActivity() with data on it. The intent is passed on to all fragments of the activity you launch. It's just easier.