Learning Android

Chapter 4. Main Building Blocks

In this chapter, you will learn about the big blocks in Android. We’ll give you a high-level overview of what activities are, how intents work, why services are cool, how to use broadcast receivers and content providers to make your app scale, and much more.

By the end of this chapter, you will understand the main Android components for building applications. You should conceptually know when you’d use what component. You will also see how these components relate to a real-world application.

What Are Main Building Blocks?

The main building blocks are components that you use as an application developer to build Android apps. They are the conceptual items that you put together to create a bigger whole. When you start thinking about your application, it is good to take a top-down approach. You design your application in terms of screens, features, and the interactions between them. You start with conceptual drawing, something that you can represent in terms of “lines and circles.” This approach to application development helps you see the big picture—how the components fit together and how it all makes sense.

A Real-World Example

Let’s say that we want to build a Twitter app. We know that the user should be able to post status updates. We also know the user should be able to see what her friends are up to. Those are basic features. Beyond that, the user should also be able to set her username and password in order to log into her Twitter account. So, now we know we should have these three screens.

Next, we would like this app to work quickly regardless of the network connection or lack thereof. To achieve that, the app has to pull the data from Twitter when it’s online and cache the data locally. That will require a service that runs in the background as well as a database.

We also know that we’d like this background service to be started when the device is initially turned on, so by the time the user first uses the app, there’s already up-to-date information on her friends.

So, these are some straightforward requirements. Android building blocks make it easy to break them down into conceptual units so that you can work on them independently, and then easily put them together into a complete package.

Activities

An activity is usually a single screen that the user sees on the device at one time. An application typically has multiple activities, and the user flips back and forth among them. As such, activities are the most visible part of your application.

I usually use a website as an analogy for activities. Just like a website consists of multiple pages, so does an Android application consist of multiple activities. Just like a website has a “home page,” an Android app has a “main” activity, usually the one that is shown first when you launch the application. And just like a website has to provide some sort of navigation among various pages, an Android app should do the same.

On the Web, you can jump from a page on one website to a page on another. Similarly, in Android, you could be looking at an activity of one application, but shortly after you could start another activity in a completely separate application. For example, if you are in your Contacts app and you choose to text a friend, you’d be launching the activity to compose a text message in the Messaging application.

Activity Life Cycle

Launching an activity can be quite expensive. It may involve creating a new Linux process, allocating memory for all the UI objects, inflating all the objects from XML layouts, and setting up the whole screen. Since we’re doing a lot of work to launch an activity, it would be a waste to just toss it out once the user leaves that screen. To avoid this waste, the activity life cycle is managed via Activity Manager.

Activity Manager is responsible for creating, destroying, and managing activities. For example, when the user starts an application for the first time, the Activity Manager will create its activity and put it onto the screen. Later, when the user switches screens, the Activity Manager will move that previous activity to a holding place. This way, if the user wants to go back to an older activity, it can be started more quickly. Older activities that the user hasn’t used in a while will be destroyed in order to free more space for the currently active one. This mechanism is designed to help improve the speed of the user interface and thus improve the overall user experience.

Programming for Android is conceptually different than programming for some other environments. In Android, you find yourself responding more to certain changes in the state of your application rather than driving that change yourself. It is a managed, container-based environment similar to programming for Java applets or servlets. So, when it comes to an activity life cycle, you don’t get to say what state the activity is in, but you have plenty of opportunity to say what happens during the transitions from state to state. Figure 4-1 shows the states that an activity can go through.

Figure 4-1. Activity life cycle

Starting state

When an activity doesn’t exist in memory, it is in a starting state. While it’s starting up, the activity will go through a whole set of callback methods that you as a developer have an opportunity to fill out. Eventually, the activity will be in a running state.

Keep in mind that this transition from starting state to running state is one of the most expensive operations in terms of computing time, and this also directly affects the battery life of the device. This is the exact reason why we don’t automatically destroy activities that are no longer shown. The user might want to come back to them, so we keep them around for a while.

Running state

The activity in a running state is the one that is currently on the screen and interacting with the user. We also say this activity is in focus, meaning that all user interactions—such as typing, touching the screen, and clicking buttons—are handled by this one activity. As such, there is only one running activity at any given time.

The running activity is the one that has priority in terms of getting the memory and resources it needs to run as quickly as possible. This is because Android wants to make sure the running activity is zippy and responsive to the user.

Paused state

When an activity is not in focus (i.e., not interacting with the user) but still visible on the screen, we say it’s in a paused state. This is not a typical scenario, because the device’s screen is usually small, and an activity is either taking up the whole screen or none at all. We often see this case with dialog boxes that come up in front of an activity, causing it to become Paused. All activities go through a paused state en route to being stopped.

Paused activities still have high priority in terms of getting memory and other resources. This is because they are visible and cannot be removed from the screen without making it look very strange to the user.

Stopped state

When an activity is not visible, but still in memory, we say it’s in a stopped state. Stopped activity could be brought back to the front to become a Running activity again. Or, it could be destroyed and removed from memory.

The system keeps activities around in a stopped state because it is likely that the user will still want to get back to those activities some time soon, and restarting a stopped activity is far cheaper than starting an activity from scratch. That is because we already have all the objects loaded in memory and simply have to bring it all up to the foreground.

Stopped activities can be removed from memory at any point.

Destroyed state

A destroyed activity is no longer in memory. The Activity Manager decided that this activity is no longer needed and has removed it. Before the activity is destroyed, it can perform certain actions, such as save any unsaved information. However, there’s no guarantee that your activity will be stopped prior to being destroyed. It is possible for a paused activity to be destroyed as well. For that reason, it is better to do important work, such as saving unsaved data, en route to a paused state rather than a destroyed state.

