aggregation of contacts

The anatomy of a lookup key is basically this. If an aggregate contact has three raw contacts with server-side IDs "A", "B" and "C", the lookup key will effectively be accountA/A.accountB/B.accountC/C

satya - Monday, November 01, 2010 1:05:51 PM

containging the most of the original raw contacts

contact ID, which will be the one containing the most of the original raw contacts

satya - Monday, November 01, 2010 1:07:17 PM

Something to digest from that topic

Lookup key is unique at any point in time. It's not unique over time.

We don't attempt to find a contact with that exact lookup key. We actually parse it, find all those three raw contacts and infer the id of the new contact ID, which will be the one containing the most of the original raw contacts. In other words, even though the result is a bit unpredictable, the user shouldn't be surprised by what they see. The original contact had A, B and C - now I am looking at something that has either A or B or C or a couple of those or maybe A,B,C and D.

You are right that you should not use lookup keys to compare contact identities to each other. You can use the ContactsContract.Contacts.lookupContact(resolver, lookupUri) method, which will give you the current contact ID for your contact. Be careful though - between the moment you get it and the moment you use it the contact may change. Any kind of background sync could cause this change to happen. I would try to design the software in such a way that either doesn't need to do this type of resolution or uses something even more robust than lookup keys, e.g. raw contact IDs.

satya - Monday, November 01, 2010 1:12:47 PM

On Aggregation algorithms

can tell you what we did when we faced a similar requirement. We needed to store things like custom ringtone, "straight-to-voicemail" etc on a per-contact basis. What we ended up doing is simply replicating this information into each raw contact in the aggregate. When raw contacts are re-aggregated, we use a heuristic to figure out the values for the entire aggregate (e.g. if one of the raw contacts has straight-to-voicemail=false, then the entire contact has straight-to-voicemail=false).

I would do the same in your case. You can always get _ids of all raw contacts in an aggregate contact and then in your database have a row for each of those raw contacts. To retrieve the information for an aggregate contact, you would pull it for all constituent raw contacts and use an algorithm to "aggregate" the data.

satya - Monday, November 01, 2010 1:22:16 PM

Another meaty thread on contacts api

satya - Monday, November 01, 2010 1:23:42 PM

How to have the contacts app create a contact for your need

You can always delegate contact creation to the Contacts app using the ContactsContract.Intents.UI.Insert intent with extras. This will show the edit UI.

satya - Monday, November 01, 2010 1:27:42 PM

get a list of accounts


AccountManager am = AccountManager.get(getContext()); 
Account[] accounts = am.getAccounts();

satya - Monday, November 01, 2010 1:31:15 PM

account types


SyncAdapterType[] syncs 
= ContentResolver.getContentService().getSyncAdapterTypes(); 

for (SyncAdapterType sync : syncs) 
{ 
     if (ContactsContract.AUTHORITY.equals(sync.authority) 
          && sync.supportsUploading()) 
     { 
          contactAccountTypes.add(sync.accountType); 
     } 
}

for (Account acct: accounts) 
{ 
   if (contactAccountTypes.contains(acct.type)) 
   { 
      contactAccounts.add(account); 
   } 
}

satya - Monday, November 01, 2010 1:34:43 PM