保持对IOS AddressBook条目的长期引用 [英] Keeping a long-term reference to an IOS AddressBook entry

问题描述

鉴于ABRecordID可以在云同步之间进行更改，并且在我无法控制的其他情况下，如何保持对IOS地址簿记录的长期引用？

< Apple提供以下指导：

保持对特定记录的长期引用的推荐方法是存储名字和姓氏，或哈希除了标识符之外，还有名字和姓氏。当您按ID查找记录时，将记录的名称与存储的名称进行比较。如果它们不匹配，请使用存储的名称查找记录，并存储记录的新ID。

但我不明白这个指导。如果地址簿中可能有重复的名称，并且由于用户可以修改记录中的名称，这个建议怎么可以工作？

例如，如果用户修改了名称一个地址簿记录我的例程将无法通过ABRecordID找到它所以如果我认为通过我存储的名称哈希搜索我找不到重复的名称而不是我之前引用的特定记录的新ABRecordID？

最后，获得长期参考IOS AddressBook记录的最佳方法是什么？如果上述建议确实有效，我缺少什么？

解决方案

最强大（但并非完全失效）的方法将是提出ABRecord字段的优先级排序，并将该列表与ABRecordID一起存储到您自己的（散列）私有记录格式中。检索私人记录时（或在其他方便的时间），您可以验证私人记录是否与ABRecord匹配，并通过一系列后备检查来确保其准确。

优先级排名示例：

1. ABRecordID


2. FirstName


3. LastName


4. PhoneNumber


5. ZipCode

何时检索记录您可以先匹配 ABRecordID 。如果没有返回结果，您可以搜索 FirstName + LastName 。然后，您可以将这些结果与 PhoneNumber ...等进行匹配。通过这种方式，您可以区分2个Bob Smiths，因为它们可能有不同的电话号码（或者可能没有有一个电话号码）。当然，根据你的优先级列表的长度，这个机制会越健壮。

最后一种方法是提示用户区分2个Bob Smiths全新的 ABRecordID ，其记录在其他方面是相同的 - 毕竟，这样一个不方便的提示将比允许用户联系错误的Bob Smith（和我说，这将是最后的手段。）

然而，AB的这个解决方案可能会涉及一些同步问题。

<对于使用过iOS Media Player的人来说，这是一个熟悉的问题。用户音乐库中的 MPMediaItems 具有属性 MPMediaItemPropertyPersistentID ，文档描述为：

不保证在同步/非同步/同步周期内保持该值。

换句话说， PersistentID 不保证是持久的。解决方案包括对 MediaItem 属性执行类似的后备检查。

Given that an ABRecordID can change between cloud syncs and under other circumstances out of my control, how can I maintain a long-term reference to an IOS address book record?

Apple provides the following guidance:

"The recommended way to keep a long-term reference to a particular record is to store the first and last name, or a hash of the first and last name, in addition to the identifier. When you look up a record by ID, compare the record’s name to your stored name. If they don’t match, use the stored name to find the record, and store the new ID for the record."

But I don't understand this guidance. If the address book can have duplicate names in it AND since users can modify the name in a record how could this advice work?

For example, if the user modifies the name of an address book record my routine will fail to find it by ABRecordID so if I think search by the name hash I stored couldn't I find a duplicate name instead of the new ABRecordID for that specific record I previously referenced?

In the end, what is the BEST way to get a long-term reference to an IOS AddressBook record? And if the above advice really does work what am I missing?

解决方案

The most robust (yet not completely failsafe) approach would be to come up with a priority ranking of ABRecord fields and store as much from that list as is available, along with the ABRecordID, into your own (hashed) private record format. When retrieving a private record (or at another convenient time), you can verify that the private record matches the ABRecord and work through a series of fallback checks to ensure it's accurate.

Example priority ranking:

1. ABRecordID
2. FirstName
3. LastName
4. PhoneNumber
5. ZipCode

When retrieving a record you can first match the ABRecordID. If that returns no results, you can do a search for FirstName + LastName. You can then match those results against PhoneNumber... etc. In this way you could potentially distinguish between 2 Bob Smiths, as they may have different phone numbers (or one may not have a phone number). Of course, depending on how long your priority list is, the more robust this mechanism will be.

The last resort would be prompting the user to distinguish between 2 Bob Smiths with brand new ABRecordID's whose records are otherwise identical -- after all, such an inconvenient prompt would be far more friendly than allowing the User to contact the wrong Bob Smith (and as I said, would be a last resort).

This solution for AB may involve some synchronization issues, however.

This is a familiar problem for anyone who has worked with the iOS Media Player. Specifically MPMediaItems in the User's Music Library have a property MPMediaItemPropertyPersistentID which the docs describe as:

The value is not guaranteed to persist across a sync/unsync/sync cycle.

In other words, the PersistentID is not guaranteed to be persistent. Solutions for this include doing similar fallback checks on MediaItem properties.

这篇关于保持对IOS AddressBook条目的长期引用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！