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.
Overview of Android Local Inter-Process Communication (IPC) (Part 1)
Loading...
From the course by Vanderbilt University
Android App Components - Services, Local IPC, and Content Providers
121 ratings
From the lesson
Android Local Inter-Process Communication (IPC)
Learning objectives are presented in the Module Introduction video lecture.
Meet the Instructors
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 Part 2 of our lesson on Android's Local IPC Mechanisms,
where IPC stands for inter-process communication.
After completing this part of the lesson,
you'll understand the motivations for Android's local IPC mechanisms.
Which include overcoming limitations with the communication mechanisms we've covered
thus far, as well as enhancing Android's intra-process communication mechanisms.
Examples of intra-process communication include the HaMeR and
AsyncTask frameworks, as well as object sharing between threads.
You'll also be able to recognize how local IPC mechanisms can be applied in practice
by several image downloader case study apps,
that are available at the link at the bottom of this slide.
Let's start by giving a motivation for the Need for
Android Local IPC Mechanisms in the first place.
IPC mechanisms enable clients and servers to exchange data across address spaces.
These mechanisms are needed because apps running in separate processes can't
directly access each other's data, as described in Part 1 of our earlier lesson
on the Android Linux Kernel in the first module of this MOOC.
The Android Linux Kernel supports a range of IPC mechanisms, including internet and
Unix-domain sockets, as well as the binder driver as described in Part 2
of the earlier lesson on the Android Linux Kernel in Module 1.
In this module, in this introductory lesson we focus on the binder IPC
mechanisms that Android provides to enable communication between components.
Typically between activities and
services, though services can also communicate with each other as well.
The previous module showed how to send an intent from an activity to a service.
For example, the intent passed to the startService() method
is delivered to the service by the onStartCommand().
startService passes intents the same way, regardless of where the service resides.
In particular, the mechanism works the same whether or not the activity and
service are co-located in the same process, or
distributed in two separate processes.
However, this simple approach does not allow an extended conversation.
In particular, multiple intents can't be passed back and
forth between an activity and a service using the startService() method by itself.
The previous module also showed how to send an intent from a service
back to an activity.
For example, our earlier lesson on the case study for
the PingPongReceiverService App illustrated how to do this.
In particular, the intent passed to the sendBroadcast() method by the service
is delivered back to a broadcast receiver running in the activity.
However, this approach incurs the various security and
performance drawbacks with broadcast receivers that we discussed in an earlier
lesson on Android Broadcast Receiver Security in MOOC 2.
Moreover, the LocalBroadcastManager solution we also described in that
earlier MOOC does not work across process boundaries.
Android thus needs a broader range of local IPC mechanisms
to enable communication between components.
These mechanisms need to work consistently,
regardless of the deployment models.
In particular, they should work the same whether the activity and
service are configured into different processes, as shown here.
As well as when they're configured into the same process, as shown here.
Let's now give an example of applying local IPC mechanisms in practice.
We'll use a family of image downloader apps to showcase
the various Android local IPC mechanisms.
And you can download these examples here at the link at the bottom of this slide.
These examples work as follows.
A DownloadActivity is used to launch a DownloadService that
runs in its own address space.
The service can be launched in various ways,
as we discussed in the previous module on services.
Likewise, an activity can send a request to a service in various ways,
as we discuss in a moment briefly,
and then discuss in greater detail in Part 2 of this lesson.
Once the DownloadService receives the request from the DownloadActivity,
it goes ahead and retrieves the image, and stores it in a file on the device.
It does this by blocking on networking calls,
which it can do without affecting DownloadActivity because
the DownloadService is going to run in its own thread, or its own process.
In that thread or process, it can then go ahead and make various socket calls, or
HTTP request calls, to retrieve the content from the remote server.
A service can send a response to an activity in various ways
once it's received the content that it downloaded from the remote server.
We'll briefly outline some of those ways in just a moment,
and discuss them in more detail in Part 2 of this lesson.
Finally the image will go ahead, and the DownloadService will return the file
path to the DownloadActivity, which can then turn around and display the image.
In our particular examples, the DownloadActivity is actually going to use
an activity from the Gallery app that’s built into Android to display the image.
Part 2 of this lesson, show how the various Android local IPC mechanisms
outlined in this table on the slide,
can be applied in the context in the image downloader apps.
In particular, we’ll show how these components
can use IPC mechanisms to communicate to a started service from an activity,
as well as from a started service back the activity that originally contacted it.
It also turns out to be the case that components can use IPC mechanisms to
communicate to a bound service from an activity,
as well as from a bound service back to the activity they bound to it.
All the started service examples that we've discussed in this MOOC pass intents
from an activity to a service, so that use case is covered already.
Our primary focus in this module
is on messenger communication between activities and services.
Both from a started service back to the activity that contacted using a messenger,
as well as between bound services, where the client and
the server communicate using a pair of messengers.
The mobile cloud computing with Android specialization focuses on
Android Interface Definition Language communication between bound services,
which we'll touch on briefly, but won't cover in detail here.
MOOC 2 in this specialization, as well as a lesson from the previous module
in this MOOC which discussed the PingPongReceiverService app,
cover broadcasts from started services
back to the activities that originally contacted them.
The smaller red check boxes here are possible use cases,
although they're typically uncommon, and in some cases very improbable for
reasons we'll talk about shortly.
This concludes Part 1 of our overview of
Android's Local Inner Process Communication Mechanisms.
[MUSIC]
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2018 Coursera Inc. All rights reserved.
