On Thu, Jan 12, 2012 at 9:19 PM, A. Elk <[email protected]> wrote: > I think that the interface (and its documentation) is complex because the > provider is designed to handle a large number of current and future > situations.
Definitely! > > There's more than one email row for a raw contact because a contact can > obviously have multiple email addresses. All of the emails, addresses, and > phone#s are stored in one table because of expandability: adding a new type > of detail record doesn't require another table. Different types of rows > (email versus postal address, etc.) are distinguished by their MIME_TYPE > column, so adding a new type of data simply means adding a new MIME_TYPE. > Notice that anyone can add their own type of data, though there's no > guarantee that anybody else will be able to use it. > > There's multiple raw contacts attached to a single contact to provide much > more flexibility than other contacts systems you may be familiar with. Each > source of contacts information (Google Contacts, Microsoft Exchange, Yahoo > Mail, Twitter, Facebook, etc.) can put its own "version" of a contact into > the Contacts Provider. They don't overwrite each other, and yet the > "contacts" row aggregates them so that you can find them easily. It's not > obvious, but the Contacts Provider assumes that most contact information is > synchronized with an external system. You may get your contacts from Google > Contacts, or you may enter them on your device and send them somewhere, but > it's rare that you don't use something on the cloud as well as Android for > contacts. Having multiple raw contacts means you don't have to choose which > system you sync with; you can sync with all of them. Aggregating multiple > raw contacts under one "contact" means that you can see all of the > information just by searching on a name. > > To summarize what you see for the Contacts Provider in the Javadoc: > > The interfaces whose names end in "Columns" are constant definitions for > table columns. They're defined as interfaces so a table class can inherit > more than one of them at once. > The CommonDataKinds classes define constants for commonly-used values. > They're not columns, but what columns contain. > The Contacts class and subclasses define stuff for the contacts table. > The RawContacts class and subclasses define stuff for the raw contacts > table. > The Data class and subclasses define stuff for the data table. > Everything else is auxiliary tables that you usually don't have to use. > Nice summary! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
