Each activity goes through a lifecycle as it comes to the screen and then goes away. In this video, learn how to describe the activity lifecycle from creation to destruction.
- [Instructor] Any discussion of Android app architecture has to start with activities. An android activity is a definition of a single focused thing that the app's user does. An activity doesn't always have a visual component. On an Internet of Things device, for example, an activity might send messages to a hardware component, but the device might not have a screen. But on a more conventional Android device, a phone, a tablet, or a Chromebook, each activity defines one or more of the app's screens. Each activity goes through a lifecycle, a series of states as it appears and disappears on the device. This starts with activity creation, and ends with the activity being destroyed, but there are many other states that it can go through in between. Activities are grouped into tasks. The tasks activities are managed on a last in, first out basis, meaning that when the user presses a Back button, or finishes the activity, the current activity will be removed from memory, and the previous activity will be active again. Typically, all of the activities of a single app are in the same task, so for example, when you first open an app, its main activity, marked as the launch activity in the application manifest, is displayed. That activity is part of a task. If the app launches a second activity, the first activity is added to a queue known as the back stack, and the second activity is now active and at the top of the stack. If the user were then to press the device's Back button or the application finished the second activity, that would remove the second activity from the stack. And the first activity would come to the foreground. If you then open a second activity, that creates a second task. If the user would then press the Home button on the device, both tasks would go into the background, and the user could switch between them by using whatever user interface is offered by their particular version of Android. So the Back button, whether it's a hardware button on a device or a software-generated Back button, removes the most recent activity from the task. That's called popping the activity from the task's back stack, and returns to the parent. If it's the top activity in the stack and there is no back stack, then that closes the application completely, and then you would return to either another task, or to the application's launcher screen. You can do the same thing as the Back button, that is, close the current activity by calling a function named finish. It's also important to know that when activities and tasks are in the background, they can be removed from memory by the application framework and the operating system. This will happen whenever the device is low on memory or other resources. You as the developer have some tools to control that, but they should be used sparingly. You'll get the best performance out of Android devices by allowing the application framework and operating system to manage background tasks. So each task has a back stack, and only one activity can be active at any given time. An activity is active when the user can interact with it. It's possible for more than one activity to be visible at the same time, say in a split screen or a multiwindow environment, but only one of them can be active. And one activity can be the previous activity on the back stack. Any other activities within a task are queued in that back stack as other previous activities. Each activity has multiple states. When an activity is active, it's said to be resumed. It's at the top of the stack, it's visible, and the user can interact with it. When it's paused, it can be visible to the user but it doesn't have focus. If it's stopped, it isn't visible but it's still in memory, and if it's inactive, it's been completely removed from the activity stack. And here is a visualization of the entire lifecycle. As the activity is created and brought to the screen, a function called onCreate is called automatically from the app framework. This is one of many callback functions that you can override in your activities. After the onCreate function, the onStart function is called, and then onResume. And these functions are called in quick succession, because the resumed state is the resting state, the state in which the user can interact with the activity. When the task is removed from the back stack, it goes into the paused state, and then into the stopped state. And if the activity is destroyed, either because you did it programmatically or the operating system did it by removing the task from memory, that would result in calling a function called onDestroy. There is another possible path, from the stopped state, you can go through an onRestart and then once again, the onStart function, and from the paused state, you can go through onResume. Understanding the activity lifecycle is critical for all Android developers. As you work on Android apps, you will learn where the best place is to put particular types of code, as an activity starts up, and shuts down.
Looking for study partners?Join the Associate Android Developer Exam study group
The Android app architecture constantly evolves. The introduction of the Kotlin programming language, new form factors such as Chromebooks, and reusable architecture components have made it faster and easier than ever to build high-quality Android apps. It is imperative that developers understand what the latest tools and recommendations are and how to use them to build out their applications. In this course, instructor David Gassner explains how to build an Android app that uses Kotlin instead of Java, add navigation functionality, and leverage the most useful architecture components such as LifecycleObserver, ViewModel, and LiveData, to create apps that are robust and easy to maintain over time.
- Handling lifecycle events
- Handling view events
- Updating display from new data
- Adding ViewModels to activities
- Subscribing to changes in LiveData values
- Adding a new launcher activity
- Starting activities with explicit intents
- Sharing data with implicit intents
- Adding a navigation drawer
- Adding a header to a navigation drawer
- Handling navigating drawer menu events