Building User Screen Flows

This chapter covers the Android activity lifecycle and explains how the Android system interacts with your app. By the end of this chapter, you’ll have learned how to build user journeys through different screens. You’ll also be able to use activity tasks and launch modes, save and restore the state of your activity, use logs to report on your application, and share data between screens.

The previous chapter introduced you to the core elements of Android development, from configuring your app using the AndroidManifest.xml file, working with simple activities, and the Android resource structure to building an app with gradle and running an app on a virtual device.

In this chapter, you’ll go further and learn how the Android system interacts with your app through the Android lifecycle, how you are notified of changes to your app’s state, and how you can use the Android lifecycle to respond to these changes.

You’ll...

Technical requirements

The complete code for all the exercises and the activity in this chapter is available on GitHub at https://packt.link/PmKJ6

The Activity lifecycle

In the previous chapter, we used the onCreate(saveInstanceState: Bundle?) method to display a layout in the UI of our screen. Now, we’ll explore in more detail how the Android system interacts with your application to make this happen. As soon as an Activity is launched, it goes through a series of steps to take it through initialization, from preparing to be displayed to being partially displayed and then fully displayed.

There are also steps that correspond with your application being hidden, backgrounded, and then destroyed. This process is called the Activity lifecycle. For every one of these steps, there is a callback that your Activity can use to perform actions such as creating and changing the display and saving data when your app has been put into the background and then restoring that data after your app comes back into the foreground.

These callbacks are made on your Activity’s parent, and it’s up to you to decide whether...

Saving and restoring the Activity state

In this section, you’ll explore how your Activity saves and restores the state. As you’ve learned in the previous section, configuration changes, such as rotating the phone, cause the Activity to be recreated. This can also happen if the system has to kill your app in order to free up memory.

In these scenarios, it is important to preserve the state of the Activity and then restore it. In the next two exercises, you’ll work through an example ensuring that the user’s data is restored when TextView is created and populated from a user’s data after filling in a form.

Exercise 2.02 – saving and restoring the state in layouts

In this exercise, firstly create an application called Save and Restore with an empty activity. The app you are going to create will have a simple form that offers a discount code for a user’s favorite restaurant if they enter some personal details (no actual information...

Activity interaction with Intents

An intent in Android is a communication mechanism between components. Within your own app, a lot of the time, you will want another specific Activity to start when some action happens in the current activity. Specifying exactly which Activity will start is called an explicit intent. On other occasions, you will want to get access to a system component, such as the camera. As you can’t access these components directly, you will have to send an intent, which the system resolves in order to open the camera. These are called implicit intents. An intent filter has to be set up in order to register to respond to these events. Go to the AndroidManifest.xml file from the previous exercise and you will see an example of two intent filters set within the <intent-filter> XML element of the MainActivity:

<intent-filter>
    <action android:name="android.intent.action.MAIN"/>
    <...

Intents, Tasks, and Launch Modes

Up until now, you have been using the standard behavior for creating Activities and moving from one Activity to the next. When you open the app from the launcher with the default behavior, it creates its own Task, and each Activity you create is added to a back stack, so when you open three Activities one after the other as part of your user’s journey, pressing the back button three times will move the user back through the previous screens/Activities and then go back to the device’s home screen, while still keeping the app open.

The launch mode for this type of Activity is called Standard; it is the default and doesn’t need specifying in the Activity element of AndroidManifest.xml. Even if you launch the same Activity three times, one after the other, there will be three instances of the same activity that exhibit the behavior described previously.

For some apps, you may want to change this behavior so the same instance is...

Summary

In this chapter, you have covered a lot of the groundwork of how your application interacts with the Android framework, from the Activity lifecycle callbacks to retaining the state in your activities, navigating from one screen to another, and how intents and launch modes make this happen. These are core concepts that you need to understand in order to move on to more advanced topics.

In the next chapter, you will be introduced to fragments and how they fit into the architecture of your application, as well as exploring more of the Android resources framework.