How many Activities vs Fragments?

Question

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.

I think you're on the right track. (And yes, the tutorials are over-simplified).

In a tablet layout, you could use a single Activity and swap in and out Fragments (in multiple 'panes'). While in a phone layout you can use a new Activity for each Fragment.

Like so:

It may seem like a lot of extra work, but by using multiple activities for phones, you enable basic Activity life-cycle and Intent passing. This also allows the framework to handle all the animations and the back-stack.

To help reduce the code you can use a BaseActivity and extend from that.

So if the user has a tablet you would use MyMultiPaneFragActivity or something similar. This activity is responsible for managing callbacks from the fragments and routing intents to the correct fragment (such as a search intent)

If the user has a phone, you can use a regular Activity with very little code and have it extend MyBaseSingleFragActivity or something similar. These activities could be very simple, 5-10 lines of code (maybe even less).

The tricky part is routing intents and whatnot. *(Edit: see more below).

I think the reason this is the recommended way is to save memory and reduce complexity and coupling. If you are swapping out Fragments, the FragmentManager maintains a reference to that Fragment for the back-stack. It also simplifies what should be 'running' for the the user. This setup also decouples the views and layout and logic in the Fragment from the Activity life-cycle. This way a Fragment can exist in a single activity, alongside another fragment (two-pane), or in a three-pane Activity, etc.

*One of the benefits of having regular intent routing is that you can launch an Activity explicitly from anywhere in the back-stack. One example might be in the case of search results. (MySearchResults.class).

Have a read here for more:

http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html

It might be a little more up-front work, because each fragment must work well across separate activities, but it usually pays off. It means that you can use alternative layout files that define different fragment combinations, keep fragment code modular, simplify action bar management, and let the system handle all the back stack work.

Here is Reto Meier's answer regarding the same, taken from this video of Udacity's Android Fundamentals course.

There are a number of reasons you'd be better off breaking your app into different activities.

• Having a single monolithic activity increases the complexity of your code, making it difficult to read, test and maintain.
• Makes creating and managing intent filters much harder.
• Increases the risk of tightly coupling independent components.
• Makes it much more likely to introduce security risks if the single activity includes both sensitive information and information that's safe to share.

A good rule of thumb is to create a new activity whenever the context changes. For example, displaying a different kind of data and while switching from viewing to entering data.

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.

In the master-detail pattern, there are two activities. One shows both fragments on larger screens and only the "master" fragment on smaller screens. The other shows the "detail" fragment on smaller screens.

Your detail logic should be tied up in the detail fragment. Hence, there is no code duplication related to detail logic between activities -- the detail activity merely displays the detail fragment, perhaps passing in data from an Intent extra.

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).

ActionBarSherlock has no more to do with fragments than does the native action bar, since ActionBarSherlock is purely a backport of the native action bar.