0

I think I have found contradictory design guidance within the Google Android documentation on fragmentation.

The first statement below advises each fragment be unaware of other fragments and always communicate only to the activity and let the activity decides what needs to be done.

Creating event callbacks to the activity

In some cases, you might need a fragment to share events with the activity. A good way to do that is to define a callback interface inside the fragment and require that the host activity implement it. When the activity receives a callback through the interface, it can share the information with other fragments in the layout as necessary.

For example, if a news application has two fragments in an activity—one to show a list of articles (fragment A) and another to display an article (fragment B)—then fragment A must tell the activity when a list item is selected so that it can tell fragment B to display the article. In this case, the OnArticleSelectedListener interface is declared inside fragment A:

But a second statement later on the same page, a list fragment directly instantiates detail fragment.

   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();
            if (index == 0) {
                ft.replace(R.id.details, details);
            } else {
                ft.replace(R.id.a_item, details);
            }
            ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
            ft.commit();

So my questions:

Are these contradicting each other?
Should this be left to Activity?

I feel confused, so any clarification is appreciated.

1
  • 2
    I don't think this should be migrated. While it points to specific document, it is still a design issue, not a technical one, so it belongs here more than on SO.
    – Jan Hudec
    Commented Mar 10, 2014 at 14:28

1 Answer 1

1

Kind of yet I suppose.

The point of the first quoted paragraph should really be that they should be connected via activity, they should be connected via the parent, which may be an activity or a composite fragment. This is done to allow easier redesign where one of the fragments needs to be replaced and generally to maintain proper separation of concerns.

Now in the example they are providing some functionality to connect the fragments directly. That indeed does not look like following the above advice. It would make more sense to provide an interface through which the list widget would expose details of the selected item and an implementation of that interface using the other fragment. Then it would still be easy to just connect the two fragments via that interface from the activity, but it would at the same time provide consistent method of using different details view.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.