(ios) Continue watchPosition when the App is suspended and reactivated, fixes #224

[katzlbt]

Platforms affected

iOS

Motivation and Context

Fixes issue #224

Description

if(error.code == kCLErrorDenied && [self isAuthorized] && [self isLocationServicesEnabled])
   then do not stopUpdatingLocation and thus continue watchPosition after suspending the app and reactivating it

Testing

Manual tests on iPhone

Checklist

• I've run the tests to see all new and existing tests pass
• I added automated test coverage as appropriate for this change
• Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
• If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
• I've updated the documentation if necessary

[katzlbt]

If #226 is fixed, PERMISSION_DENIED is transmitted to the WebView, although it is not really a user-denial. Should this be done?

[breautek]

Apple states:

If the user denies your app's use of the location service, this method reports a kCLErrorDenied error. Upon receiving such an error, you should stop the location service.

https://developer.apple.com/documentation/corelocation/cllocationmanagerdelegate/1423786-locationmanager?language=objc

And Apple can be notoriously picky when it comes to app reviews, which makes me hesitant about merging this change.

A simple workaround is to just hook into the resume event and resume watching which is what Apple would expect you to do natively in this situation.

Not stopping the location manager means you're wastefully draining battery resources on the device when you know you won't get any GPS updates.

So my apologies, I don't think this PR can be accepted.

[katzlbt]

@breautek Did you notice the && [self isAuthorized] && [self isLocationServicesEnabled] in the if statement? So, yes the user has authorized GPS and enabled the location-services. The thing is a workaround to a bug that Apple's iOS sends once or twice kCLErrorDenied after suspending and resuming the app and then kCLErrorDenied goes away. It may have been fixed in recent iOS releases though.

Of course this has passed Apples review more than once.

[breautek]

The thing is a workaround to a bug that Apple's iOS sends once or twice kCLErrorDenied after suspending and resuming the app and then kCLErrorDenied goes away. It may have been fixed in recent iOS releases though.

This would be intentional and will happen if your app doesn't have background access granted.

I think my concern was here where it is ignoring kCLErrorDenied and simply returning, instead of stopping location services and that is directly against what iOS says the application should do.

Of course this has passed Apples review more than once.

To be frank, this isn't really a strong argument. I've had things in my own apps that has gone through countless of app publications and reviews for years until one day Apple decides to flag that thing. It really all depends on the reviewer. To re-iterate I'm more concerned with ignoring the Apple documentation.