I am one of the developers of iOS GroupMe, and this is what we do.
We scan the users address book and store it in Core Data. We have a Contact object that has 1-to-many by phone numbers and 1-to-many by email addresses. The first scan may take a little time if there are many contacts, but in each subsequent scan, we ignore any ABRecordRef that kABPersonModificationDateProperty has before our last scan. This makes updates much faster.
Then, assuming that the user has selected contact synchronization, we send to our server phone numbers and email addresses that will correspond to existing GroupMe users.
Finally, we pull out GroupMe relationships based on matches (from phone, email, facebook, twitter) and store them in Core Data. If the connection was made because of the phone / email that already exists in the user's address book, we transfer these values ββback to the relationship so that we can create a 1 to 1 relationship between the GroupMe relationship and the contact that we saved in Core Data in step 1 Thus, we can easily create an NSFetchRequest for local contacts or GroupMe relationships and get relationship data at any point (so that we can show that the local contact is a GroupMe user, etc. - like Aaron G. in your screenshot)
We also use NSFetchedResultsController , so we can receive updates reflected in the user interface if our background operations find new contacts / relationships.
The only other tips are to make sure that you have a fetch request to pre-fetch all relationships, so the reasons for loading do not affect the basic data when scrolling to fill in the errors.
And yes, keeping your n'sync master data with a user address book more tedious than stupid is worth having easy access to it for queries that all this jazz needs to know.
jeremysomething
source share