You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 2, 2021. It is now read-only.
There seems to be a problem with the current usage of the library, people is often surprised with the Only one Dexter request at a time is allowed exception and are forced to write a snippet similar to:
if (!Dexter.isRequestOngoing()) {
Dexter.checkPermission(someListener, Manifest.permission.RECORD_AUDIO);
}
We can simplify the library usage by removing the exception and notifying an optional callback if there is a problem instead of forcing everyone to handle that scenario. Adding a new parameter to every Dexter method to pass the optional callback seems to be a non-scalable option but the only one compatible with the current implementation.
Thoughts are welcome!
The text was updated successfully, but these errors were encountered:
I'm new to Dexter, and have not much experience with Permissions Management in 6, but I face this issue as well.
Sometime I need to request the permission to continue the user scenario, but I can't because another permission has not been resolve by the user (put in background, still not sure if this is WAKE_LOCK permission or FLAG_KEEP_SCREEN_ON feature).
In some use case, I need to force request, and cancelling others. If that would be possible.
eg : the user ask taking photo, but dexter is requesting something else on a service/application/activity
There seems to be a problem with the current usage of the library, people is often surprised with the
Only one Dexter request at a time is allowed
exception and are forced to write a snippet similar to:We can simplify the library usage by removing the exception and notifying an optional callback if there is a problem instead of forcing everyone to handle that scenario. Adding a new parameter to every Dexter method to pass the optional callback seems to be a non-scalable option but the only one compatible with the current implementation.
Thoughts are welcome!
The text was updated successfully, but these errors were encountered: