4 ms·

What if core features of the app rely on the permissions? Is the onus on the app developer to build checks for permissions or on the user to realize the app isn

What if core features of the app rely on the permissions? Is the onus on the app developer to build checks for permissions or on the user to realize the app isn't working the way it should because they disabled some permissions?

moron4hire 14y ago
I see nothing wrong with making developers check for features before using them. Should be used to it, with the variability of platforms.
vasco 14y ago
The app would define core features and nice-to-have features. The user would be able to disable the nice-to-haves. Admittedly this just pushes the problem one layer down because Facebook would just make everything part of the core and force people to install. And now the user would have the burden of trying to figure out what was going on.
atesti 14y ago
The best use case for oneself would be if missing features are emulated with dummy data using some app-firewall tool. The phone should give any app no chance of finding out, whether e.g. address book access was granted, but instead show fake data. Of course this would soon be a cat and mouse game if Google really implemented it for everyone: Developers like WhatsApp would check the address book data whether it is statistically sound and if not they would request you to grand access for real, etc. All the permissions only required for ads (like position, IMEI, full internet access, reading sms, reading address books) would also just have the app terminate if it's not possible, just like today they check for rooted devices based on tools like bash or they check for modified hosts files that block ads.
jyap 14y ago
On iOS the onus is on the developer.
krschultz 14y ago
As a full time Android developer, I can tell you that wouldn't be a burden. First off, there are already lots of places you have to handle compatibility based on the version of the phone, intents available from other apps installed on the phone, or capabilities (even something as basic as a phone can't be guaranteed if you support tablets). Obviously you can turn small things on and off in a block of code with if statements, but you can handle major changes with the Fragment model. If you have a drastically different UI due to a missing intent/permission/API feature you can actually ship the app with 2 different Fragments and decide which one to show at runtime. As an aside, I turned off auto-updating for Facebook and will not upgrade from here. Too many permissions, too intrusive to the UI. I have deleted Facebook from my phone before and I'm fine without it now.

moron4hire 14y ago

I see nothing wrong with making developers check for features before using them. Should be used to it, with the variability of platforms.

vasco 14y ago

The app would define core features and nice-to-have features. The user would be able to disable the nice-to-haves. Admittedly this just pushes the problem one layer down because Facebook would just make everything part of the core and force people to install. And now the user would have the burden of trying to figure out what was going on.

atesti 14y ago

The best use case for oneself would be if missing features are emulated with dummy data using some app-firewall tool. The phone should give any app no chance of finding out, whether e.g. address book access was granted, but instead show fake data. Of course this would soon be a cat and mouse game if Google really implemented it for everyone: Developers like WhatsApp would check the address book data whether it is statistically sound and if not they would request you to grand access for real, etc. All the permissions only required for ads (like position, IMEI, full internet access, reading sms, reading address books) would also just have the app terminate if it's not possible, just like today they check for rooted devices based on tools like bash or they check for modified hosts files that block ads.

jyap 14y ago

On iOS the onus is on the developer.

krschultz 14y ago

As a full time Android developer, I can tell you that wouldn't be a burden. First off, there are already lots of places you have to handle compatibility based on the version of the phone, intents available from other apps installed on the phone, or capabilities (even something as basic as a phone can't be guaranteed if you support tablets). Obviously you can turn small things on and off in a block of code with if statements, but you can handle major changes with the Fragment model. If you have a drastically different UI due to a missing intent/permission/API feature you can actually ship the app with 2 different Fragments and decide which one to show at runtime. As an aside, I turned off auto-updating for Facebook and will not upgrade from here. Too many permissions, too intrusive to the UI. I have deleted Facebook from my phone before and I'm fine without it now.