4 ms·

The way permissions work, the difference between reading 0 contacts where the contact list is empty, and reading them with a disabled permission, is that the la

The way permissions work, the difference between reading 0 contacts where the contact list is empty, and reading them with a disabled permission, is that the latter throws an exception. You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled. In fact, I'd love to have the ability to block reading of contacts from all apps except ones I explicitly allow. It's the more basic "INTERNET" permission that is core to monetizing apps that I take umbrage with blocking; if someone is using my contacts somehow to monetize their app, that's not cool, and I absolutely wouldn't want to use an app that did that.

MaulingMonkey 13y ago
> You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled. ...or to write your own wrapper which does the same by handling the exception, and to then exclusively use that wrapper in your client code.
- SomeCallMeTim 13y ago
  It's not just one case of "query for contacts" I'm talking about. One permission is trivial to test for. But if we're going with my example of eight permissions, then you probably have 24+ calls in various places in your code, some of which relying on others. Catching the error isn't even half the battle, either. If you want the app to "work," you need to explicitly test the full set of permissions any particular block of code might need prior to enabling aspects of your UI that require them, or your app is going to behave badly. At best, your proposed solution would prevent the app from crashing, though it could still get into a bad state -- a non-modal dialog waiting for a particular result could never be closed, for example, because of an unexpected throw that skipped over the proper cleanup code. Yes, that code SHOULD be in a finally{} clause, but what if you missed something? I'm an awesome developer in a lot of ways, probably even a 10x+ developer, but I don't consider myself perfect. Do you? Have you developed apps for Android as an indie developer? Or for iOS? How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings? How likely is it that you'd successfully handle all 255 extra permutations with no real testing? And don't think unit tests would solve the problem: You'd really need full functional and UI tests, probably with a human to really be sure that you're covered. Some apps really don't work without certain permissions (say an Internet chat app with no INTERNET permission), so be sure you have reasonable error messages that explain to the user that the app can't work if you don't give it the right permission. And word the message so that your average non-techie will understand it, or be prepared for lots of negative ratings with "app doesn't work! uninstalled!" comments. No, making it easy for people to kill permissions on an app is the wrong answer. Giving developers the ability to optionally query sets of permissions reduces the complexity from exponential to constant, and allows for optional features to exist in an app.
  - MaulingMonkey 13y ago
    > I'm an awesome developer in a lot of ways, probably even a 10x+ developer, but I don't consider myself perfect. Do you? I don't consider myself a 10x developer, nevermind a perfect developer. But I still think you're continuing to overstate the difficulty of minimizing the combinatorial effects and general difficulty of handling missing permissions. You can certainly make a herculean task out of it if you want to, however. > Have you developed apps for Android as an indie developer? Or for iOS? Depends on how you're defining both "developed apps" and "indie". > How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings? While I certainly wouldn't relish platform mandated "busywork" as a developer, I've seen much worse and much more pointless work than such. > How likely is it that you'd successfully handle all 255 extra permutations with no real testing? How likely is it that you'd successfully handle all execution of your app even with real testing? For anything sufficiently complex, statistics will eventually catch up with you, and your chance will, when rounded, come to a nice and magical number... nil. Zero. Mistakes will happen, complexity will happen, and removing features in an attempt to prevent the inevitable from eventually striking is the wrong answer. Don't get me wrong, permissions sets are a fine way to help reduce that complexity without necessarily harming the other goals. And it'd be nice to have it done for you. And it'd be nice to have it done as atomic sets. But I remain unconvinced it's unreasonable to manage without those niceties. ( although as a matter of personal taste, if I want to kill INTERNET and just read my chat app's logs or settings I'd like to be able to do that -- and can at the OS level by turning off both mobile data and wifi, your monetization strategy be damned.)
    - SomeCallMeTim 13y ago
      >Depends on how you're defining both "developed apps" and "indie". Spent time (and money) on your own initiative to develop an app that's been published in the Android and iOS stores. I spent my own time developing a game that's in the Android and iOS app stores. > How likely is it that you'd successfully handle all execution of your app even with real testing? My point wasn't about bugs. My point was about execution path coverage: If code has never been hit, then it may contain hidden bugs. And if I'm doing things right, 100% of the code would be executed in testing. There are techniques to specifically track code coverage, so you don't need to wonder whether a code path has been triggered, but in general I don't write code and then never execute it. > But I still think you're continuing to overstate the difficulty of minimizing the combinatorial effects and general difficulty of handling missing permissions. It's your right to believe as you will.

