search

jamesmontemagno / Xamarin.Plugins

Cross-platform Native API Access from Shared Code!
MIT License
1.3k stars 380 forks source link

GeoLocator GetPositionAsync fails on iOS 9 in 4.0.0-beta1 without background location #246

Closed TheAlmightyBob closed 8 years ago

TheAlmightyBob commented 8 years ago

Please take a moment to fill out the following (change to preview to check or place x in []):

This is a

Which plugin does this impact:

Version Number of Plugin: 4.0.0-beta1 Device Tested On: n/a Simulator Tested On: iOS 9 simulator

Expected Behavior

GetPositionAsync returns a position.

Actual Behavior

Platform exception thrown: NSInternalInconsistencyException: 'Invalid parameter not satisfying: !stayUp || CLClientIsBackgroundable(internal->fClient)'

Steps to reproduce the Behavior

Create a simple test app with LocationWhenInUseUsageDescription and without the "Location Updates" Background Mode.

This is a regression from 3.0.4.

Commit 799665bff39ce4e51ed786ee43efbd20e97f7983 made a change to GetPositionAsync for iOS 9 to "always permit background updates since we're only listening for a single update." However, the Apple documentation for allowsBackgroundLocationUpdates states that "Setting the value to YES but omitting the UIBackgroundModes key and location value in your app’s Info.plist file is a programmer error."

(hence the exception)

Enabling background location in the Info.plist "fixes" the problem, however it should not be necessary for an app that does not actually require that capability (and my understanding is that Apple will reject apps that enable those properties unnecessarily).

jamesmontemagno commented 8 years ago

Good find, we will need to cover this in the mass refactoring.

We only enabled this for StartListening @MatthewGerber we need to handle this

MatthewGerber commented 8 years ago

Yes good find. Will fix. Thanks.

jamesmontemagno commented 8 years ago

I am curious if we can detect it without having to send in a parameter and set it automatically.

On Thu, Mar 17, 2016 at 9:09 PM, Matthew Gerber notifications@github.com wrote:

Yes good find. Will fix. Thanks.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jamesmontemagno/Xamarin.Plugins/issues/246#issuecomment-198150317

James Montemagno http://www.montemagno.com @jamesmontemagno http://www.twitter.com/jamesmontemagno

MatthewGerber commented 8 years ago

Can we read the plist? On Mar 17, 2016 9:44 PM, "James Montemagno" notifications@github.com wrote:

I am curious if we can detect it without having to send in a parameter and set it automatically.

On Thu, Mar 17, 2016 at 9:09 PM, Matthew Gerber notifications@github.com wrote:

Yes good find. Will fix. Thanks.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub < https://github.com/jamesmontemagno/Xamarin.Plugins/issues/246#issuecomment-198150317

James Montemagno http://www.montemagno.com @jamesmontemagno http://www.twitter.com/jamesmontemagno

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jamesmontemagno/Xamarin.Plugins/issues/246#issuecomment-198158646

MatthewGerber commented 8 years ago

@jamesmontemagno Did you test the plist reading code that I added in 80e13e6? It seems to work in the latest NuGet, but I wasn't able to actually test those particular lines of code on my machine prior to committing them.