Accessing phone contacts to implement a "friends" feature

[peroh]

Suggestions

• Use Contacts API to access phone contacts
• Display contacts that are using the app
• Allow adding and accepting friend requests
• Monitor friend status with a "Friendship" table in database

Contacts API

Contacts.getPermissionsAsync()

When permission hasn't been granted yet, revoked, or denied:

{
  "canAskAgain": true,
  "expires": "never",
  "granted": false,
  "status": "denied",
}

When permission has been granted:

{
  "canAskAgain": true,
  "expires": "never",
  "granted": true,
  "status": "granted",
}

Contacts.requestPermissionsAsync()

If granted is false, this popup will be triggered every time it is called:

If granted is true, the popup won't appear anymore until the permissions are revoked.

Code snippets

Checking for permissions and then requesting permissions:

const { granted } = await Contacts.getPermissionsAsync();
if (granted) {
  doWorkOnContactList()
} else if (!granted && shouldAskForPermission) {
  // shouldAskForPermission will depend on business logic
  const { granted } = await Contacts.requestPermissionsAsync();
  if (granted) {
    doWorkOnContactList()
  }
}

Contacts data structure:

const { data } = await Contacts.getContactsAsync({
  fields: [Contacts.Fields.PhoneNumbers],
});
console.log("Number of contacts:", data.length);
for (var i = 0; i < Math.min(data.length, 100); i++) {
  if (data[i] && data[i].name && data[i].phoneNumbers) {
    console.log(`${data[i].name}: ${data[i].phoneNumbers[0].number}`);
  }
}

Comments

• I suspect we will need to store some state (maybe in local storage or on the server) about whether we have asked for contact permissions before. If a user denies permissions initially, we don't want don't want to keep asking every time the app re-renders. But we do want the ability to ask again if they click the wrong thing, or if they decide they want to enable the friends functionality down the track.

[shadforth]

Great write-up @peroh! 👏

A few thoughts:

• Love the hand drawn diagram (iPad?) 😁
• Access via Settings: On your comment about a user accidentally not granting permission access, perhaps this can be an option on our Settings page. With that, we can provide some informational text to explain why we need contact access.
• Table naming: A suggestion on the "Friendship" table - I have an inkling naming it something a bit more generic like "Relationship" will give us more flexibility in future.
• Blocking a contact: Are we going to give users the access to "block" other contacts, i.e. the WhatsApp pattern? I think from what you've described it makes sense to keep it as simple as "User 1 is friends with User 2" or "User 1 is not friends with User 2".
• Navigation bar: Just raising a thought if the Contacts page sits within our navigation bar or somewhere else

[peroh]

• iPad ✅
• Settings access 👌
• Table naming 👌
• Blocking - agree the simple approach of is/is not friends should suffice
• Navigation - good question - let's get design input

Thanks @shadforth