Сохранение долгосрочной ссылки на запись адресной книги IOS

Учитывая, что ABRecordID может меняться между облачными синхронизациями и при других обстоятельствах из-под моего контроля, как я могу поддерживать долгосрочную ссылку на запись в адресной книге IOS?

Apple предоставляет следующие рекомендации:

"Рекомендуемый способ сохранить долгосрочную ссылку на конкретную запись - это сохранить первое и последнее имя или хэш первого и последнего имени в дополнение к идентификатору. Когда вы просматриваете запись по ID, сравните имя записи с вашим сохраненным именем. Если они не совпадают, используйте сохраненное имя для поиска записи и сохраните новый идентификатор для записи."

Но я не понимаю этого указания. Если адресная книга может иметь в себе дубликаты имен И, поскольку пользователи могут изменять имя в записи, как этот совет может работать?

Например, если пользователь изменяет имя записи в адресной книге, моя подпрограмма не сможет найти ее по адресу ABRecordID, поэтому, если я думаю, что поиск по хэш-имени, который я хранил, не мог найти дублирующее имя вместо нового ABRecordID для этой конкретной записи, на которую я ранее ссылался?

В конце концов, каков ЛУЧШИЙ способ получить долгосрочную ссылку на запись IOS AddressBook? И если приведенный выше совет действительно работает, что мне не хватает?

Ответы

Ответ 1

Самый надежный (но не полностью отказоустойчивый) подход - это придумать приоритетный рейтинг полей ABRecord и сохранить как можно больше из этого списка вместе с ABRecordID в свой собственный (хешированный) формат записи, При получении личной записи (или в другое удобное время) вы можете проверить, что личная запись соответствует ABRecord, и выполните серию проверок с обратной связью, чтобы обеспечить ее точность.

Пример ранжирования приоритетов:

  • ABRecordID
  • FirstName
  • LastName
  • PhoneNumber
  • ZipCode

При извлечении записи вы можете сначала сопоставить ABRecordID. Если это не даст никаких результатов, вы можете выполнить поиск FirstName + LastName. Затем вы можете сопоставить эти результаты с PhoneNumber... и т.д. Таким образом, вы можете различать 2 Боба Смита, так как у них могут быть разные номера телефонов (или, возможно, у них нет номера телефона). Конечно, в зависимости от того, как долго ваш список приоритетов, тем более надежным будет этот механизм.

Последнее средство будет побуждать пользователя различать 2 Боба Смита с новым ABRecordID, чьи записи в остальном идентичны - в конце концов, такое неудобное приглашение будет гораздо более дружелюбно, чем позволить Пользователю связаться с неправильным Боб Смит (и, как я сказал, был бы последним средством).

Однако это решение для AB может включать некоторые проблемы синхронизации.

Это знакомая проблема для тех, кто работал с iOS Media Player. В частности, MPMediaItems в библиотеке пользовательской музыки имеет свойство MPMediaItemPropertyPersistentID, которое документы описывают как:

Значение не может сохраняться в цикле синхронизации/синхронизации/синхронизации.

Другими словами, PersistentID не гарантируется настойчивость. Решения для этого включают выполнение аналогичных проверок на свойства MediaItem.

Ответ 2

RecordID может быть изменен только при удалении или reset, когда это будет сделано, все новые записи будут иметь новые createdProperty и modifiedProperty.

  • Пока я читаю адресную книгу в первый раз, я сохраню все записи записи вместе с RecordID в моей базе данных.

  • Я сохраню последний раз, когда контакты, синхронизированные с контактами, в мою базу данных (назовите это что-то: lastSyncedTime) и сохраните их где-нибудь.

Я закончил синхронизацию контактов в первый раз, теперь выполняю следующие действия для синхронизации в любое время в будущем.

итерации по всем записям,

  • проверить createdTime (kABPersonCreationDateProperty) против lastSyncedTime. Если createdTime > lastSyncedTime, сохраните идентификатор записи в NSArray.

  • Если! (шаг 1), то проверьте modifiedDate (kABPersonModificationDateProperty) и lastSyncedTime. Если modifiedDate > lastSyncedTime, то сохраните идентификатор записи в NSArrayray "modifiedRecords" .

  • if! (1) & &! (2) сохраните все recordID в "unModifiedRecords".

Теперь я буду читать все контакты из моей локальной базы данных,

  • Я удалю все локальные записи базы данных, которые не находятся ни в "modifiedRecords" , ни в "unModifiedRecords".

  • Я обновлю все "modifiedRecords" в локальной базе данных.

  • Я создам новые записи для всех записей в "newRecords".

  • Обновите lastSyncedTime соответственно.

Ответ 3

Документация сообщает вам, что вы не можете рассчитывать на ABRecordID как постоянный идентификатор.

Рассмотрим этот сценарий: у пользователя есть запись для "Bob Smith". Затем пользователь удаляет свою запись "Боб Смит", а затем импортирует свои контакты со своего компьютера (создавая новый идентификатор) через iTunes sync.

Итак, если вы хотите сохранить постоянную ссылку на существующий контакт, вы можете сохранить ссылку на имя и идентификатор в качестве подсказки, что это та самая запись, которую вы использовали раньше, но нет реальной постоянной ссылки.

Если вы сохраняете постоянную ссылку на контакт в адресной книге, вы всегда должны быть готовы к тому, что это может быть не тот самый контакт, который вы использовали раньше.