Question

I am trying to learn Fragments in Android and from various examples I have found there seems to be different ways of doing it and I just wanted to get some advice as to which is the correct way, or at least under which circumstances one way should be used over another.

One example created a layout that contained a fragment and a FrameLayout. In the code, when an item is selected from the ListFragment a new Fragment is created (with some data it requires in the constructor) and the FrameLayout is replaced with this new Fragment (using FragmentTransaction.replace()).

Another example has a layout file that declares the 2 fragments side by side. Now in the code when the user selects an item from the list in one fragment a call is made to the other fragment to update the data (based on the selected item).

So I am just wondering if either of these methods is preferred over the other or if there are certain circumstances where one should be used?

EDIT: here is the code for each of the two methods I was referring to:

1:

        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);
        }

2:

public void onListItemClick(ListView l, View v, int position, long id) {
    String item = (String) getListAdapter().getItem(position);
    DetailFragment fragment = (DetailFragment) getFragmentManager()
            .findFragmentById(R.id.detailFragment);
    if (fragment != null && fragment.isInLayout()) {
        fragment.setText(item);
    } else {
        Intent intent = new Intent(getActivity().getApplicationContext(),
                DetailActivity.class);
        intent.putExtra("value", item);
        startActivity(intent);

    }

}

Answer 1

So I am just wondering if either of these methods is preferred over the other or if there are certain circumstances where one should be used?

If the actual fragment does not need to change (i.e., it is the same fragment class), I would have the activity call a method on that fragment rather than replace it (your scenario #2), assuming it exists. That’s much less expensive at runtime, and it’s probably simpler to code as well.

If, however, the fragment might need to be a different one (e.g., depending on what you click, there may be different fragments for different types of model objects represented in the list), then replacing the fragment will be needed (your scenario #1). You could optimize the case where the fragment happens for this event to be of the same class, though I’d focus first on getting it working just by replacing the fragment and worry about the optimization if/when you have the time and inclination.

I’m not a fan of your #2 code structurally, though. IMHO, fragments should not be talking with other fragments directly. My preferred pattern is for fragments to “stick to their knitting”, focusing solely on things within their own widgets and models. For events that affect other parts of the UI (e.g., list click), have the fragment notify the activity (e.g., via a listener interface). The activity is the one that knows which fragments should be around, as it is the one that created them in the first place. The activity can then either talk to the other fragment (if it exists), create the other fragment (if there is room), or start up another activity. If you prefer your #2 approach, you are welcome to use it — it’s just not what I’d do in your circumstance.