Activities & Lifecycle

Configure Manifest

Declare Intent Filters

It is used to handle implicit intents

Intent filters are a very powerful feature of the Android platform. They provide the ability to launch an activity based not only on an explicit request, but also an implicit one. For example, an explicit request might tell the system to “Start the Send Email activity in the Gmail app". By contrast, an implicit request tells the system to “Start a Send Email screen in any activity that can do the job." When the system UI asks a user which app to use in performing a task, that’s an intent filter at work.

Declare Permission

You can use the manifest's <activity> tag to control which apps can start a particular activity.

Activity Lifecycle

Over the course of its lifetime, an activity goes through a number of states. You use a series of callbacks to handle transitions between states. The following sections introduce these callbacks.

onCreate()

which fires when the system creates your activity. Your implementation should initialize the essential components of your activity

For example, your implementation of onCreate() might bind data to lists, associate the activity with a ViewModel, and instantiate some class-scope variables. This method receives the parameter savedInstanceState, which is a Bundle object containing the activity's previously saved state. If the activity has never existed before, the value of the Bundle object is null.

onStart()

As onCreate() exits, the activity enters the Started state, and the activity becomes visible to the user. This callback contains what amounts to the activity’s final preparations for coming to the foreground and becoming interactive.

onResume()

The system invokes this callback just before the activity starts interacting with the user. At this point, the activity is at the top of the activity stack, and captures all user input. Most of an app’s core functionality is implemented in the onResume() method.

onPause()

The system calls onPause() when the activity loses focus and enters a Paused state. This state occurs when, for example, the user taps the Back or Recents button. When the system calls onPause() for your activity, it technically means your activity is still partially visible, but most often is an indication that the user is leaving the activity, and the activity will soon enter the Stopped or Resumed state.

An activity in the Paused state may continue to update the UI if the user is expecting the UI to update. Examples of such an activity include one showing a navigation map screen or a media player playing. Even if such activities lose focus, the user expects their UI to continue updating.

The following example of a LifecycleObserver reacting to the ON_PAUSE event is the counterpart to the preceding ON_RESUME event example, releasing the camera that initializes after the ON_RESUME event is received:

class CameraComponent : LifecycleObserver {

   ...

   @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)

   fun releaseCamera() {

       camera?.release()

       camera = null

   }

   ...

}

onStop()

The system calls onStop() when the activity is no longer visible to the user. This may happen because the activity is being destroyed, a new activity is starting, or an existing activity is entering a Resumed state and is covering the stopped activity. In all of these cases, the stopped activity is no longer visible at all.

Also, use onStop() to perform relatively CPU-intensive shutdown operations. For example, if you can't find a better time to save information to a database, you might do so during onStop(). The following example shows an implementation of onStop() that saves the contents of a draft note to persistent storage:

When your activity enters the Stopped state, the Activity object is kept resident in memory: it maintains all state and member information, but is not attached to the window manager. When the activity resumes, it recalls this information.

onRestart()

The system invokes this callback when an activity in the Stopped state is about to restart. onRestart() restores the state of the activity from the time that it was stopped.

This callback is always followed by onStart().

onDestroy()

The system invokes this callback before an activity is destroyed.

This callback is the final one that the activity receives. onDestroy() is usually implemented to ensure that all of an activity’s resources are released when the activity, or the process containing it, is destroyed.

onDestroy() is called before the activity is destroyed. The system invokes this callback for one of two reasons:

1. The activity is finishing, due to the user completely dismissing the activity or due to finish() being called on the activity.

2. The system is temporarily destroying the activity due to a configuration change, such as device rotation or entering multi-window mode.

Instead of putting logic in your Activity to determine why it is being destroyed, use a ViewModel object to contain the relevant view data for your Activity. If the Activity is recreated due to a configuration change, the ViewModel does not have to do anything, since it is preserved and given to the next Activity instance.

If the Activity isn't recreated, then the ViewModel has the onCleared() method called, where it can clean up any data it needs to before being destroyed. You can distinguish between these two scenarios with the isFinishing() method.

Navigation between activities

Starting one activity from another

Depending on whether or not your activity wants a result back from the new activity it’s about to start, you start the new activity using either the startActivity() method or the startActivityForResult() method. In either case, you pass in an Intent object.

val intent = Intent(this, SignInActivity::class.java)

startActivity(intent)

Your application might also want to perform some action, such as send an email, text message, or status update, using data from your activity. In this case, your application might not have its own activities to perform such actions, so you can instead leverage the activities provided by other applications on the device, which can perform the actions for you.

This is where intents are really valuable. You can create an intent that describes an action you want to perform, and the system launches the appropriate activity from another application. If there are multiple activities that can handle the intent, then the user can select which one to use. For example, if you want to let the user send an email message, you can create the following intent:

val intent = Intent(Intent.ACTION_SEND).apply {

   putExtra(Intent.EXTRA_EMAIL, recipientArray)

}

startActivity(intent)

startActivityForResult()

Sometimes you want to get a result back from an activity when it ends. For example, you might start an activity that lets the user pick a person in a list of contacts. When it ends, it returns the person that was selected. To do this, you call the startActivityForResult(Intent, int) method, where the integer parameter identifies the call.

This identifier is meant to distinguish between multiple calls to startActivityForResult(Intent, int) from the same activity. It's not a global identifier and is not at risk of conflicting with other apps or activities. The result comes back through your onActivityResult(int, int, Intent) method.

override fun onActivityResult(requestCode: Int, resultCode: Int, intent: Intent?) {

   when (requestCode) {

       PICK_CONTACT_REQUEST ->

           if (resultCode == RESULT_OK) {

               // A contact was picked. Display it to the user.

               startActivity(Intent(Intent.ACTION_VIEW, intent?.data))

           }

   }

}