The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
One of the more popular stores of data on your average Android device is the contact list. Ever since Android 2.0, Android tracks contacts across multiple different “accounts”, or sources of contacts. Some may come from your Google account, while others might come from Exchange or other services.
This chapter will walk you through some of the basics for accessing
the contacts on the device. Along the way, we will revisit and expand
upon our knowledge of using a
First, we will review the contacts APIs, past and present. We will then demonstrate how you can connect to the contacts engine to let users pick and view contacts… all without your application needing to know much of how contacts work. We will then show how you can query the contacts provider to obtain contacts and some of their details, like email addresses and phone numbers. We wrap by showing how you can invoke a built-in activity to let the user add a new contact, possibly including some data supplied by your application.
In addition, we will take a peek at the
CallLog provider, which, as the
name suggests, gives you access to a log of calls made on the device.
Understanding this chapter requires that you have read these chapters in addition to the core chapters:
Android makes contacts available to you via a complex
ContentProvider framework, so you can access many facets of a
contact’s data — not just their name, but addresses, phone
numbers, groups, etc. Working with the contacts
is simple… only if you have an established pattern to work with.
Otherwise, it may prove somewhat daunting.
ContentProvider framework can be found as the set of
ContactsContract classes and interfaces in the
package. Unfortunately, there is a dizzying array of inner classes to
Contacts can be broken down into two types: raw and aggregate. Raw
contacts come from a sync provider or are hand-entered by a user.
Aggregate contacts represent the sum of information about an
individual culled from various raw contacts. For example, if your
Exchange sync provider has a contact with an email address of
firstname.lastname@example.org, and your Facebook sync provider has a contact with an
email address of
email@example.com, Android may recognize that those two
raw contacts represent the same person and therefore combine those in
the aggregate contact for the user. The classes relating to raw
contacts usually have
Raw somewhere in their name, and these
normally would be used only by custom sync providers.
represent the “entry points” for the
ContentProvider, allowing you
to query and obtain information on a wide range of different pieces
of information. What is retrievable from these can be found in the
ContactsContract.CommonDataKinds series of classes. We will
see examples of these operations later in this chapter.
Prior to Android 2.0, Android had no contact synchronization built
in. As a result, all contacts were in one large pool, whether they
were hand-entered by users or were added via third-party
applications. The API used for this is the
ContentProvider still works, as
it is merely deprecated in Android 2.0.1, not removed. In practice,
it has one big limitation: it will only report contacts added directly
to the device (as opposed to ones synchronized from Microsoft Exchange,
Facebook, or other sources). As a result, modern Android apps should
not be using
Contacts in general — use
The preview of this section was abducted by space aliens.
The preview of this section was lost due to a rupture in the space-time continuum.
The preview of this section is in the process of being translated from its native Klingon.
The preview of this section apparently resembled a Pokémon.