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
feat(ios): expose new APIs to use location AccuracyAuthorization #11813
Conversation
Tests:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. My review comments are just suggestions, not required.
description: Will be undefined if `error` is `true`. | ||
optional: true | ||
type: Number | ||
constants: [Titanium.Geolocation.ACCURACY_AUTHORIZATION_FULL, Titanium.Geolocation.ACCURACY_AUTHORIZATION_REDUCED] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing newline at EOF
@@ -244,7 +246,52 @@ describe.windowsBroken('Titanium.Geolocation', function () { | |||
should(Ti.Geolocation.trackSignificantLocationChange).be.true(); | |||
}); | |||
|
|||
it.ios('.ACCURACY_REDUCED', function () { | |||
if (OS_VERSION_MAJOR >= 14) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we define these special filters like it.ios
, where it skips on other platforms. It may make sense to expand to add ones like it.ios14Plus
because technically we'd want to skip on older versions, not have a no-op test that always passes. (Alternatively, once we upgrade from ti-mocha to the real mocha package, I think you can explicitly call this.skip()
inside a test to mark it at runtime)
should(e).have.property('code').which.is.a.Number(); | ||
should(e.code).be.eql(1); | ||
should(e).have.property('error').which.is.a.String(); | ||
finish(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typically I'd move this outside the try/catch block, because if an after
test hook fails this could cause the catch block to fire and call finish again.
@@ -282,6 +282,63 @@ methods: | |||
platforms: [iphone, ipad, android] | |||
since: "5.1.0" | |||
|
|||
- name: requestTemporaryFullAccuracyAuthorization |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to create a new method? From a cross-platform standpoint, it might be nice to re-use our existing requestLocationPermissions() and hasLocationPermissions() methods and add the new "purpose" string key as a parameter... or even better add support for a settings dictionary to these methods with a new "purpose" field.
On Android, location permission can be granted temporarily by the end-user too. We can still leverage the hasLocationPermission()
method to check if it's still granted. And the Ti.Location.accuracy
property defines the accuracy of the permission we need to look for. On Android, the ACCESS_FINE_LOCATION
sounds like the equivalent of the "accurate" permission on iOS (which means read from the GPS).
https://developer.android.com/preview/privacy/permissions#one-time
So, can we do something like this?
const permissionSettings = {
authorization: Ti.Geolocation.AUTHORIZATION_ALWAYS,
purpose: 'PurposeKey1',
};
if (Ti.Geolocation.hasLocationPermissions(permissionSettings)) {
fetchLocationInfo();
} else {
Ti.Geolocation.requestLocationPermissions(permissionSettings, (e) => {
if (e.success) {
fetchLocationInfo();
}
});
}
Question:
On iOS 14, is the "purpose" key required? Are people going to have location accessing problem if they don't update their location permission handling code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jquick-axway This new API is for requesting full accuracy if user requires it in app. And it get expires. It is not mandatory. e.g your app do not need full accurate location, you should simply need location access . let's say at some screen you need full accuracy to show use'r location, you have to go for it. See here for more details
I think changes in Android 11 is same as of 'allow once' permission given in iOS 13. It is location permission's life not accuracy. See here.
'purpose' key is only required if one is going to access location with full accuracy. It will not break existing implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So my only beef with this is if the app developer sets Ti.Location.accuracy
to ACCURACY_HIGH
, then I think hasLocationPermissions()
should return false
if it has high accuracy has expired, because that's what the app desires. That's why I'm question the necessity of these new APIs... that and I think we're making this more complicated for app developers than it needs to be. A portable API that works between all iOS versions and Android would be the ideal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If user has granted location permission hasLocationPermissions()
will be true
. ACURRACY_HIGH (kCLLocationAccuracyBest) is desirable not guaranteed.
In iOS 14+ when app request for location permission there comes a popup (see attached Image1) which have a button mentioning 'Precise: On'. If user sets it off, app will not get location data with full accuracy. If at some point it is required to get 'full accuracy', with this new API app can ask for permission to get full accuracy in location data with a valid reason (see image2 ). And it will be temporary.
Image1-
FR Passed |
Holding for @vijaysingh-axway and @jquick-axway to continue discussion about the APIs before we merge this. |
50a182d
to
f2bda48
Compare
@jquick-axway Opened up https://jira.appcelerator.org/browse/TIMOB-28114 to track investigating a better cross-platform API to hide the platform specific and OS version specific codepaths. |
https://jira.appcelerator.org/browse/TIMOB-27976