3 ms·
My point remains valid. If OS is handling contacts it should have some sort of control over what's getting shared. Theirs no point of providing alternate ways i
by anthropodie 6y ago
My point remains valid. If OS is handling contacts it should have some sort of control over what's getting shared. Theirs no point of providing alternate ways if an app can access full list of contacts.
- viraptor 6y agoYou need a migration path and backwards compatibility. They can't kill all the apps which used the old system.
- MiddleEndian 6y agoThey can just lie to the old apps. Tell them they're getting the full list when the API is called.
- LeifCarrotson 6y ago"Yep, this user has exactly one contact, and gee, it happens to be the one they're calling now, how fortuitous! They had a different single contact yesterday, but apparently they've deleted that one and added this one."
- MiddleEndian 6y agoIf the devs update the code to respond to fake entries, then the program is no longer out of date and thus no longer in need of backwards compatibility.
- lucb1e 6y agoPrivacy Guard in Cyanogenmod used to do this I think, at least to fake the list to be empty. It somehow still broke a tiny number of apps (unintentionally, i.e. the app owners didn't purposefully add code to annoy those users) so there seems to have been some flaw between 'empty list with permission granted' and 'empty list with permission not granted'. Regardless, I'm not sure why this didn't become mainline Android aside from that it would come with no benefits to the main developer of Android.
- MiddleEndian 6y agoFor backwards compatibility, they could just put in some nonsense entries. If the program can figure out those entries are nonsense, it's no longer out of date and it's on them. Why they didn't do this by default is anyone's guess. Maybe they like app devs more than users. More technology should lie on users' behalf.
- lucb1e 6y agoSure sure, I was just saying that this sort of thing already existed in the past (in Cyanogenmod, and that it worked well for 99% of apps even without providing wrong data) but other vendors or even mainline Android never picked it up unfortunately.
- viraptor 6y agoWhat if the app caches some (or fragments of) entries for some good reason? If you're unaware you're getting only one requested contact each time you may be triggering edge case behaviour. What if you have reasonable time-out behaviour which triggers each time now while user chooses which contact to expose to the app? What if the contract list is polled in the background, or when you receive a message to match it up with the right source?
- zibzab 6y agoThat is a very odd take away. The first method is good to have for apps you trust, and requires permission from the user. https://developer.android.com/guide/topics/permissions/overview https://developer.android.com/guide/topics/permissions/overv... The second method is what you want with apps you don't yet fully trust or for some other reason don't want to give direct access to your contacts. https://developer.android.com/training/permissions/evaluating https://developer.android.com/training/permissions/evaluatin...
- LeifCarrotson 6y agoWhy would an app developer ever think their own app should use the method reserved for untrustworthy apps? All incentives suggest the developer should prevent using the app without full permissions being given (basically force the user into giving permission) and only implement the first method.
- zibzab 6y agoBecause it would be easier for the users and allow some customization you can't otherwise have? Sure it can be abused, but there are also legit use cases
- MrDresden 6y agoWhile I get where you are coming from, but giving that option is a design flaw. As Android developers, we should only be given one pipe to consume from. The system should then present the user with the ability to choose if that pipe for this particular application is going to be: "All contacts" / "A subset of contacts" / "No contacts And even better yet just "A subset of the values for a subset of contacts"