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