4 ms·
It does sound like they're batch-copying the entire contact book into their app at startup, rather than using the Android contact picker. The static analysis pr
by jsnell 4y ago
It does sound like they're batch-copying the entire contact book into their app at startup, rather than using the Android contact picker. The static analysis problem of determining whether there is / isn't a batch import seems a lot easier than determining with certainty what happens with the contacts after they were saved to disk.
Though the article doesn't actually show any screenshots from the review emails, but just paraphrases them, so we don't even know that their interpretation of the rejection reason is correct.
- TheNorthman 4y agoThis could, of course, be an explanation. Except for the _stated fact_ that after they removed the batch import, they were still rejected.
- jefftk 4y agoI don't see where they say they removed batch import? Just that they removed caching. I don't think they're using the default contact picker?
- tadfisher 4y agoJust to clarify a few things: "Batch import" is querying the system Contacts Provider [0] with essentially a "SELECT *" query. This requires the READ_CONTACTS permission, which is granted by the user via a runtime permissions dialog. "Batch import" under this definition includes the use case of displaying the contacts list in the app's UI, regardless of whether that list is cached offline or uploaded somewhere. The "contact picker" is an Intent the app sends to the system contacts application, which then returns a single contact. The UI is handled by the contacts app, filtering options are limited/non-existent, and there's no way to display app-specific metadata. It also requires no permissions. [0]: https://developer.android.com/guide/topics/providers/contacts-provider https://developer.android.com/guide/topics/providers/contact...