[android-developers] Re: Stable contact identity & CONTENT_LOOKUP_URI

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 WHERE clause on the contact ID
to pull out the settings for a particular contact.

If we store lookup URIs in the table, and want to find some current
contact in that table, we cannot do it by comparing lookup URIs
directly, because the lookup URI for the target contact may have
changed since we wrote the table. If we want to compare two lookup
URIs to see if they refer to the same person, we need to look them
both up in the contacts table and see if they have the same record ID
right now. Is that right ?

Thanks,

Richard

On Nov 2, 5:32 pm, Dmitri Plotnikov <dplotni...@google.com> wrote:
> Hi Richard,
>
> You are exactly right.  If you want a robust persistent reference to a
> contact, you now need to use the lookup URI.  Android itself uses lookup
> URIs for shortcuts, Quick Contact etc.  The main reason contact ID is
> volatile is that Android 2.0 has contact aggregation, both automatic and
> manual.  Let's say your app stored a long ID of a contact.  Then the user
> goes and manually joins the contact with some other contact. Now we have one
> contact where we used to have two - the stored long contact ID points
> nowhere.  However, the lookup key is more resilient.  It's a string
> concatenating identities of raw contacts.  Using that string, we can still
> track down a contact as it is joined with others or separated from them.
>
> There are two options available to you: you can store just the lookup key,
> which is a string id of a contact, or you can use both the lookup and the
> long id of a contact.  The latter will give you better performance, but
> functionally the long id is not required.  I would take this approach: if
> you need to bulk-process contacts, maintain both ids.  If your app works
> with a single contact per user action - you don't need to bother with the
> long id.
>
> I hope this helps,
> - Dmitri
>
> On Mon, Nov 2, 2009 at 9:02 AM, jarkman <jark...@gmail.com> wrote:
> > In the course of moving to the 2.0 cotnact APIs, I've stumbled across
> > CONTENT_LOOKUP_URI :
>
> >http://developer.android.com/reference/android/provider/ContactsContr...
>
> > "As long as the contact's row ID remains the same, this URI is
> > equivalent to CONTENT_URI. If the contact's row ID changes as a result
> > of a sync or aggregation, this URI will look up the contact using
> > indirect information "
>
> > Currently, we store contact IDs to identify particular contacts. If I
> > read this right, contact IDs will no longer be stable in the world of
> > 2.0, and we will need to store a lookup URI (or at least a LOOKUP_KEY
> > and a row ID) in order to identify a contact in a stable way.
>
> > That would be a substantial change in our code. So, before I rush off
> > to do it, I'd love to find out if a contact row ID change is going to
> > be a routine thing (say, on every sync), or if it will be a very rare
> > thing (say, when two contacts are manually combined into one, or some
> > even rarer exception).
>
> > Any clues ?
>
> > Thanks,
>
> > Richard
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubscribe@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
>

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en