I believe this is why we offer a paging API for it. Especially on Android, this API is slow. We use a standard native implementation to fetch these, we aren’t doing anything special or different which would add extra slowness.
I think what we want here is a way to query the contacts without having to load them all into memory. I created a feature request for this here: Query contacts | Voters | Expo
Currently I’m using a FlatList to display contacts. It is slow, because my users want a sorted list (don’t blame them). This requires retrieving all of them in one go, because the current API does not sort them.
This slowness basically makes the API useless to me, I am now resorting to creating my own contact list, and trying to keep it in sync in the background, which is quite an ordeal frankly.
Ran into the same issue last days. The paging API is only useful if it returns sorted list values. Otherwise people always need to fetch the whole thing, sort them and show them or make another pagination. Haven’t found a proper solution for this yet.
I dont understand native code well enough, but I think this stackoverflow solution shows that there may be a way to make this quicker on Android. I am also pulling in all the users contacts in my app at once. On iOS it is quick but on Android it runs slowly.
Here is the solution I found:
For my app only the email, phone number and name is necessary too. Maybe an option to select only what is needed could make this faster?
@notbrent Yes I am using the fields option, but when I log the resulting object, even though I am only asking for the email and phone number I get a very large object with other default keys. The fields option seems to be tacking on addons to a large default object
I was wondering if instead we could just call the fields we want and we would only get that, if that would make the api call faster
I suspect a lot of us actually just want to get the user to select one contact.
So, if Expo exposed contact picker API then, for those users, it would eliminate the problem being discussed here, eliminate the need for all of our contact management code (and saving the contacts), and reduce related privacy concerns.
I love using Expo but this really slow read of android contacts is a showstopper for us. Is there any chance that someone will work on this problem soon?I’d love to contribute by hiring someone to work on this, what specific skills should I be looking for?
disclaimer: not part of expo team and above is not meant to be a confirmative statement, expecting continued good collaboration with expo for quick integration of the optimizations
The PR mentioned above is set to be merged and should be released with SDK27 so when we release that, there will be performance improvements to the Android Contacts API. We don’t have a date or estimate of when that will be so follow our blog on Medium or follow us on Twitter so you know when we roll out SDK27.
Just wanted to add another friendly voice to the chorus of folks who have the same challenges as (username)izzusan and (username)heresmyinfo (not allowed to tag many people people bc I’m new) regarding android-contacts loading. We will hold our app’s release due to this bug and are excitedly awaiting the release of 27.
Also wanted to say special thanks to @tiny-dancer for working this issue as it’s so critical for us right now, and we are happy to have found it will be resolved in this next release.