Android: Manage contacts with lookup key

I'm currently writing a application that allows to save drafts (using android version >= 2.0). Each draft is connected to a contact via the ContactsContract.Contacts.LOOKUP_KEY. My problem is that if I change the name of my contact the lookup key changes also. Is that the way this works?

So for what do I need a lookup key? I thought that the lookup key does never change and now it changes anyway.开发者_运维技巧 I'm confused about that behavior ...

Can someone explain to me how to link permanently to a contact? Should I use IDs instead of the lookup key?

Thanks in advance.

It is my understanding that the lookup key is a structured / hierarchical key. Hence strictly speaking it can change, but still be used to find your contact back, by using the appropriate method:

    Uri lookupUri = Uri.withAppendedPath(ContactsContract.Contacts.CONTENT_LOOKUP_URI, lookupKey);
    Uri res = ContactsContract.Contacts.lookupContact(getContentResolver(), lookupUri);

Edited:

Why don't you find contact id or lookup key via using raw contact id? this is bug in 2.1.

Lookup key was based on the contact name for unsynced contacts.

http://comments.gmane.org/gmane.comp.handhelds.android.devel/130677

==================================================================

I didn't try yet. But I found some information about this.

http://developer.android.com/resources/articles/contacts.html

....

If performance is a concern for your application, you might want to store both the lookup and the long ID of a contact and construct a lookup URI out of both IDs, as shown here:

Uri lookupUri = getLookupUri(contactId, lookupKey)

When both IDs are present in the URI, the system will try to use the long ID first. That is a very quick query. If the contact is not found, or if the one that is found has the wrong lookup key, the content provider will parse the lookup key and track down the constituent raw contacts. If your app bulk-processes contacts, you should maintain both IDs. If your app works with a single contact per user action, you probably don't need to bother with storing the long ID.