Hi! Can anyone recommend a good permissions library? https://github.com/QuickPermissions/QuickPermissions-Kotlin perhaps?

Splitties Permissions (I'm the author): https://github.com/LouisCAD/Splitties/tree/master/modules/permissions

bookmarked, thanks!

Be sure to always test with the dev settings do not keep activities.

@Tolriq sorry, not sure what you mean exactly?

It's a Android settings to see how you app behave when your activity is destroyed as soon as you leave it (Can happens on low end devices and some chinese devices) see https://medium.com/@elye.project/dont-keep-activities-alone-is-not-enough-for-testing-407b7c01bd60

@Tolriq Mine does, you can check it.

Looking at the code it have the same flaw, it works when you secure a complete activity and do the check at each creation. Now take a simple example of an activity with a button that button checks the permission then show a dialog to change a setting related to that permission. User press the button permission is shown activity is closed, callback is never called.

@Tolriq There's a lot of "buttons" you mention that I fail to get where they are from. Anyway, I tested with "Don't keep activities" when developing it, and I got two bugs, one from not handling empty permission request result, and one from Android Activity in an inconsistent state, now unable to request further permissions. I found a solution for that, and you can TEST that it works, instead of judging by glancing over the code (there's a ready example in the sample). And if it's not working, I'm eager to have the reproducing steps in a new issue or here.

@louiscad I'm not judging and you do not have to be aggressive you know 🙂 And I've just told you the example: A simple activity that have a button in it in that button onclicklistener you use any of the functions to request permissions that will look like ensurePermission(permission) { doSomething() }. If you do not keep activities or rotate the phone while the permission dialog is shown then the doSomething() is not called as it can't be called and even if by forcing the activity to keep references and not be dead, on rotation if dosomething access view then crash. This is just a simple fact about how Android works. Sorry if you misunderstood what I wrote I thought it was pretty clear and self contained example.

@Tolriq I'm saying you're judging the code without testing it, I don't mean to be aggressive or claiming you're being personal, no worries. The

ensurePermission

function is suspending. You're supposed to call it from a scope that is cancelled with the lifecycle. That means when your activity is recreated, if the permission prompt is still visible and the user grants it just after, you'll not know, so you'll ask again (for example when the user clicks the button), and here, you'll see the permission has been granted. Android makes it impossible for developers to provide a better UX without adding another layer of spaghetti code, to remember that you were requesting a permission that you might get the callback from, maybe, if you're not falling into the case of empty permission request result where the activity is no longer able to request permissions and you need a new one. So, I'm encouraging you to test the sample in Splitties permissions, because that way, you can witness the UX that users get in the very rare case of activity being destroyed while requesting a permission, and you can see how the library ensures your app can continue to work and request the permission again if needed, or pass when granted.

There was nothing to test as it's simple facts. I never said that it did not allow to request again or anything wrong about your library, I'm just explaining facts to the thousands of people that are not aware of the subtleties of Android. (That guy did not even know what that option was). So yes your library allows to request again, but if the app is killed 100% of the time then the code is never called. And this is something that thousands of people will not see in dev and will face when in prod and users complains. So let me continue to disagree, no suspending / callback based solution works at 100% and properly handle activity kills. And yes fixing this at library side is really complex but people needs to know that there's limits to this and that it's not a simple yes my library support don't keep activities, this is misleading. As from my point of view this is false due to some cases where it does not do what the dev can think it would do. And this is also true from user point of view. Click a button, grant permission then nothing happens? Bad user UX sorry.

@Tolriq Do you handle it better than Splitties permissions do for real in your apps? Can you reproduce that "bad UX" that can make a user in edge cases have to click a button twice? I'm honestly uninterested in little problems that have no realistic solutions, so that's why I'm asking you that.

I abandoned the idea and use the normal onRequestPermissionsResult and the bad UX can be repro easily just rotate the phone when the permission dialog is shown and see that the callback is not called. To improve your library you could keep a weak reference to the caller and accept an optional string to be called when caller is removed before callback is called then show a toast / dialog showing that string that could say permission granted do the action again. But as said this is nothing about your library this is just that it can't work due to Android and that less experienced devs will fall into that trap easily as it's nowhere explained that the callback won't be called if activity not kept or issues can arise when rotating the phone.

That's something you can already do with `try`/`catch` to detect cancellation on the call to

ensurePermission

. Also, you can remember you were requesting a permission using saved state, and call

ensurePermission

and the rest again on activity recreation. Now that AndroidX saved state is stable, I might try that in the sample when I'm done with way more important things.

The try catch does not work as it happens with the request permission dialog over and you do not yet have the result. And yes you can remember thing + save state + check save state + call again, there's many ways to workaround the issue, but for that people needs to be aware that there's an issue and it's still complex workaround that can be badly implemented by the dev.