Developing with Google Android

In articles and videos about Android that Google released on YouTube, users have likely heard the word “intent,” such as in phrases like “broadcast an intent.” However, like me, not everyone totally got the gist of this, as the descriptions were geared toward end users rather than developers.

Essentially, intents are a common way to categorize what applications typically do. A contact application will allow a developer to view a list of contacts and select one, edit a contact, add a new contact and so on. Google has predefined these types of processes with words like VIEW for the viewing of a contact, PICK for the selection of a contact and EDIT for the editing of a contact.

The whole intention of intents (sorry) is to facilitate late binding. Look at it this way: One person could create an application (call it Application A) that can make use of features in other applications. Later, somebody could create an application that provides such a feature. Call this second application Application B. When Application A was developed, the programmers couldn’t have known about Application B. While the developers of A could create their own careful specification by which future developers providing a feature must adhere to—meaning future developers must link their code into the first application—Google engineers have found a simpler method.

Instead of statically linking code together, they allow for a message system that accomplishes late binding. This message system is the Intent class and its associated classes.

Applications can then publish their intents to the entire system. This is where the cool part happens. As I said in a previous article about Android, you can replace standard applications (such as a phone or contact application) with a custom app. That way, if a programmer doesn’t like the built-in phone software, they can use a better one someone else wrote. That replacement app would advertise its intentions. Then, if they have yet another program that launches the phone dialer, instead of launching the built-in dialer, it would launch the replacement app. The app doing the launching could send data to the replacement dialer; the developer can see then how late-binding factors in here.

When an application provides intentions, it can respond to various events that aren’t necessarily triggered by a human. For example, a user might write a special program that needs to respond when the phone rings. (Speaking off the top of my head, I can’t think of a good example of such a program, but I’m sure others can come up with some interesting ideas here.) One nice thing here is that your program doesn’t have to already be running; because it has broadcast an intent, the operating system will launch the program in response to the event.