Activity life cycle
Activities in Android go through
a life cycle, a set of stages as they appear
and disappear on the device. Activities are grouped into tasks. Typically,
the activities of a single app are all in the same task. For
example, when you first open an app, its launch activity comes to the screen. And
that Activity is part of a Task. If that Activity launches a
second Activity, the first Activity goes to the back of a stack, known as
the Back Stack, and the second Activity is on 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. Now
take a scenario where the user presses the
Home button on the device, and then goes to a new application. That
creates a second task, which has its own stack of activities. The
user can then switch between tasks, either by going
through the launcher screen, that is by pressing the home
button, and then relaunching the first task, or bygoing to the screen that
lists all the open tasks.
Either way, all of these activities are
still available, as long as the device has adequate memory and resources. But
at any time, if the operating system detects a low memory condition, it
can remove certain tasks and activities from memory forcing them to be
relaunched. Here
are some of the rules around activity stacks. On
a single device, only one activity is active at any given time. There
can be more than one visible activity. For
example, in a screen that's laid out with
fragments, you might have a couple of different activities
visible, each with their own layouts, but only one
will be fully interactive at any given time.
While that one activity is active, another
activity can
be the most recent, or last activity. And,
if the user presses the Back button, or
the active activity finishes, then that last activity
can become active. Other
activities that have been previously viewed, are queued
in the Back Stack as previous activities. And
you can have as many activities in the back stack,
as are necessary for the functionality of an app. An
activity can be in one of a number of different states.
There are transient states, states that an
activity goes
through to get somewhere else, and resting states. If
an activity is visible and interactive, it's said to be either active or
resumed.That means it's at the top of the stack. It's
visible, and the user can interact with it. An
activity that's paused, can be visible but without focus. So
let's imagine a nap where you have a list on
the left, and a detail screen on the right. If
the user is scrolling the list, then the detail screen will be paused.
And if the user is typing something into the
detail screen, then the list will be paused. But
both activities can't be active at the same time. An
activity that's been pushed to the back of the stack but not removed from
memory, is said to be stopped. It's
not visible, but it might be retaining its state. And
an activity that's inactive has been completely removed
from the activity stack, and will need to
be reinstantiated to be used again. Here's
what the activity life cycle looks like, and some
tips about how you can program with it.
Tracing state
changes with logcat
Each of the events that's
triggered as you move from
activity to activity is associated with a method. The
methods are named for the events, such as onCreate, onResume, onPause, and so
on. The
default versions of these methods are implemented in
the activity class or its super classes. To
add your own custom code to these methods, you need to override the
methods.When you create a
brand new Android project, its MainActivity class
already has an onCreate method, and in
this project, activity life cycle, I've added
a logging message to the onCreate method.
I'm using a log tag of MainActivity, and I'm outputting
a message named for the method itself, onCreate. I'll
run the application in the emulator, and then go look at LogCat. I'm
going to adjust my screen a little bit here, so
I can see the messages that are being output. Notice
that I'm filtering on the tag, MainActivity. Now,
I'm going to add some more method overrides. As
an activity comes to the screen, in addition to the onCreate event, you'll also
get an onResume and an onStart. So, I'll implement those methods.
I'll type the beginning of onResume, press
Ctrl+space, and select it from the list. Then
I'll remove the comment, and very importantly, after the
call to the super classes method, I'll logthe method with Log.d, and I'll pass
in the LOGTAG
constant and the name of the method, onResume. And
I'll do the same thing for onStart. I'll
implement the method, get rid of the auto-generated comment, and add
the logging message. Now I'll test the application again.
Before I launch it, I'll clear the LogCat
console, then I'll run the application, and
as the application comes to life, I see the messages in their proper order. With
onCreate, then onStart, and onResume. Now,
I'll show what happens as you restart the
application from a couple of different states. First, I'll
leave the application entirely by pressing the back button.Then I'll go to the
application list, and I'll run the
application again, and I see all three events happen.
Next, I'll go back to the home screen by
pressing the home button. And
once again I'll start the application, and this time I get an onStart
and an onResume, and remember, when the
user leaves the application by touching the
home button, that doesn't destroy the activity. That
task remains in memory, if possible given
available resources, and in this situation, it was
still there, so it was started and resumed, but it had already been created. Now
let's add some more methods.
I'll go back to the MainActivity class, and
now I'll add an onPause event. And
I'll copy and paste this log command, and
I'll change the message to reflect the method name. Then
I'll also add onStop, and I'll follow that same process, and I'll add two more. I'll
add the onDestroy method and the onRestart. I'll
save those changes and run the app again, and I'll clear theLogCat console and
come back to the app and do some more experiments. As
I did before, I'll leave the app by pressing
the back button, and I'll see three events
in a row, pause, stop and destroy.
And then when I restart the application, I get
create, start, and resume. I'll
clear my console and start over again. This
time I'll press the home button. I
get an onPause and an onStop, but not an onDestroy. And
then I'll come back to the app list, and restart, and I get a restart, a
start, and a resume. And
now let's see what happens when the
current activity opens a secondary activity. I'll
clear my console, and I'll click the button that opens the secondaryactivity,
and as I leave that activity, I get an onPause and an onStop.
And when I click the up button, that's the app
launcher, I come back to
the main activity, and I get a restart, a start, and an onResume. So
that tells us that from a lifecycle point of
view, the process of pressing the home button to
go to the home screen, and opening a secondary
activity of the same app are the same. The
main activity is kept in memory if the resources are available,
and when it returns to the screen it's just being re-presented.
It was never destroyed, so it doesn't have to
be recreated. I
encourage you
to experiment more with this sort of lifecycle debugging. Android
developers should have a thorough understanding of how
activities work in the application framework, including the
process through which they're created presented to the
user, activated and deactivated, hidden, and finally destroyed.
0 comments:
Post a Comment