MaulingMonkey 13y ago

> You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled. ...or to write your own wrapper which does the same by handling the exception, and to then exclusively use that wrapper in your client code.

SomeCallMeTim 13y ago
It's not just one case of "query for contacts" I'm talking about. One permission is trivial to test for. But if we're going with my example of eight permissions, then you probably have 24+ calls in various places in your code, some of which relying on others. Catching the error isn't even half the battle, either. If you want the app to "work," you need to explicitly test the full set of permissions any particular block of code might need prior to enabling aspects of your UI that require them, or your app is going to behave badly. At best, your proposed solution would prevent the app from crashing, though it could still get into a bad state -- a non-modal dialog waiting for a particular result could never be closed, for example, because of an unexpected throw that skipped over the proper cleanup code. Yes, that code SHOULD be in a finally{} clause, but what if you missed something? I'm an awesome developer in a lot of ways, probably even a 10x+ developer, but I don't consider myself perfect. Do you? Have you developed apps for Android as an indie developer? Or for iOS? How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings? How likely is it that you'd successfully handle all 255 extra permutations with no real testing? And don't think unit tests would solve the problem: You'd really need full functional and UI tests, probably with a human to really be sure that you're covered. Some apps really don't work without certain permissions (say an Internet chat app with no INTERNET permission), so be sure you have reasonable error messages that explain to the user that the app can't work if you don't give it the right permission. And word the message so that your average non-techie will understand it, or be prepared for lots of negative ratings with "app doesn't work! uninstalled!" comments. No, making it easy for people to kill permissions on an app is the wrong answer. Giving developers the ability to optionally query sets of permissions reduces the complexity from exponential to constant, and allows for optional features to exist in an app.
- MaulingMonkey 13y ago
  > I'm an awesome developer in a lot of ways, probably even a 10x+ developer, but I don't consider myself perfect. Do you? I don't consider myself a 10x developer, nevermind a perfect developer. But I still think you're continuing to overstate the difficulty of minimizing the combinatorial effects and general difficulty of handling missing permissions. You can certainly make a herculean task out of it if you want to, however. > Have you developed apps for Android as an indie developer? Or for iOS? Depends on how you're defining both "developed apps" and "indie". > How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings? While I certainly wouldn't relish platform mandated "busywork" as a developer, I've seen much worse and much more pointless work than such. > How likely is it that you'd successfully handle all 255 extra permutations with no real testing? How likely is it that you'd successfully handle all execution of your app even with real testing? For anything sufficiently complex, statistics will eventually catch up with you, and your chance will, when rounded, come to a nice and magical number... nil. Zero. Mistakes will happen, complexity will happen, and removing features in an attempt to prevent the inevitable from eventually striking is the wrong answer. Don't get me wrong, permissions sets are a fine way to help reduce that complexity without necessarily harming the other goals. And it'd be nice to have it done for you. And it'd be nice to have it done as atomic sets. But I remain unconvinced it's unreasonable to manage without those niceties. ( although as a matter of personal taste, if I want to kill INTERNET and just read my chat app's logs or settings I'd like to be able to do that -- and can at the OS level by turning off both mobile data and wifi, your monetization strategy be damned.)
  - SomeCallMeTim 13y ago
    >Depends on how you're defining both "developed apps" and "indie". Spent time (and money) on your own initiative to develop an app that's been published in the Android and iOS stores. I spent my own time developing a game that's in the Android and iOS app stores. > How likely is it that you'd successfully handle all execution of your app even with real testing? My point wasn't about bugs. My point was about execution path coverage: If code has never been hit, then it may contain hidden bugs. And if I'm doing things right, 100% of the code would be executed in testing. There are techniques to specifically track code coverage, so you don't need to wonder whether a code path has been triggered, but in general I don't write code and then never execute it. > But I still think you're continuing to overstate the difficulty of minimizing the combinatorial effects and general difficulty of handling missing permissions. It's your right to believe as you will.