Question about "Must be done during an initialization phase like onCreate"
vanniktech opened this issue · 15 comments
Why do I need to get the instance of RxPermission in a phase like onCreate? Since internally it uses the ApplicationContext isn't the activity lifecycle irrelevant?
You don't need to get the instance of RxPermission during an init phase, it's required when you invoke methods from that instance.
So basically when calling request, ensure or the methods alike of RxPermission I need to have an activity that is visible?
So basically when calling request, ensure or the methods alike of RxPermission I need to have an activity that is visible?
Main point is not that your activity should be visible, but that you have to invoke these methods during initialization phase (i.e. onCreate()/onStart() in Activity, etc.)
For example, if you call request() and subscribe to observable in OnClickListener of some button.
User taps button, and permissions request is started.
If during permissions request activity is recreated (i.e. due to configuration changes), then code in you click listener is not executed again and you don't subscribe to observable - permissions request result is lost.
But if you subscribe to observable during init phase, then in case of activity recreation, you'll resubscribe, and receive result from observable.
Alright that makes it clear. Maybe this should be added to the README.
That requirement is due to the permission request dialog, which is displayed by the framework when you call request/ensure and the permission is not granted or not denied permanently. If an activity recreation occurs when that dialog is displayed, then the dialog is restored but there's absolutely no way to get that information from the framework.
The only solution is so to invoke the request/ensure in a init phase, and in that case there's a little complex mechanism, which detects pending permission requests.
That requirement is clearly the ugliest thing in that library, and there is a long thread about that in #3, but despite the intervention of famous android developers, no better solution could be found.
From my side this issue could be closed. It's up to you whether you want to update the javadoc and README or not.
I linked this issue in the readme.
The sample app has the subscription in onCreate() but no corresponding call to unsubscribe(). Does it matter that the subscription is leaked here?
Permission dialog opened twice when calling method request() in onCreate() .
I enabled "don't save activity" mode in developers options in settings.
How i can resolve this problem?
After the first call of the Call_Phone cell phone Note2, the application exit
@tbruyelle I am evaluating using this library on my App, but this "only use it in onCreate" restriction is VERY limiting.
My app gets the user location only after there's a user click on a button, so the Fragment onCreate is long gone at that point.
Also, even if I could get the permission in onCreate, the user could revoke the permission later, and I would have to ask again for the permission, which would be when the app has been created already.
How do you guys deal with this so common scenarios? Am I missing something?
@feinstei our team have got no problems with such scenarios. The only thing you should keep in mind it's dispose your subscription to RxPermission observable in onStop (actiually we dispose all of our subscribtions in onStop). And you're good to go. Nothing bad should happen, because views won't be touched. And you shouldn't ever get java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState as we totally forgot about it. At all.
Very quick example of what I'm talking about could be found here
Is it okay to use onPostCreate?
BUG 主体布局使用vierpager2+Fragment出现错误 java.lang.IllegalStateException: FragmentManager is already executing transactions
该如何解决?
FWIW I can reproduce this even if the system decides to not show the system permission dialog. (i.e. Android OS is still pausing my Activity, and thus Fragment, every time I request permission. Following advice in the readme fixed the problem