Configurable authorization level (iOS) #26
Conversation
There was a problem hiding this comment.
👋 Thanks @tyronet-sportsbet! This implementation looks really good. I like that it solves the issue people are having in a nice backward compatible way.
I've added one suggestion for changes to the types, just in case someone wants to explicitly use the auto behaviour without getting type errors.
After those are in and the tests are passing, I will merge and release this 👍
|
The CircleCI errors look to be the usual Android flakiness. They should pass when you push the changes 👍 |
|
Thanks for the very quick response @matt-oakes ! I've made the requested changes, and as you predicted, the checks have passed 😄 |
|
Thanks, this looks great! Merging and releasing now |
# [1.2.0](v1.1.0...v1.2.0) (2019-04-18) ### Features * **iOS:** Configurable authorization level on iOS ([#26](#26)) ([a9939cc](a9939cc))
|
🎉 This PR is included in version 1.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Overview
As per comments in the react native issue 20879 thread, some organizations just want "when in use" permissions. However, because react native (and this library!) reference the
requestAlwaysAuthorizationselector, Apple requires us to include theNSLocationAlwaysUsageDescriptionin our Info.plist. We're happy to provide this key in ourInfo.plist, butreact-native-geolocationshould NOT always assume that means we want that permission, with no way to override it!There are workarounds in that thread that involve applying patches that rewrite react native code to not reference that symbol. This is not a workable long term solution, in our specific case we have additional closed-source third party dependencies and some of them may reference this
requestAlwaysAuthorizationselector as well.A solution that solves for all cases is to have the ability for the application to override the authorization level requested from CoreLocation. This PR implements that. I have added an additional configuration option to the
setRNConfigurationGeoConfigurationobject:authorizationLevel, which when provided will allow you to override which location services authorization level your application requests from the user. Two possible values,alwaysandwhenInUse.Test Plan
A unit test here would need to be in the Objective-C side and I couldn't find any so in the absence of that, I've manually tested it:
authorizationLevelkey -> maintains old behaviour: it does.authorizationLeveltowhenInUse-> requests "when in use" permissions: it does.authorizationLeveltoalways-> requests "always" permissions: it does.Fixes #25