考虑到ABRecordID可以在云同步之间更改,以及在我无法控制的其他情况下更改,我如何维护对IOS地址簿记录的长期引用?
Apple提供了以下指导:
保留对特定记录的长期引用的推荐方法是除了存储标识符之外,还存储名字和姓氏或名字和姓氏的哈希。按ID查找记录时,将记录的名称与存储的名称进行比较。如果它们不匹配,则使用存储的名称查找该记录,并存储该记录的新ID。
但是我不理解这个指南。如果地址簿中可以有重复的名称,并且用户可以修改记录中的名称,那么这个建议如何工作呢?
例如,如果用户修改了地址簿记录的名称,我的例程将无法通过ABRecordID找到它,因此,如果我认为通过存储的名称散列进行搜索,我不能找到重复的名称而不是之前引用的特定记录的新ABRecordID吗?
最后,获得对IOS AddressBook记录的长期引用的最佳方法是什么?如果上面的建议真的有效,那么我错过了什么呢?
发布于 2013-02-12 00:44:47
最健壮(但不是完全安全)的方法是提出ABRecord字段的优先级排序,并将该列表中可用的尽可能多的内容与ABRecordID一起存储到您自己的(散列的)私有记录格式中。在检索私有记录时(或在其他方便的时候),您可以验证私有记录是否与ABRecord匹配,并通过一系列备用检查来确保它的准确性。
优先级排序示例:
在检索记录时,您可以首先匹配ABRecordID。如果没有返回任何结果,您可以搜索FirstName + LastName。然后,您可以将这些结果与PhoneNumber进行匹配。通过这种方式,您可以潜在地区分两个Bob Smith,因为他们可能有不同的电话号码(或者其中一个可能没有电话号码)。当然,根据你的优先级列表有多长,这个机制就越健壮。
最后的办法是提示用户区分具有全新ABRecordID的两个Bob Smith,它们的记录在其他方面是相同的--毕竟,这种不方便的提示将比允许用户联系错误的Bob Smith要友好得多(正如我所说的,这将是最后的办法)。
然而,AB的这种解决方案可能涉及一些同步问题。
对于任何使用过iOS媒体播放器的人来说,这都是一个熟悉的问题。具体地说,用户音乐库中的MPMediaItems具有属性MPMediaItemPropertyPersistentID,文档描述为:
不能保证该值在整个同步/取消同步/同步周期中保持不变。
换句话说,不能保证PersistentID是持久的。此问题的解决方案包括对MediaItem属性执行类似的回退检查。
发布于 2013-08-29 18:41:56
RecordID只有在删除或重置时才会更改,当此操作完成后,所有新记录都将具有新的createdProperty和modifiedProperty。
我已经完成了第一次同步联系人,现在做以下同步在未来的任何时间。
当遍历所有记录时,
现在我将读取本地数据库中的所有联系人,
我将删除在“accordingly.”或"unModifiedRecords".
发布于 2013-02-08 14:11:48
文档告诉您,您不能指望ABRecordID作为永久标识符。
考虑这个场景:用户有一条"Bob Smith“的记录。然后,用户删除他的"Bob Smith“记录,然后通过iTunes同步从他的计算机导入他的联系人(创建一个新的ID)。
因此,如果你想保留对现有联系人的永久引用,你可以保留对姓名和id的引用,以提示它与您之前使用的记录相同-但没有真正的永久引用。
如果您保留对通讯簿联系人的永久引用,则必须始终准备好处理它可能与您以前使用的联系人不同这一事实。
https://stackoverflow.com/questions/14763688
复制相似问题