Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

watchPosition doesn't raise an error if the user disables location services #53

Closed
yoshikischmitz opened this issue Jan 9, 2019 · 6 comments

Comments

@yoshikischmitz
Copy link

When a user opens the app with location services enabled, and the app then registers a watchPosition callback, and then the user disables location services, and goes back to the app, watchPosition never raises an exception. React Native core's navigator.geolocation has this same issue, but I would expect watchPosition to raise an exception the same way that getCurrentPosition would. This would be useful for detecting that location services are off so the app could prompt a user to reenable it.

@oakis
Copy link
Contributor

oakis commented Jan 9, 2019

I think this is what you are looking for:
https://facebook.github.io/react-native/docs/permissionsandroid

@Agontuk
Copy link
Owner

Agontuk commented Jan 13, 2019

You mean the error callback is not triggered ? That seems like a bug, I'll look into it.

@yoshikischmitz
Copy link
Author

@Agontuk yes the onError callback on watchPosition is not triggered. To be clear, the onError callback on getCurrentPosition does get triggered.

@avasuro
Copy link

avasuro commented Mar 28, 2019

Same issue.
And in addition: If I run my application with disabled GPS, then i click "No thanks" on request to turn GPS on (after that errorCallback is triggering), and then I manually turn GPS on - nothing happens after that (I expect that successCallback should be triggered).

@ThePJMP
Copy link

ThePJMP commented Dec 2, 2019

@Agontuk is there any update on this issue?

@Agontuk Agontuk pinned this issue Mar 27, 2020
@Agontuk
Copy link
Owner

Agontuk commented May 30, 2020

It should be fixed in v5.0.0. Sorry for not being able to fix this sooner.

@Agontuk Agontuk closed this as completed May 30, 2020
@Agontuk Agontuk unpinned this issue May 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants