why won't contacts aggregate?
Asked Answered
E

1

0

My app allows editing contacts. In this scenario, I chose a contact which existed in only one account and changed it to associate it with three accounts. However, I ended up with two contacts, not one, as shown in the ContactsContract dump below. Why didn't the provider aggregate them?

agg 1821, display "A Z1", key 770i236434918d3893ea.2709i79dde86f8c1565d3.2709i506dc01a0d43d677.2709i4707c358f8fb503
  raw 1821, acct type com.google, acct name [email protected]
    data 10338, display "A Z1"
    data 10343, phone 123456, Pager
    data 10349, phone 545, Fax Work

agg 1861, display "A Z1", key 1780r1860-q29pq04pq5Bpq16p.2709r1861-q29pq04pq5Bpq16p
  raw 1860, acct type com.fusionone.account, acct name Backup Assistant
    data 10580, display "A Z1"
    data 10582, phone 123456, Pager
    data 10584, phone 545, Fax Work

  raw 1861, acct type com.google, acct name [email protected]
    data 10581, display "A Z1"
    data 10583, phone 123456, Pager
    data 10585, phone 545, Fax Work

In this dump, the three tiers represent the aggregate contact rows, the raw contact rows, and the contact data rows. The number next to the leading word (e.g. agg 1821) is the _ID column value. "display" represents DISPLAY_NAME.

More specifically, I started with agg 1821 which comes from account [email protected] (obfuscated). Then I created two new raw contacts (1860 and 1861) for two other accounts, using the same display name as for agg 1821. You can see the results: the two new raw contacts were aggregated together but the pair was not aggregated with the original (1821) contact.

Egomania answered 18/11, 2016 at 18:43 Comment(0)
K
4

Don't assume the system to aggregate similar contacts, if you want RawContacts to join force aggregation by writing to AggregationExceptions:

for each pair, create an operation:

Builder builder = ContentProviderOperation.newUpdate(AggregationExceptions.CONTENT_URI);
builder.withValue(AggregationExceptions.TYPE, AggregationExceptions.TYPE_KEEP_TOGETHER);
builder.withValue(AggregationExceptions.RAW_CONTACT_ID1, raw1);
builder.withValue(AggregationExceptions.RAW_CONTACT_ID2, raw2);
ContentProviderOperation op = builder.build();

Then execute an ArrayList of all operations:

ContentProviderResult[] res = resolver.applyBatch(ContactsContract.AUTHORITY, operationList);

res will contain info about the success/failure of all operations

Kimble answered 29/11, 2016 at 15:16 Comment(2)
I'll give you a +1 since this technique works, and is what I'm using. However, it doesn't answer the question. Unless someone can come up with a good reason the aggregation algorithm failed in my example, it seems like it is pretty useless.Egomania
the automatic aggregation decision code is quite complex, it's possible that it also uses contact's creation date to make the decision, so when you create two identical contacts at the same time, it immediately aggregates them, but not the old one. I've had cases where an aggregation happened a few days later, when a contact was updated via the sync-provider.Kimble

© 2022 - 2024 — McMap. All rights reserved.