Dmitri - thanks - that's perfect.
So, we have two choices -
(1) For each incoming contact URI, loop over our table of stored
lookup keys, looking each one up with
ContactsContract.Contacts.lookupContact(resolver, lookupUri) and
comparing with the incoming contact.
I think that will be reliable,
Hi Richard,
I 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
Dmitri - thanks - that's very helpful. I have a couple more questions,
if that's OK:
In the short term, if we do not use the lookup URI, and go on storing
record IDs, we will clearly lose track of a contact when aggregation
or dis-aggregation of a contact takes place. Are there any other
Oh - one more question:
Am I right in thinking that the lookup URI is not itself a unique,
stable identifier ? That is, the lookup URI for one contact may be
different at different times.
Right now, we store some contact row IDs in a table, along with per-
contact settings of our own. We use a
Hi Richard,
Lookup key is unique at any point in time. It's not unique over time.
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
We don't
5 matches
Mail list logo
