Fix iosapp location ask

[friedbunny]

The iosapp demo app was asking for location permission via showsUserLocation = YES in viewDidLoad, then immediately having restoreState: set showsUserLocation = NO because that's what the default is.

This PR lets restoreState: do the setting of showsUserLocation and then only asks for permissions if the value is NO — after a delay to allow the map to load.

Fixes #1930.

/cc @1ec5 @incanus

[friedbunny]

RE: @incanus in #1930 (comment)

I'm not generally into timers, but in the interest of simplicity, maybe just set showsUserLocation = YES a second after viewDidAppear:?

Went with two seconds at the end of viewDidLoad:, only on the first launch (or any launch after that doesn't have permission, I suppose). Whatcha' think?

[incanus]

I think this is fine. However if we save & restore userTrackingMode, this will implicitly show the user dot, right?

[1ec5]

However if we save & restore userTrackingMode, this will implicitly show the user dot, right?

The user might want to see the user dot without following it.

[incanus]

My point is that restoring tracking mode at launch will have the same affect as restoring showing the user dot — still prompt the user without delay when restoring state.

[friedbunny]

If the saved user tracking mode was none and we didn't explicitly set mapView.showsUserLocation, the dot would not appear initially. I kept settings->showsUserLocation because it's useful in determining if location is authorized.

The delayed mapView.showsUserLocation should only be triggered on the first launch, because we turn .showsUserLocation on when location permissions are given and it is never turned off at any point after. (Disabling user tracking when the dot is shown doesn't disable .showsUserLocation.)

[maciekish]

This commit breaks master for me. Xcode says "Use of undeclared identifier 'settings' here https://github.com/mapbox/mapbox-gl-native/pull/2265/files#diff-33b34b5f099a16158c8462652a0c3688R79

[friedbunny]

This was broken subsequently in 0a172a2#diff-33b34b5f099a16158c8462652a0c3688 when we moved directly to using NSUserDefaults instead of an intermediary. I'll get a fix in.

[maciekish]

I think you may want to prefix your defaults or use initWithSuiteName: or something to avid clashes with defaults names.

[friedbunny]

I think you may want to prefix your defaults or use initWithSuiteName: or something to avid clashes with defaults names.

Sandboxing means that we only have to contend with certain Apple NSUserDefaults (which tend to be namespaced themselves). A real app may need to worry about this, but our demo app likely does not.