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 circumstances where we will lose track ? For example, might an ID change as a result of a sync which does not aggregate or disaggregate a contact ? When we use the lookup uri and a contact is disaggregated, will the lookup URI we are holding still refer to one of the two resulting contacts, or will it no longer refer to either of them ? Incidentally, I wonder if it might be worth mentioning this change a bit more prominently in the 2.0 release notes. If I hadn't happened across the lookup key in the docs, I would not have realised that 2.0 broke all our contact references. I imagine other developers may not be so lucky. 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+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
