fondesa/kpermissions

Listener not called when selecting Allow

AlaaZarifa opened this issue · 7 comments

Description

My main goal is to auto open the gallery after the user clicks allow in case the permissions are not allowed.

The usage sample in README.md doesn't achieve this, because after I click allow, the dialog dismisses but the gallery doesn't open unless I click on the button again.

I tried to solve the problem using listener and based on this Issue #27 But it didn't work.

KPermissions version: 3.1.2

API level: 29

Sample code:

val kPermission = permissionsBuilder(
           Manifest.permission.WRITE_EXTERNAL_STORAGE,
           Manifest.permission.READ_EXTERNAL_STORAGE
       ).build()

       kPermission.addListener {
           if (it.allGranted()) getContent.launch("image/*")
       }

       binding.editButtton.setOnClickListener {
           kPermission.send()
       }

I tried to reproduce the bug you described with no success.

  1. Can you try to replace getContent.launch("image/*") with something like Log.e("KPermissions", "granted") and see if it's logged or not?
  2. Does it happen also on other API levels?
  3. Can you try to reproduce the same bug using the working sample of this project? You can clone/fork the project and update MainActivity.kt

@fondesa sorry for the very late reply.

  1. I've added the log, but it didn't show up when click allow. but it did when I click again.
  2. I didn't test it on other API levels.
  3. I've made a new project with a basic sample so you can test the issue. it's a private repo, but I sent you an invite.
    here's the link https://github.com/AlaaZarifa/kpermissions-test

Hi @AlaaZarifa, debugging your project, I've found the bug. That's VERY interesting. I can fix it on my side and release an update to the library when it will be ready, thanks for the sample.

@AlaaZarifa For the moment, you can workaround it in your app, inverting the order of the permissions READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE. See the last commit I've pushed to your private repo.

Fixed in #160

Released the version 3.1.3 which fixes the bug.
Feel free to re-open this issue if the bug is still happening.

@fondesa it's a very interesting bug indeed.! 3.1.3 works with no issues now 👍