This course introduces you to the design and implementation of Android applications for mobile devices. You will develop an app from scratch, assuming a basic knowledge of Java, and learn how to set up Android Studio, work with various Activities and create simple user interfaces to make your apps run smoothly.
The Activity Class - Part 1
Loading...
來自 University of Maryland, College Park 的課程
Programming Mobile Applications for Android Handheld Systems: Part 1
539 個評分
University of Maryland, College Park
539 個評分
從本節課中
Application Fundamentals and the Activity Class
與講師見面
Dr. Adam PorterProfessor
Computer Science
[MUSIC]
In our last lesson we talked about the four fundamental components of
Android applications.
And they were activities, services, broadcast receivers and content providers.
Today we're going to take a deeper look at one of those components,
the activity class.
I'll start by presenting the activity class itself.
Next I'll discuss Androids Task Backstack which helps you to
easily navigate back and forth among the activities they use.
After that, I'll discuss the lifecycle of activities.
How they're created, executed, and terminated, and how Android manages and
communicates these lifecycle phases and changes to your applications.
After that, I'll discuss the APIs and
patterns that you'll need to programmatically start activities.
And finally, I'll finish up with a, with a discussion of
how Android activities handle device and application configuration changes.
As I said before, activities are the primary class for interacting with users.
They're designed to provide a visual interface through which the user can
interact with the application.
And by convention, activities should be modular, in the sense that, each activity
should support a single focused thing that the user can do with your application.
And individual things like viewing an email message or showing a log in screen.
And if you follow this convention, then you end up creating applications by
stringing together multiple activities, each with a single purpose.
That the user then navigates through, and
Android helps users do this navigation in a couple of ways.
By supporting the concept of tasks, by providing a task back stack for
managing the specific activities through which the user is navigating, and
by ensuring that activities are properly suspended and
resumed as they're pushed on and popped off the task back stack.
In Android, a task is simply a set of related activities.
These related activities can, but don't have to be part of the same application.
So tasks can span multiple applications, and most tasks start at the home screen.
So when a user launches an application from the home screen,
a new task is normally started.
And when the user hits the home button, to return back to the home screen.
The current task is it, is at least temporarily closed.
The task backstack works as follows.
When an activity is launched,
it's pushed on to the task backstack, normally as part of the current task.
When that activity is later destroyed, for example because the user hit
the back button, because the activity terminated itself programmatically, or
even because Android itself has decided to kill that activity in order to
reap its resources and the activity is popped off the task back stack.
Let's take a look at how this process works.
Now this graphic represents an activity that's running on a device.
And it picks the state of the task backstack while the application
is running.
The black pointer at the bottom indicates the current snapshot.
Now in this application, this first launch, it starts up Activity 1, which
is then pushed on to the top of the task backstack as the root of the current task.
Now, as you can see,
activity one has a single button, labeled, start activity two.
So the idea here, is that,
if the user presses this button, activity two will start.
So let's say, now, that the user presses the Activity 2 button.
At this point, Activity 1 is suspended and it's state will be captured so
that it can be restored later if the user returns back to it.
Next, Activity 2 begins and Activity 2 is pushed on to the task backstack.
Now similar to Activity 1, Activity 2 has a single button labeled Start Activity 3.
If a user presses this button, activity 3 will start.
So let's say that the user now presses the Start Activity 3 button.
At this point activity 2 will be suspended, activity 3 will begin, and
activity 3 will be pushed onto the task backstack.
Now let's say that the user has had enough of Activity 3 and
hits the Back button with the idea of going back to Activity 2.
At this point, Android kills Activity 3 and pops it off the task backstack.
Now because Activity 2 is currently at the top of the task backstack,
Android will unsuspend or resume that activity, restoring its state and
bringing it back in to view on the device.
Now as we saw with the task backstack examples, Android activities come and
go and come again and go away for good.
They have a life cycle.
And importantly, for
you as a developer, your applications are not really in control of this lifecycle.
Some lifecycle changes, for example, depend on choices that the user makes.
Like pressing the Back button or the Home button.
Other lifecycle changes depend on Android itself.
For example, if your device is running low on memory Android can decide to
kill activities that are currently suspended.
And it will do that knowing that it will need to recreate them later if the user
navigates back to them.
So let's talk a bit more about the activity lifecycle and
the particular lifecycle changes that activities go through.
For example, once an activity is started, it can be in a resumed or running state.
And while it's in this state,
the activity is visible and the user can interact with it.
An activity can also be paused, for instance,
when a new activity starts to pop up in front of it.
In this situation the activity may still be partially visible but
the user can't interact with it because the user will be
interacting with a new activity that's starting up.
Prior to version 3.0,
Android could terminate activities once they went in to the paused state.
Now finally, the activity can be stopped.
And when it stopped, that activity is no longer visible.
And Android is free to terminate.
And this is important to reiterate.
It can terminate stopped activities.
And it does so knowing that it might need to recreate them later,
if the users navigate back to them.
Now your activities will often need to behave differently during
different parts of their life cycle.
For instance, if your activity is showing an animation,
then pops up a partially transparent dialog style activity in front of it,
well you might want to pause the animation while the user response to the dialog and
then restart the animation once that dialog activity finishes.
In order to support scenarios like this, Android announces lifecycle changes
to activity by calling specific lifecycle, or template, methods.
And some of these methods are shown here.
Each is named, as you can see, on something or another, on create when
the activity is about to be created, on start when the activity is about to
become visible, all the way to onDestroy, when the activity's about to be destroyed.
And if you want to take some specific action when your activity changes state,
then you need to override one or more of these methods in your activity.
So, let's take a look at
how these different methods interrelate with each other.
Now, this graphic depicts the orders in which activity lifecycle methods
can be called.
And the important thing to remember here
is that Android applications don't work completely by themselves.
Instead there's a clear back and
forth collaboration between your application and Android.
And you have to understand the rules of this collaboration if you
want your Android applications to function properly.
So let's imagine a simple application with one activity that starts up,
waits for a moment, and then exits.
In this simple case when that application is launched,
Android will call the activity's onCreate method.
Then Android will call its onStart method.
And then onResume.
After which the activity's user interface will appear on the device's screen.
And the user can interact with it.
After a minute of so, our example activity will begin to shut down.
And at this point, Android will call that activity's onPause method.
Then, onStop and then, finally, onDestroy.
And at this point the activity is completely dead.
So as you can see the entire lifetime of the activity runs from the start of
onCreate to the end of onDestroy.
Now when this simple activity started, it wasn't visible on the screen.
At some point, it became visible, and at some point later,
it became invisible as it was removed from the screen.
When activities are about to become visible, Android calls the on start, and
sometimes, the on restart method.
When activities are about to become invisible,
Android calls the onStop method.
And so, you can think of the visible lifetime of an activity as occurring
between the startup calls to onStart and the end of calls to onStop.
And, finally, while an activity is visible on the screen, there are times
when the user can interact with it, and there are times when he or she can't.
And for example, this can happen when a device goes to sleep.
In that case, the user can't interact with the activity anymore,
even though it still is the foreground activity.
So when activities are about to be ready for
user interaction, Android calls the onResume method.
When activities are about to stop being able to interact with the user,
Android calls the onPause method.
And so, you can think of the visible and in foreground lifetime of an activity
as occurring between the start of calls to onResume, and the end of calls to onPause.
Let's walk through an example of this based on the map location
application that we saw in earlier lessons.
First the user goes to the home screen, and launches the map location application.
This causes the map location activity to start up.
At which point Android calls map locations onCreate method.
onCreate initializes the activity and then Android continues by calling on start.
And at this point map location is visible but not yet ready for user interaction.
Android now calls onResume.
After onResume completes an application will soon be both visible and
ready for user interaction.
And at this point the user will normally enter an address in the address box.
Once the address has been entered,
the user will normally press the Show Map button which will launch Google maps.
Now, as Google Maps starts up, it will have its own initial activity
that will go through its own life cycle, and receive its own life cycle callbacks.
But let's continue looking at what's going on with the map location activity.
Now because Google maps is about to come into the foreground and
cover up map location, the map location activity will first receive a call to its
on pause method, and soon after this, map location will no longer be visible.
And Android will call its onStop method.
Now eventually Google Maps will appear on the screen and
the user can interact with it.
But at some point the user will be done with Google Maps and might, for example,
choose to return back to map location.
For instance, to map a new address.
So let's assume that the user now hits the Back button to return back to
map location.
At this point, map location must be brought back into the foreground.
So as Android does this, it will first call onRestart and
then onStart, and soon after this map location will again be visible.
Next, Android will call map locations onResume method.
Soon after which the map location activity will be both visible and ready for
user interaction.
And finally when the user eventually loses interest in map location, he or
she might hit the back button again, in this case to end the application.
At this point,
Android will again go through the process of removing map location from the screen.
It will first call onPause, then onStop, and then this time it
will call onDestroy, before completely terminating the application.
