Figure 7.11 shows the fragment lifecycle. It is similar to the activity lifecycle: It has stopped, paused, and resumed states, and it has methods you can override to get things done at critical points – many of which correspond to activity lifecycle methods.

Figure 7.11  Fragment lifecycle diagram

The correspondence is important. Because a fragment works on behalf of an activity, its state should reflect the activity’s state. Thus, it needs corresponding lifecycle methods to handle the activity’s work.

One critical difference between the fragment lifecycle and the activity lifecycle is that fragment lifecycle methods are called by the hosting activity, not the OS. The OS knows nothing about the fragments that an activity is using to manage things. Fragments are the activity’s internal business.

You will see more of the fragment lifecycle methods as you continue building CriminalIntent.

You have two options when it comes to hosting a UI fragment in an activity:

The first approach is known as using a layout fragment. It is straightforward but inflexible. If you add the fragment to the activity’s layout, you hardwire the fragment and its view to the activity’s view and cannot swap out that fragment during the activity’s lifetime.

The second approach, adding the fragment to the activity’s code, is more complex – but it is the only way to have control at runtime over your fragments. You determine when the fragment is added to the activity and what happens to it after that. You can remove the fragment, replace it with another, and then add the first fragment back again.

Thus, to achieve real UI flexibility you must add your fragment in code. This is the approach you will use for CrimeActivity’s hosting of a CrimeFragment. The code details will come later in the chapter. First, you are going to define CrimeActivity’s layout.

You will be adding a UI fragment in the hosting activity’s code, but you still need to make a spot for the fragment’s view in the activity’s view hierarchy. In CrimeActivity’s layout, this spot will be the FrameLayout shown in Figure 7.12.

Figure 7.12  Fragment-hosting layout for CrimeActivity

This FrameLayout will be the container view for a CrimeFragment. Notice that the container view is completely generic; it does not name the CrimeFragment class. You can and will use this same layout to host other fragments.

Locate CrimeActivity’s layout at res/layout/activity_crime.xml. Open this file and replace the default layout with the FrameLayout diagrammed in Figure 7.12. Your XML should match Listing 7.5.

<FrameLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/fragment_container"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

Note that while activity_crime.xml consists solely of a container view for a single fragment, an activity’s layout can be more complex and define multiple container views as well as widgets of its own.

You can preview your layout file or run CriminalIntent to check your code. You will see an empty FrameLayout below a toolbar containing the text CriminalIntent (Figure 7.13). (If the preview window does not render the screen correctly, or you see errors, build the project by selecting Build → Rebuild Project. If that still does not work correctly, run the app on your emulator or device. As of this writing, the preview window can be finicky.)

Figure 7.13  An empty FrameLayout

The FrameLayout is empty because the CrimeActivity is not yet hosting a fragment. Later, you will write code that puts a fragment’s view inside this FrameLayout. But first, you need to create a fragment.

(The toolbar at the top of your app is included automatically because of the way you configured your activity. You will learn more about the toolbar in Chapter 13.)