如何在ContactsContract.Contacts表上唯一标识联系人 [英] How to uniquely identify a contact on ContactsContract.Contacts table

问题描述

我有一个应用程序，该应用程序获取设备上联系人的ContactsContract.Contacts.LOOKUP_KEY并将其保存在应用程序Db中.

I have an app that gets the ContactsContract.Contacts.LOOKUP_KEY of a contact on the device and saves it on the app Db.

阅读此页面后，我认为我即使编辑了某个联系人(例如，在编辑了联系人的姓名之后)，也可以使用LOOKUP_KEY唯一地标识该联系人.

After reading this page I thought I could use the LOOKUP_KEY to uniquely identify a contact, even when a contact is edited (for example after editing the name of the contact).

实际上，我看到编辑联系人后，其LOOKUP_KEY发生了更改，因此我无法再使用保存在应用程序数据库中的LOOKUP_KEY.

Actually I saw that after editing a contact, its LOOKUP_KEY changes, so I cannot use anymore the LOOKUP_KEY I saved on my app DB.

我的问题是:从第一次在设备上创建联系人直到将其从设备中删除，有没有办法唯一地标识ContactsContract.Contacts上的联系人?

My question is: is there a way to uniquely identify a contact on ContactsContract.Contacts from when it is created for the first time on the device until it is deleted from the device?

谢谢

推荐答案

LOOKUP_KEY不能单独用作键，而应与联系人的_ID一起使用以构成完整的键lookupUri.

A LOOKUP_KEY is not meant to be used as a key on its own, instead it should be used together with a contact's _ID to form a full lookupUri.

然后可以使用lookupUri在CONTENT_LOOKUP_URI表中查找联系人. CONTENT_LOOKUP_URI基本上首先通过_ID查找联系人，如果找不到，或者_ID似乎是错误的联系人，它会使用LOOKUP_KEY部分中的提示尝试为您找到正确的联系人.

The lookupUri can then be used to find a contact in CONTENT_LOOKUP_URI tables. The CONTENT_LOOKUP_URI basically first looks for the contact by _ID, if it fails to find it, or the _ID seems like the wrong contact, it uses hints from the LOOKUP_KEY part to try and track down the correct contact for you.

来自 CONTENT_LOOKUP_URI

此表的content://样式URI，应使用它创建 快捷方式或以其他方式创建到联系人的长期链接.这个URI 应始终后跟一个"/"和联系人的LOOKUP_KEY.它 可以选择附加一个"/"和最后一个已知的联系人ID 在那之后.这种完整"格式是一项重要的优化，并且 强烈推荐.

A content:// style URI for this table that should be used to create shortcuts or otherwise create long-term links to contacts. This URI should always be followed by a "/" and the contact's LOOKUP_KEY. It can optionally also have a "/" and last known contact ID appended after that. This "complete" format is an important optimization and is highly recommended.

只要联系人的行ID保持不变，此URI就是 等同于CONTENT_URI.结果是联系人的行ID发生变化 同步或聚合，此URI将使用 间接信息(同步ID或原始联系人).

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 (sync IDs or constituent raw contacts).

查找键应未编码地附加-它存储在已编码的编码中 表单，可以在URI中使用.

Lookup key should be appended unencoded - it is stored in the encoded form, ready for use in a URI.

来自 getLookupUri(long contactId, String lookupKey)

使用给定的_ID和 LOOKUP_KEY.

Build a CONTENT_LOOKUP_URI lookup Uri using the given _ID and LOOKUP_KEY.

来自 LOOKUP_KEY

一个不透明值，其中包含有关如何查找联系人的提示 同步或汇总导致行ID发生了更改.

An opaque value that contains hints on how to find the contact if its row id changed as a result of a sync or aggregation.

这篇关于如何在ContactsContract.Contacts表上唯一标识联系人的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！