This 4 week MOOC builds upon the core Android app components and concurrency frameworks covered in Course 2 by focusing on started and bound services, local inter-process communication (IPC), and content providers. Case study apps will be examined from multiple perspectives to learn how to program these app components using Android's material design paradigm. Students will work incrementally on a hands-on project involving a material design-based RSS reader app. Each week you will add additional capabilities to the project, based on material covered in the lecture videos. You'll spend roughly 4 hours per week watching video lectures, taking quizzes, and programming assignments with Java and Android.
Case Study: PingPongReceiverService App
Loading...
来自 Vanderbilt University 的课程
Android App Components - Services, Local IPC, and Content Providers
136 个评分
从本节课中
Android Started and Bound Services
Learning objectives are presented in the Module Introduction video lecture.
与讲师见面
Dr. Douglas C. SchmidtProfessor of Computer Science and Associate Chair of the Computer Science and Engineering Program
Electrical Engineering and Computer Science
[MUSIC]
Welcome to our next lesson in the module on Android Services.
Which presents a case study of the ping pong receiver service app.
After completing this lesson,
you'll know the run time behavior of the PingPongReceiverService app.
You recognize the design of the PingPongReceiverService app.
You will also understand the implementation of
the PingPongReceiverService app, which is available at this URL.
First we'll show the PingPongReceiverService app in action,
starting by giving a high level of overview with a couple of screen shots.
And then actually executing the app inside the Android Studio empire.
This app has the same look and feel as the ping pong receiver apps for
module five in book two.
In particular, it props the user for
a number of times to play ping pong and then it goes ahead and
sends intents back and forth between a ping receiver and a pong service.
The PongService runs in the same process as the PingReceiver.
We're now inside the Android Studio emulator, where I'll go ahead and
launch the PingPongReceiverService app.
You can see as it comes up it logs the various
hook methods the activity calls You come over here.
Click on the floating action button, and it prompts us for
the number of times we want to play ping pong.
So, let's give a nice big number.
Let's say we want to run this ten times.
Click OK.
Then let's click the play button, which is another floating action button.
You can see it's up here playing ping pong.
If we pull down the notification status bar,
you can see up here it's going back and forth, ping, pong, ping, pong.
And what's happening here, of course, is that the ping receiver is sending
a start service request to the pong surface,
which then is sending back the request to the ping receiver.
Okay, so that's just a quick way to look at the operation of the program.
You can see here all the various logging operations that are taking place
between the pong service and the ping receiver.
Now that we've shown how the PingPongReceiverService app runs,
we'll talk about its design.
This program plays ping pong by passing intents between a dynamically
registered broadcast receiver and a started intent service.
As always the lifecycle logging activity is used to define a common superclass for
the logging lifecycle operations.
The main activity provides the user interface that prompts the user for
account and initiates the ping/pong interactions.
The PingReceiver is a broadcast receiver that handles ping intents and
starts a service by applying intents.
And the PongService is an intent service that handles pong intents and
broadcasts ping intents.
Let's now go ahead and take a look through the source code
of the PingPongReceiverService app which you can download at this link.
Here we are inside the Android Studio project file for
the PingPongReceiverService app.
Let's start by taking a quick look at the Android manifest file as you can see,
it finds an application that has an activity and the service.
Here's the activity implementation location that's in the .activities
MainActivity file as we can see here.
And then down here, we have the service which is called the PongService which
is in the service folder.
So that's how things are laid out.
As you can see here, we aren't exposing the palm service nor
are we running it in a separate process.
Let's go take a look at main activity.
Main activity extends life cycle logging activity as always.
This activity's going to prompt the user for the count and then play the ping pong
by passing intense back and forth between the started service and
the broadcast receiver that's registered dynamically.
We have a number of fields.
We have our edit text field that keeps track of the number of accounts
the user wants to play.
Whether or not the edit text is visible or not.
A couple of floating action buttons used to set account as well or start or
stop the game.
We keep a notification ID which is used by the status bar notification service
in order to update the status notification when pings and pongs are playing.
We have our ping receiver, which is a dynamically registered broadcast receiver
that handles the the ping intense.
We'll see how that works in a second.
And now we've got a bunch of methods, starting with the entry point method,
the virtual constructor on Create.
Nothing really exciting going on here.
We call up to the super class.
Layout the content view.
And initialize the views.
Once again, nothing really super exciting going on in the initialized views.
Its essentially grabbing the edit text and the various floating action buttons and
setting fields to be visible or invisible.
Starts with them being invisible, as you can see here.
And then we set ourselves with a listener that's going to display the start
playing coding action button when the user hits the enter key or clicks enter.
Let's now go take a look at on pause.
This is the hook method that's called when the activity is about to lose focus.
And as you can see here what it's going to do after calling it super class
is it's going to check to see whether or not we have a ping receiver registered.
And if we do we're going to unregister the ping receiver and
we're going to update the status bar to indicate this particular game is now idle.
Here's the on resume method.
This gets called when they application is coming back into focus or
if it's being launched the first time.
Here we check to see whether or not we've already got a receiver.
If not we're going to call a method called registerPingReceiver down here
which will go ahead and register the receiver dynamically.
And then we're going to ahead and resume the game from the last known iteration.
And you can see how this works.
We're calling.
The ping receivers on receive hook method explicitly passing in a ping intent.
It's going to pick up from wherever we left off last time
which could be starting with zero if this is the first time in.
Let's now go down here and take a look at register receiver,
the register ping receiver creates a new intent filter which say we're
a dynamic intent and we know how to handle the action view ping intent.
And then we go ahead and
register this ping receiver that we've just made earlier with the intent filter.
So that will have received those particular intents.
Here's the start or stop playing method.
This gets called back when the user clicks on the floating action button.
As you can see here, if we have got ourselves a non-null receiver.
Then we're going to go ahead and stop playing.
Otherwise, we're going to go ahead and get the count that the user gave, or
whatever the default might be.
And if the user gave account is less than zero, we're going to throw up an error.
Otherwise, we're going to start playing the game.
So let's see what happens when we start playing the game.
First thing we do is we hide the keyboard.
We then make ourselves a new ping receiver, which is going to be used in
the onResume hook method we looked at a few minutes ago.
Come up here, you can see where the ping receiver's being used right there.
This down here, is where we actually allocate that ping receiver.
We then dynamically register it.
And then we go ahead and
call the onReceive method, indicating this is the first time in.
So we're going to go ahead and give it a count of one.
And then we're going to toggle the floating action button to indicate
that the user can stop it if they don't want to play the game anymore.
Here is the stop playing button, this is what gets called back if the user
clicks on the floating action button when it's in stop mode.
As you can see we unregister the receiver.
Null out the ping receiver, to indicate it's no longer in use, and
then we go ahead and cancel the status bar notification and
toggle back the floating action button to the play icon.
And the last method we have in the activity is basically set count, and
what set count is used to do is to get the count that the user has indicated.
So that will either make the edit text visible or invisible,
depending on what mode it was in.
Okay, so that's basically the main activity.
Let's now go over here and look at the ping receiver.
This looks very much like the one we had done in moot two,
in module five on broadcast receivers.
This is a dynamically registered broadcastReceiver that handles
ping intents.
You can see here is the action that it knows how to handle.
This is the ACTION_VIEW_PING that we define here.
And we have ourselves a little title bar that we're going to use for
the status bar, status notification bar.
We're going to store some extra key strings in tense that we're
going to fish out and use later.
We'll keep track of the maximum number of times to play Ping Pong.
We'll keep track of the current iteration,
which allows us to be able to resume a paused game.
We track of our enclosing activities, so
we can call it back when we're all done playing Ping Pong.
Here's the constructor for the Ping receiver.
We stashed the main activity away along with the max count.
Here's the make ping intent factory method that takes in a context account and
a notification IP.
Let's go ahead and take a look and see what that does.
That makes a new intent which is an action view ping intent.
It goes ahead and adds the count and the notification IDs as extras and
it limits the receiver to components in this app package for extra security.
We talked about that in the previous MOOC as well.
Here is the ad hoc receive method,
this is what really does all the heavy lifting for the ping receiver.
This goes ahead and extracts the count from the extra field as
an INT inside the ping intent which it's going to stash away in a couple of places.
We're then going to go ahead and create a notification ID
using the notification ID that was stashed away in the intent.
and then assuming we are done, then we're going to
tell the status bar we're finished, and we're going to stop playing.
So in that particular case, we're going to go ahead and send a stop
service call to the pong service telling it to go ahead and
shut down because we're not going to need it anymore.
And then we inform the activity that we've stopped playing.
We call the stop playing method directly.
That's why we had to stash that reference earlier.
If we're not done playing we're going to update the status bar.
And then we're going to go ahead and make a pong intent and
this pong intent would be used in order to start a service.
And that start service will then go ahead and
run in the background as we'll see in a second.
So the makePongIntent is a factor method defined by Pong Services we'll see here
and that's going to be used to go ahead and start the service And here's
the method we used to get back the current iteration, which we use as a starting
point for resuming a game that was paused, when the application was paused.
All right, let's now go over to PongService, Here's PongService.
PongService extends IntentService so
it's going to have a thread that runs in the background.
And it defines title for the status bar called Pong and
it also defines a couple of strings that uses as keys.
You put a little delay in here so that's easier to see what the status
bar is doing, if you go back and watch the video up
running to see that it pauses line after actually is tell what's going on.
We have to make ourselves a constructor that
calls up to the IntentServices constructor given
in the name of the service which in this case the PongService.
Here's the make pom intent method.
It's very similar to the one we used for making a ping intent,
except you don't have to worry about limiting the package.
So this goes ahead and makes an explicit intent with the pom service class.
That's the Java Class File.
And we add in the extras account, and the notification ID.
And here at long last is really the work course of this service,
which is the on handle intent method.
Which as you may recall gets called back in a background thread because this is
using the intent service.
It gets the count from the intent,
stashes it away, we get the notification id from the intent, stashes that away.
We then go ahead and sleep for
a thousand milliseconds just to give it a little bit of a delay and
then we go ahead and update the status bar to indicate we've been ponged.
[INAUDIBLE] Again just a little bit.
And the last thing we do as we leave this service
is we send a broadcast back to the dynamically registered broadcast receiver.
And of course send broadcast takes an intent which is returned from
the PingReceiver.makePingIntent factory method.
And that's going to take the count that we were passed here.
And add one to it, and then go ahead and make an intent, that count plus one, and
the notification ID.
And that will then come back to the registered broadcast receiver inside
of the main activity in order to keep the ping pong operations going back and forth.
So that's basically a walk-through of all the source code.
That concludes our case study of the PingPongReceiverService app.
[MUSIC]
