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 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?

Answer 1

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.