Question

Intro:

The basic “Fragments Tutorial” pattern goes something like this:

1. On a tablet, have a list on the left, details on the right.
2. Both are Fragments and both reside in the same Activity.
3. On a phone, have a
   list Fragment in one Activity.
4. Launch a new Activity with the details Fragment.

(e.g. Android 3.0 Fragments API by Dianne Hackborn and the Fragments API Guide)

On both devices, functionality is in the Fragments. (simple)

On the Tablet, the whole app is 1 Activity, on the phone, there are many Activities.

---

Questions:

• Is there a reason to split the phone app into many Activities?

One problem with this method, is that you duplicate a lot of the logic in the main Tablet Activity, and in the separate Phone Activities.

• Would it not be easier to retain the 1 Activity model in both cases,
  using the same logic of switching Fragments in and out (just using a different layout)?

This way most of the logic resides in the Fragments themselves, and there is only a single Activity – less duplication of code.

Also what I have read about the ActionBarSherlock is that it seems to work best with Fragments instead of Activities (but I have not worked with it yet).

Are the tutorials oversimplified, or have I missed something major in this approach?

---

We have tried both approaches successfully in the office – but I am about to start a bigger project and want to make things as easy for myself as possible.

Some links to related questions:

• Dilemma: when to use Fragments vs Activities:
• Patterns when to use Activity Transition vs Dynamic Fragments
• Android – I need some clarifications of fragments vs activities and views
• Activities or fragments in Android?
• Multiple fragments and activities interaction design
• So what are the exact advantages of Fragments in Android 3.0?

---

Updates

Started bounty on question – still not convinced about why I need to duplicate my app logic in my tablet activity and in each phone activity.

Also found an interesting article by the guys at Square, which is well worth reading:

• Advocating Against Android Fragments

Answer 1

I agree that the tutorials are very simplified. They just introduce Fragments but I do not agree with the pattern as suggested.

I also agree that it is not a good idea to duplicate your app’s logic across many Activities (see DRY Principle on wikipedia).

---

I prefer the pattern used by the ActionBarSherlock Fragments Demo app (download here and source code here). The demo that most closely matches the tutorial mentioned in the question is the one called “Layout” in the app; or FragmentLayoutSupport in the source code.

In this demo, the logic has been moved out of the Activity and into the Fragment. The TitlesFragment actually contains the logic for changing Fragments. In this way, each Activity is very simple. To duplicate many very simple Activities, where none of the logic is inside the Activities, makes it very simple.

By putting the logic into the Fragments, there is no need to write the code more than once; it is available no matter which Activity the Fragment is placed into. This makes it a more powerful pattern than the one suggested by the basic tutorial.

    /**
    * Helper function to show the details of a selected item, either by
    * displaying a fragment in-place in the current UI, or starting a
    * whole new activity in which it is displayed.
    */
    void showDetails(int index)
    {
        mCurCheckPosition = index;

        if (mDualPane)
        {
            // We can display everything in-place with fragments, so update
            // the list to highlight the selected item and show the data.
            getListView().setItemChecked(index, true);

            // Check what fragment is currently shown, replace if needed.
            DetailsFragment details = (DetailsFragment) getFragmentManager()
                .findFragmentById(R.id.details);
            if (details == null || details.getShownIndex() != index)
            {
                // Make new fragment to show this selection.
                details = DetailsFragment.newInstance(index);

                // Execute a transaction, replacing any existing fragment
                // with this one inside the frame.
                FragmentTransaction ft = getFragmentManager()
                    .beginTransaction();
                ft.replace(R.id.details, details);
                ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
                ft.commit();
            }

        }
        else
        {
            // Otherwise we need to launch a new activity to display
            // the dialog fragment with selected text.
            Intent intent = new Intent();
            intent.setClass(getActivity(), DetailsActivity.class);
            intent.putExtra("index", index);
            startActivity(intent);
        }
    }

---

Another advantage of the ABS pattern is that you do not end up with a Tablet Activity containing lots of logic, and that means that you save memory. The tutorial pattern can lead to a very big main activity in a more complex app; since it needs to handle the logic of all the fragments that get placed in it at any time.

Overall, do not think of it as being forced to use many activities. Think of it as having the opportunity to split your code into many fragments, and saving memory when using them.