Explore
For Enterprise
Join for Free
Log In

艺术与人文
商务
计算机科学
数据科学
信息技术
健康
数学和逻辑
个人发展
物理科学与工程
社会科学
语言学习
学位
证书

浏览 Coursera 的全部课程

浏览
搜索
企业版
登录
免费加入

The Activity Class - Part 1

Loading...

Android 手持系统的移动应用程序设计：第 1 部分

马里兰大学帕克分校

4.6（573 个评分） | 59K 名学生已注册

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.

查看授课大纲

您将学习的技能

Android Studio, Android (Operating System) Software, Android Software Development, User Interface

审阅

4.6（573 个评分）

5 stars
430 ratings
4 stars
101 ratings
3 stars
23 ratings
2 stars
9 ratings
1 star
10 ratings

EG

Jun 02, 2016

Very good courser, not for beginners certainly. Funny videos and easy to understand and gives you asignments that let you think about it and research so you understand better the assignments

AZ

Jan 21, 2018

I think this is the most helpful course that I have taken until now. I am not that perfect at Java but this course makes me understanding both Java and Android.\n\nThanks a lot.

从本节课中

Application Fundamentals and the Activity Class

Application Fundamentals - Part 115:27

Application Fundamentals - Part 211:17

The Activity Class - Part 114:07

The Activity Class - Part 214:35

Introduction to Amazon Guest Lecture - AppStores and Free Ebook2:25

Introduction to Amazon Guest Lecture - App Monetization0:52

Preview - Programming Mobile Services for Android Handheld Systems2:18

教学方

Dr. Adam Porter
Professor

脚本

[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.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2019 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取

Coursera
关于
管理团队
工作机会
目录
证书
MasterTrack™ 证书
学位
企业版
政府版

社区
Learners
Partners
Developers
Beta Testers
Translators

连接
博客
Facebook
领英
Twitter
Instagram
YouTube
技术博客

更多
条款
隐私
帮助
内容访问
媒体
联系我们
目录
附属公司