Уникальный идентификатор записи контактной книги + база данных SQLite - PullRequest
3 голосов
/ 19 января 2012

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

Теперь вопросы:
1).Какой вариант лучше, хранить уникальный идентификатор записи контакта в SQLite или хранить все детали контакта?
2).Если ваш ответ идентификатор , будет ли этот уникальный идентификатор записи ссылаться на одну и ту же запись каждый раз?

Ответы [ 4 ]

2 голосов
/ 27 ноября 2014

ABRecordID a.k.a. уникальный идентификатор - хороший способ идентифицировать каждую запись. Тем не менее, документация Apple содержит некоторые заслуживающие внимания пункты об ABRecordID, возвращенном этим API.

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

Таким образом, чтобы ответить на ваши вопросы 1). Какой вариант лучше, хранить уникальный идентификатор записи контакта в SQLite или хранить все детали контакта?

Минимальные сведения, которые я бы посоветовал вам сохранить в вашей БД SQLite: имя, фамилия, дата создания и идентификатор записи

Причина, снова упомянутая в документации Apple:

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

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

2). Если ваш ответ является идентификатором, то будет ли этот уникальный идентификатор записи ссылаться на одну и ту же запись каждый раз?

Объясняя ваш первый вопрос, я думаю, что я также ответил на этот вопрос.

Несмотря на то, что я вставил здесь большую часть контента, всегда рекомендуется прочитать документацию

2 голосов
/ 19 января 2012

1). Какой вариант лучше, хранить уникальный идентификатор записи контакта в SQLite или хранить все детали контакта?

Я бы сказал, что нет необходимости хранить все данные, так как они уже сохранены в устройстве, поэтому подойдет простой идентификатор.

2). Если ваш ответ является идентификатором, то будет ли этот уникальный идентификатор записи ссылаться на одну и ту же запись каждый раз?

Да, он должен ссылаться на одну и ту же запись каждый раз, поэтому он является уникальным идентификатором.

Кроме того, я бы рекомендовал прочитать раздел уникальных идентификаторов в структуре AddressBook непосредственно из источника: Руководство по программированию Apple Address Book

Надеюсь, это поможет.

1 голос
/ 01 мая 2012

Уникальный идентификатор адресной книги не всегда один и тот же. он может измениться, если вы запустите некоторые приложения синхронизации, такие как контакты Google из адресной книги TAPP, так как контакты будут удалены и добавлены снова. Наилучший способ - создать некоторый хеш-код, например, объединить все свойства, а затем проверить в db, если одно не совпадает, удалить из sqlite, который не соответствует, и добавить новый в db.

помните, что если вы работаете на одном устройстве, то для идентификатора проблем нет. но если ваши контакты общаются с любым сервером устройства, как Mac. тогда вам нужно найти лучшее решение. я нашел тот, который я упомянул.

0 голосов
/ 03 марта 2014

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

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

...