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