Keeping a long-term reference to an IOS AddressBook entry

Question

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 reco

Answer 1

The RecordID only get changed either on delete or reset, when this is done all the new record(s) will have new createdProperty and modifiedProperty as well.

1. While I am reading the address book for the first time, I will save all entries of the record along with RecordID in my database.

2. I will save the last time the contacts synced from contacts to my database(name it something: lastSyncedTime) and store it some where.

I am done with syncing the contacts for the first time, now do the following for syncing anytime in future.

while Iterating through all records,

1. check createdTime(kABPersonCreationDateProperty) vs lastSyncedTime. If createdTime > lastSyncedTime, store the recordID in a "newRecords" NSArray.

2. If !(step 1) then check modifiedDate(kABPersonModificationDateProperty) vs lastSyncedTime. If modifiedDate > lastSyncedTime, then store the recordID in a "modifiedRecords" NSArray.

3. if !(1) && !(2) store all recordID in a "unModifiedRecords".

Now I will read all the contacts from my local database,

1. I will delete all local database records that are not find either in "modifiedRecords" or in "unModifiedRecords".

2. I will update all "modifiedRecords" in the local database.

3. I will create new records for all records in "newRecords".

4. Update the lastSyncedTime accordingly.

Answer 2

Refer : https://developer.apple.com/library/ios/documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/Chapters/DirectInteraction.html#//apple_ref/doc/uid/TP40007744-CH6-SW2

Clearly tells you how to handle it.

Answer 3

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.

Answer 4

The documentation is communicating to you that you can't count on ABRecordID as a permanent identifier.

Consider this scenario: The user has a record for "Bob Smith". The user then deletes his "Bob Smith" record and then imports his contacts from his computer (creating a new ID) through iTunes sync.

So if you want to keep a permanent reference to an existing contact, you can keep a reference to the name and id as a hint that it is the same record you used before- but there is no real permanent reference.

If you keep a permanent reference to an address book contact, you must always be ready to deal with the fact that it may not be the same contact you used before.