Application Components In Android

What Are Main Building Blocks?

A Real-World Example

Activities

Activity Life Cycle

Intents

Services

Content Providers

Broadcast Receivers

Application Context

  

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.

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

 

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.

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.

 

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 runit 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 illustrate show the content provider’s CRUD interface pierces the application boundaries and allows other apps to connect to it to share data.

 

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.

              

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

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.