Android Fragments vs Activities

I spent an hour or two today trying to figure out the best dividing line between Fragments and Activities in my Android app. I started out by reading through the developer guide on Fragments. The most noteworthy gem I extracted from it was:

You should design each fragment as a modular and reusable activity component. That is, because each fragment defines its own layout and its own behavior with its own lifecycle callbacks, you can include one fragment in multiple activities, so you should design for reuse and avoid directly manipulating one fragment from another fragment.

While designing a client app for my door service, I wanted to design a door list component and a door details component. I wanted to support the use case for tablet with a split pane view that arranged the door list on the left and the door details on the right.

When I started writing the networking code to make API calls to my door service, I wasn’t sure if that logic would go into the activity or into the fragment. Something that complicated that decision was how the door details fragment would be initialized. I wanted to support two use cases for launching the app. In the first case, the app would launch the door list activity which would allow the user to choose the door they wanted to interact with from a list. The second case was to have already selected a default door and launch the door details activity immediately, skipping the door list activity. The second case is useful for quickly opening a door.

To support the first case, all I needed to expose was a setDoor method from my door details fragment so that the door list activity could easily input the selected door from the list. But if the setDoor method was the only one exposed by the door details fragment, then it would be left up to door details activity to keep track of the default door and make API calls to get the Door object to pass into the door details fragment to support the second use case.

Since I wanted to focus on the reuse of the door details fragment outside of the door details activity, I moved the logic for keeping track of the default door into the door details fragment and exposed a new method from it called loadDefaultDoor (I also renamed setDoor to loadDoor for consistency). This loadDefaultDoor method would keep the logic of finding the default door and retrieving its information from the door service inside of the door details fragment.

However, I couldn’t figure out a good way to handle the error cases of loading the default door inside of the door details fragment. The error cases include not having a default door defined, not finding the default door in the door service, or any other networking problem that could arise. To solve this I created a interface that door details fragment’s host activity would have to implement:

/** Interface that host activities of {@ link DoorDetailsFragment}s must implement. */
public interface DoorDetailsHostActivity {
  /** Will always be called on the UI thread. */
  void onNoDoorAvailable();
}

This interface would offload the handling of the case where the door details fragment couldn’t load a door to the host activity. In my app, the host activity handles this by navigating the user back to the door list activity so that they can choose another door.

Functionally, the fragment has access to almost everything that the host activity has access to so the decision on where to draw the boundary between the two should be based on how the fragment will be reused. In my app, I focused on having the activity deal with intents and navigation and having the fragments focused on displaying UI and loading content (from the network if needed). I hope this example helps someone designing their fragment/activity boundaries. You can check out the code for my app at github.com/rltoscano/door-client.