Note

The fact that an activity is in a running state doesn’t mean it’s doing much. It could be just sitting there and waiting for user input. Similarly, an activity in a stopped state is not necessarily doing nothing. The state names mostly refer to how active the activity is with respect to user input, in other words, whether an activity is visible, in focus, or not visible at all.

Intents

Intents are messages that are sent among the major building blocks. They trigger an activity to start up, tell a service to start or stop, or are simply broadcasts. Intents are asynchronous, meaning the code that sends them doesn’t have to wait for them to be completed.

An intent could be explicit or implicit. In an explicit intent, the sender clearly spells out which specific component should be on the receiving end. In an implicit intent, the sender specifies the type of receiver. For example, your activity could send an intent saying it simply wants someone to open up a web page. In that case, any application that is capable of opening a web page could “compete” to complete this action.

When you have competing applications, the system will ask you which one you’d like to use to complete a given action. You can also set an app as the default. This mechanism works very similarly to your desktop environment, for example, when you downloaded Firefox or Chrome to replace your default Internet Explorer or Safari web browsers.

This type of messaging allows the user to replace any app on the system with a custom one. For example, you might want to download a different SMS application or another browser to replace your existing ones. Figure 4-2 shows how intents may be used to “jump” between various activities, in the same application or in another app altogether.

Figure 4-2. Intents

Services

Services run in the background and don’t have any user interface components. They can perform the same actions as activities, but without any user interface. Services are useful for actions that we want to perform for a while, regardless of what is on the screen. For example, you might want your music player to play music even as you are flipping between other applications.

Note

Don’t confuse the Android services that are part of an Android app with native Linux services, servers, or daemons, which are a much lower-level component of the operating system.

Services have a much simpler life cycle than activities (see Figure 4-3). You either start a service or stop it. Also, the service life cycle is more or less controlled by the developer, and not so much by the system. Consequently, we as developers have to be mindful to run our services so that they don’t consume shared resources unnecessarily, such as the CPU and battery.

Figure 4-3. Service life cycle

Note

The fact that a service runs in the background doesn’t mean it runs on a separate thread. If a service is doing some processing that takes a while to complete (such as performing network calls), you would typically run it on a separate thread. Otherwise, your user interface will run noticeably slower. In other words, services and activities run on the same main application thread, often called the UI thread.

Content Providers

Content providers are interfaces for sharing data between applications. By default, Android runs each application in its own sandbox so that all data that belongs to an application is totally isolated from other applications on the system. Although small amounts of data can be passed between applications via intents, content providers are much better suited for sharing persistent data between possibly large datasets. As such, the content provider API nicely adheres to the CRUD principle. Figure 4-4 illustrates how the content provider’s CRUD interface pierces the application boundaries and allows other apps to connect to it to share data.

Figure 4-4. Content provider

The Android system uses this mechanism all the time. For example, Contacts Provider is a content provider that exposes all user contact data to various applications. Settings Provider exposes system settings to various applications, including the built-in Settings application. Media Store is responsible for storing and sharing various media, such as photos and music, across various applications. Figure 4-5 illustrates how the Contacts app uses Contacts Provider, a totally separate application, to retrieve data about users’ contacts. The Contacts app itself doesn’t have any contacts data, and Contacts Provider doesn’t have any user interface.

Figure 4-5. Contacts application using Contacts Provider to get the data

This separation of data storage and the actual user interface application offers greater flexibility to mash up various parts of the system. For example, a user could install an alternative address book application that uses the same data as the default Contacts app. Or, he could install widgets on the Home screen that allow for easy changes in the System Settings, such as turning on or off the WiFi, Bluetooth, or GPS features. Many phone manufactures take advantage of content providers to add their own applications on top of standard Android to improve overall user experience, such as HTC Sense.

Content providers are relatively simple interfaces, with the standard insert(), update(), delete(), and query() methods. These methods look a lot like standard database methods, so it is relatively easy to implement a content provider as a proxy to the database. Having said that, you are much more likely to use content providers than write your own.

Broadcast Receivers

Broadcast receivers are Android’s implementation of a system-wide publish/subscribe mechanism, or more precisely, an Observer pattern. The receiver is simply dormant code that gets activated once an event to which it is subscribed happens.

The system itself broadcasts events all the time. For example, when an SMS arrives, a call comes in, the battery runs low, or the system gets booted, all those events are broadcasted, and any number of receivers could be triggered by them.

In our Twitter app example, we want to start the update service once the system starts up. To do that, we can subscribe to the broadcast that tells us the system has completed booting up.

You can also send your own broadcasts from one part of your application to another, or to a totally different application.

Broadcast receivers themselves do not have any visual representation, nor are they actively running in memory. But when triggered, they get to execute some code, such as starting an activity, a service, or something else.

Application Context

So far you have seen activities, services, content providers, and broadcast receivers. Together, they make up an application. Another way of saying this is that they live inside the same application context.

Application context refers to the application environment and the process within which all its components are running. It allows applications to share the data and resources between various building blocks.

An application context gets created whenever the first component of this application is started up, regardless of whether that component is an activity, service, or something else. Application context lives as long as your application is alive. As such, it is independent of the activities life cycle. You can easily obtain a reference to the context by calling Context.getApplicationContext() or Activity.getApplication(). Keep in mind that activities and services are already subclasses of context, and as such they inherit all its methods.

Summary

In this chapter, you learned about some of the most important Android application components. We put together these components to create various applications, from a simple Hello World to much more complex creations.

In the next chapter, we’ll outline a Yamba application as an example of how all these bits and pieces come together to form a working Android app.