This article is the follow-up to answer the questions raised in the previous article Mobile Address Book and Contact Picker API Experiment, which tries to explain the Contact Picker API and its current stage, in the following paragraphs, I will list the questions and the answer we found, and demonstrate the experiments we did.
Q. What browser/OS combinations are supported today?
Currently, at the time I’m writing this article, the Contact Picker API browser support is as follows below:
- Chrome for Android – Full support since version 112
- Opera Mobile – Full support since version 73
- Android Browser – Full support since version 112
- Safari iOS 17.4 – Not supported by default, but can be enabled through the Contact Picker API flag.
You can find the most recent support information in the following two links:
- https://developer.mozilla.org/en-US/docs/Web/API/ContactsManager#browser_compatibility
- https://caniuse.com/mdn-api_contactsmanager
Q. What is the current contact data format returned through the API, can we easily transform it into our structure?
The returned structure for Contact Picker API, is an array of contact objects, with the following structure in Typescript:
You can find more information on the W3C Contact Picker API Draft.
Q. What events does the Contact Picker API emit? Are we notified about successful or failed selections?
The Contact Picker API getProperties receives no parameters and returns a Promise that resolves with an Array of strings naming the contact properties that the current system can return. No exceptions are thrown.
Properties can include the following array:
['name', 'tel', 'email', 'address', 'icon']
Reference: https://developer.mozilla.org/en-US/docs/Web/API/ContactsManager/getProperties
Q. What is the user experience of the Contact Picker API in terms of speed, responsiveness, and handling load?
These questions make sense to be answered together, the Contact Picker API is pretty fast since it uses the device’s native interface, and it feels instantaneous even with a big amount of data. It uses the device’s cached contacts, so no matter the size of your contact list, it will access the cache and return it almost immediately, if you sync your contacts again, you will have to close the Contact Picker, and open it again, so the new contacts show up in your list, not something that makes the experience worst, but something which I consider expected in a mobile device.
Q. How much effort would it be to add a Contact Picker API source to the CloudSponge product?
We don’t need an authentication system for Contact Picker API, and we also don’t need and UI for it, since it uses the device’s native interface, we only need to use Contact Picker API to launch the device native interface so the user can manually select the contacts, and after this step, we need to format the output to fit the CloudSponge Contacts Format.
The implementation can be straightforward, with most or all code on the client side, the focus will be to ensure we are collecting all metrics we provide for our customers, which we will be able to do except for the number of contacts in the address book, because this information is limited by the Contact Picker API.
We’ll explore this in more detail in the next article describing the integration with the CloudSponge Contact Picker.
Q. Are there any UX/UI conventions that we should consider adding to the CloudSponge Contact Picker?
Right now, the CloudSponge Contact Picker has a complete interface, which covers all features of the Native Contact Picker and adds functionalities like the select all contacts option. We could incorporate some UX/UI changes in there to make it match the style of the Native interface and look more familiar to a smartphone user. It would also require two different styles, one for Android devices, and another for iOS devices. Besides the visual benefit of making the interfaces mimic the native interface and look more familiar to the users, there is nothing else that could improve the current appearance of the CloudSponge Contact Picker. Said that I also like the idea of the user being able to differentiate when he is using the native interface, and when he is using the web interface. So I would not change our current interface right away.
Q. What icon/name would make sense for users to identify the address book source?
The Contact Picker API doesn’t have an official logo, so we could use the default icon for contacts for each platform, so we could use the Android Contacts icon for Android devices, and the Contacts iOS icon in case of iOS devices.
Q. What is the overall impression of the Contact Picker API?
My overall impressions of the Contact Picker API are that it is a robust, simple, and straightforward API, it solves the problem it decides to approach in the simplest way possible, with just two methods.
It is also privacy-focused, and reliable because it forces the users to be aware of the data they are sharing, requiring them to consent first before any data is provided.
It is fast since it does not access external interfaces, it only has access to the contacts already cached in the device, it is very responsive, and feels like a native device experience (because it is).
Q. Should we add an integration to CloudSponge?
Adding the Contact Picker API, even in the experimental stage, would be a welcoming addition to the CloudSponge sources list. It will have some limitations compared to other sources we integrate with, but it will also give the CloudSponge users easier access to their most significant contacts.
Since the Contact Picker API only accesses local information, it would not require authentication, and it would be one of the faster ways to grab contacts the user is interested in sharing some information with.
Q. What are the concerns we must have about privacy and security?
Again, the data Contact Picker API access is locally cached data, the user has the control, and there is no way to automate the contacts selection, so I would say the only security concerns are the ones we are already applying to any other source.
After collecting the data, we will not store or use it for any purpose the owner didn’t have agreed on.
All the other security measures were already taken by the team that built the Contact Picker API.
Code Experiment
I answered all these questions after going through the documentation, articles, and code I found about the Contact Picker API, the sources are all listed in this and the previous article.
Also, in the previous article, I mentioned after I had done my research and tested myself the API, I would share the results with you, so I’m listing them below:
This is my first attempt using the Contact Picker API, I used Glitch to build it following some samples I mentioned in the previous article and using Javascript, if you decide to test it by yourself, do not forget this API is meant to work only in Mobile devices:
Live Preview: https://congruous-scratch-cork.glitch.me
Code: https://glitch.com/edit/#!/congruous-scratch-cork
After some tests, I decided to build an NPM package with Typescript to wrapper the Contact Picker API utilities, and make it even easier to use in your projects. It was built thinking of being able to be used in ES6, React, and CJS projects. And we will use it to Integrate the Contact Picker API into CloudSponge sources. With the NPM Package code, I included a really simple example of a React app using it. It will be publicly available to anybody who uses it:
https://github.com/cloudsponge/contact-picker-ts
Conclusion
This whole experiment was very interesting to do, I hope I can help someone to better understand the Contact Picker API with it, this was for sure helpful to me.
After this time studying and testing the Contact Picker API, I do not understand why it is still considered an experimental technology and does not receive more support, maybe because of the resistance of some players, but if you are using a newish Android device I consider it safe to use, I would like the support of iOS to be better, or at least not behind a feature flag, so more people can benefit from it, maybe it can happen sooner than later.
If you found this article interesting and want to know more, you can read these three other articles about it (contacts really matter to us here in CloudSponge):
- Chrome Address Book and Google Contact Picker Explained
- Mobile Address Book and Contact Picker API Experiment
- Mobile Address Book and Contact Picker API Integration
Feel free to drop me a note at alfredo(at)cloudsponge.com or on my X account mentioned below.
