New Android apps should always be built using the Jetpack (androidx) version of fragments. If you maintain older apps, you may see two other versions of fragments being used: the framework version and the v4 support library version. These are legacy versions of the Fragment class, and you should migrate apps that use them to the current Jetpack version.

Fragments were introduced in API level 11, when the first Android tablets created the need for UI flexibility. The framework implementation of fragments was built into devices running API level 11 or higher. Shortly afterward, a Fragment implementation was added to the v4 support library to enable fragment support on older devices. With each new version of Android, both of these fragment versions were updated with new features and security patches.

But as of Android 9.0 (API 28), the framework version of fragments is deprecated and the earlier support library fragments have been moved to the Jetpack libraries. No further updates will be made to either of those versions, so you should not use them for new projects. All future updates will apply only to the Jetpack version.

Bottom line: Always use the Jetpack fragments in your new projects, and migrate existing projects to ensure they stay current with new features and bug fixes.

CrimeDetailFragment is the class that interacts with model and view objects. Its job is to present the details of a specific crime and update those details as the user changes them.

In GeoQuiz, your activities did most of that work in activity lifecycle functions. In CriminalIntent, this work will be done by fragments in fragment lifecycle functions. Many of these functions correspond to the Activity functions you already know, such as onCreate(Bundle?). (You will learn more about the fragment lifecycle in the section called The fragment lifecycle later in this chapter.)

In CrimeDetailFragment.kt, add a property for the Crime instance and an implementation of Fragment.onCreate(Bundle?).

Android Studio can provide some assistance when overriding functions. Begin typing onCreate(Bundle?); Android Studio will provide a list of suggestions, as shown in Figure 9.10.

Figure 9.10  Overriding the onCreate(Bundle?) function

Press Return to select the option to override the onCreate(Bundle?) function, and Android Studio will create the declaration for you, including the call to the superclass implementation. Update your code to create a new Crime, matching Listing 9.6.

class CrimeDetailFragment : Fragment() {

    private lateinit var crime: Crime

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        crime = Crime(
            id = UUID.randomUUID(),
            title = "",
            date = Date(),
            isSolved = false
        )
    }
}

Much like activities, fragments are re-created on configuration changes by default, so they are not good places to hold state. In Chapter 13, you will use a ViewModel to hold this state, but this will work for now.

Kotlin functions default to public when no visibility modifier is included in the definition. So Fragment.onCreate(Bundle?), which has no visibility modifier, is public. This differs from the Activity.onCreate(Bundle?) function, which is protected. Fragment.onCreate(Bundle?) and other Fragment lifecycle functions must be public, because they will be called by whichever activity is hosting the fragment.

Also, note what does not happen in Fragment.onCreate(Bundle?): You do not inflate the fragment’s view. You configure the fragment instance in Fragment.onCreate(Bundle?), but you create and configure the fragment’s view in another fragment lifecycle function: onCreateView(LayoutInflater, ViewGroup?, Bundle?).

This function is where you inflate and bind the layout for the fragment’s view and return the inflated View to the hosting activity. The LayoutInflater and ViewGroup parameters are necessary to inflate and bind the layout. The Bundle will contain data that this function can use to re-create the view from a saved state.

In CrimeDetailFragment.kt, add an implementation of onCreateView(…) that inflates and binds fragment_crime_detail.xml. You can use the same trick from Figure 9.10 to fill out the function declaration.

class CrimeDetailFragment : Fragment() {

    private lateinit var binding: FragmentCrimeDetailBinding

    private lateinit var crime: Crime

    override fun onCreate(savedInstanceState: Bundle?) {
        ...
    }

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        binding =
            FragmentCrimeDetailBinding.inflate(inflater, container, false)
        return binding.root
    }
}

Much like in GeoQuiz, View Binding will generate a binding class that you can use to inflate and bind your layout. This time it is called FragmentCrimeDetailBinding.

As before, you call the inflate(…) function to accomplish the task. However, this time you call a slightly different version of the function – one that takes in three parameters instead of one. The first parameter is the same LayoutInflater you used before. The second parameter is your view’s parent, which is usually needed to configure the views properly.

The third parameter tells the layout inflater whether to immediately add the inflated view to the view’s parent. You pass in false because the fragment’s view will be hosted in the activity’s container view. The fragment’s view does not need to be added to the parent view immediately – the activity will handle adding the view later.

Once you return the root view within the binding, you are ready to start wiring up the views.

You are now going to hook up the EditText, CheckBox, and Button in your fragment. Your first instinct might be to add some code to onCreateView(…), but it is best if you keep onCreateView(…) simple and do not do much more there than bind and inflate your view. The onViewCreated(…) lifecycle callback is invoked immediately after onCreateView(…), and it is the perfect spot to wire up your views.

Start by adding a listener to the EditText in the onViewCreated(…) lifecycle callback.

class CrimeDetailFragment : Fragment() {
    ...
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        ...
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        binding.apply {
            crimeTitle.doOnTextChanged { text, _, _, _ ->
                crime = crime.copy(title = text.toString())
            }
        }
    }
}

Setting listeners in a fragment works exactly the same as in an activity. Here, you add a listener that will be invoked whenever the text in the EditText is changed. The lambda is invoked with four parameters, but you only care about the first one, text. The text is provided as a CharSequence, so to set the Crime’s title, you call toString() on it.

(The doOnTextChanged() function is actually a Kotlin extension function on the EditText class. Do not forget to import it from the androidx.core.widget package.)

When you are not using a parameter, like the remaining lambda parameters here, you name it _. Lambda arguments named _ are ignored, which removes unnecessary variables and can help keep your code tidy.

Next, connect the Button to display the date of the crime.

class CrimeDetailFragment : Fragment() {
    ...
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        binding.apply {
            crimeTitle.doOnTextChanged { text, _, _, _ ->
                crime = crime.copy(title = text.toString())
            }

            crimeDate.apply {
                text = crime.date.toString()
                isEnabled = false
            }
        }
    }
}

Disabling the button ensures that it will not respond to the user pressing it. It also changes its appearance to advertise its disabled state. In Chapter 14, you will enable the button and allow the user to choose the date of the crime.

The last change you need to make within this class is to set a listener on the CheckBox that will update the isSolved property of the Crime, as shown in Listing 9.10.

class CrimeDetailFragment : Fragment() {
    ...
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        binding.apply {
            crimeTitle.doOnTextChanged { text, _, _, _ ->
                crime = crime.copy(title = text.toString())
            }

            crimeDate.apply {
                text = crime.date.toString()
                isEnabled = false
            }

            crimeSolved.setOnCheckedChangeListener { _, isChecked ->
                crime = crime.copy(isSolved = isChecked)
            }
        }
    }
}

It would be great if you could run CriminalIntent and play with the code you have written. But you cannot – yet. Remember, fragments cannot put their views onscreen on their own. To realize your efforts, you first have to add a CrimeDetailFragment to MainActivity.