react-native/Libraries/Geolocation/Geolocation.js

214 lines
6.5 KiB
JavaScript
Raw Normal View History

/**
* Copyright (c) 2015-present, Facebook, Inc.
* All rights reserved.
*
* This source code is licensed under the BSD-style license found in the
* LICENSE file in the root directory of this source tree. An additional grant
* of patent rights can be found in the PATENTS file in the same directory.
*
2015-03-09 10:04:44 +00:00
* @providesModule Geolocation
2015-03-25 18:12:57 +00:00
* @flow
*/
'use strict';
const NativeEventEmitter = require('NativeEventEmitter');
const RCTLocationObserver = require('NativeModules').LocationObserver;
const invariant = require('fbjs/lib/invariant');
const logError = require('logError');
const warning = require('fbjs/lib/warning');
const LocationEventEmitter = new NativeEventEmitter(RCTLocationObserver);
const Platform = require('Platform');
const PermissionsAndroid = require('PermissionsAndroid');
var subscriptions = [];
var updatesEnabled = false;
iOS: Geolocation: Allow skipping of permission prompts Summary: This change enables developers to tell the Geolocation module to skip its permissions requests so the app can manage the permissions requests on its own. React Native Android's Geolocation module already requires apps to request permissions on their own. Currently, the Geolocation module automatically makes permissions requests for you based on what you've specified in your property list file. However, the property list file doesn't always represent what permissions the app wants right now. For example, suppose an app sometimes wants location when "in use" and sometimes wants location "always" depending on what app features the user has engaged with. The Geolocation API will request the "always" location permission even if that's not what the app wants for the current scenario. This change enables developers to tell the Geolocation module to skip permission requests so that the app can explicitly ask for the appropriate permissions. By default, Geolocation will still ask for permissions so this is not a breaking change. This change adds a method to Geolocation that is not supported by the web spec for geolocation (`setRNConfiguration`). This method includes `RN` in the name to minimize the chances that the web spec will introduce an API with the same name. **Test plan (required)** Verified that Geolocation requests permissions by default and when `skipPermissionRequests` is `false`. Verified the permission requests are skipped when `skipPermissionRequests` is `true`. Also, my team is using this change in our app. Adam Comella Microsoft Corp. Closes https://github.com/facebook/react-native/pull/15096 Differential Revision: D5725563 Pulled By: javache fbshipit-source-id: fd23fedb7e57408fa0f0d0568e0f1ef2aea1cdd4
2017-08-29 11:00:41 +00:00
type GeoConfiguration = {
skipPermissionRequests: bool;
}
2015-04-24 23:10:46 +00:00
type GeoOptions = {
Use Apple's significant-change API (for iOS 11 UX) Summary: In the yet-to-be-released iOS 11, Apple has changed the way they notify the user of location services. (You can watch their session from WWDC about all the changes [here](https://developer.apple.com/videos/play/wwdc2017/713/).) The current implementation of `RCTLocationObserver` uses the standard location services from Apple. When the user has granted `Always` location permission and the application uses the background location service, the user is presented with the *_Blue Bar of Shame_* (for more information check out [this blog post](https://blog.set.gl/ios-11-location-permissions-and-avoiding-the-blue-bar-of-shame-1cee6cd93bbe)): ![image](https://user-images.githubusercontent.com/15896334/28285133-281e425c-6af9-11e7-9177-61b879ab593c.png) * Added `useSignificantChanges` boolean to the options passed. * Added `_usingSignificantChanges` boolean based on user options. If `true`, then the CLLocationManager will use functions `startMonitoringSignificantLocationChanges`/ `stopMonitoringSignificantLocationChanges` rather than the standard location services. * Changed method signature of `beginLocationUpdatesWithDesiredAccuracy` to include `useSignificantChanges` flag * Added check for new `NSLocationAlwaysAndWhenInUseUsageDescription` All unit tests passed. Tested in simulator and on device, toggling `useSignificantChanges` option when calling `watchPosition`. Results were as expected. **When `TRUE`, the _Blue Bar of Shame_ was not present.** Changes do not affect Android and location services still work as expected on Android. * Change is for iOS only * Using a different API will have different accuracy results. Adding `useSignificantChanges` as an option was by design so apps that want to have most accurate and most frequent update can still use standard location services. Closes https://github.com/facebook/react-native/pull/15062 Differential Revision: D5443331 Pulled By: javache fbshipit-source-id: 0cf5b6cd831c5a7c8c25a5ddc2e410a9aa989bf4
2017-07-24 18:15:27 +00:00
timeout?: number,
maximumAge?: number,
enableHighAccuracy?: bool,
distanceFilter: number,
Use Apple's significant-change API (for iOS 11 UX) Summary: In the yet-to-be-released iOS 11, Apple has changed the way they notify the user of location services. (You can watch their session from WWDC about all the changes [here](https://developer.apple.com/videos/play/wwdc2017/713/).) The current implementation of `RCTLocationObserver` uses the standard location services from Apple. When the user has granted `Always` location permission and the application uses the background location service, the user is presented with the *_Blue Bar of Shame_* (for more information check out [this blog post](https://blog.set.gl/ios-11-location-permissions-and-avoiding-the-blue-bar-of-shame-1cee6cd93bbe)): ![image](https://user-images.githubusercontent.com/15896334/28285133-281e425c-6af9-11e7-9177-61b879ab593c.png) * Added `useSignificantChanges` boolean to the options passed. * Added `_usingSignificantChanges` boolean based on user options. If `true`, then the CLLocationManager will use functions `startMonitoringSignificantLocationChanges`/ `stopMonitoringSignificantLocationChanges` rather than the standard location services. * Changed method signature of `beginLocationUpdatesWithDesiredAccuracy` to include `useSignificantChanges` flag * Added check for new `NSLocationAlwaysAndWhenInUseUsageDescription` All unit tests passed. Tested in simulator and on device, toggling `useSignificantChanges` option when calling `watchPosition`. Results were as expected. **When `TRUE`, the _Blue Bar of Shame_ was not present.** Changes do not affect Android and location services still work as expected on Android. * Change is for iOS only * Using a different API will have different accuracy results. Adding `useSignificantChanges` as an option was by design so apps that want to have most accurate and most frequent update can still use standard location services. Closes https://github.com/facebook/react-native/pull/15062 Differential Revision: D5443331 Pulled By: javache fbshipit-source-id: 0cf5b6cd831c5a7c8c25a5ddc2e410a9aa989bf4
2017-07-24 18:15:27 +00:00
useSignificantChanges?: bool,
2015-04-24 23:10:46 +00:00
}
/**
* The Geolocation API extends the web spec:
* https://developer.mozilla.org/en-US/docs/Web/API/Geolocation
*
* As a browser polyfill, this API is available through the `navigator.geolocation`
* global - you do not need to `import` it.
*
Include Create React Native App in Getting Started Summary: cc hramos Create React Native App was designed to reduce "time to hello world" to 5-10 minutes for React Native apps. This PR would make CRNA the first way to get started that new users encounter. Included also is some text to help advanced users navigate the question of whether to use CRNA or whether to go straight to `react-native init`. It also includes a new banner for the iOS and Android guides, since they do not apply to CRNA users. Changes are only to the website, screenshots below. This branch was created from the last CI-passing master commit this morning, dependencies were freshly installed and these screenshots are from a clean build. [The Getting Started page](https://www.dropbox.com/s/1s7f3wu3oxr6gpo/Screenshot%202017-04-04%2015.12.29.png?dl=0) [The "native builds only" banner](https://www.dropbox.com/s/nyv51xdiibdkn57/Screenshot%202017-04-04%2015.13.25.png?dl=0) [Pages which still apply to CRNApps have no banner](https://www.dropbox.com/s/qgl0h6uzynqkmy2/Screenshot%202017-04-04%2015.14.10.png?dl=0) <details> * [x] Decide how to handle native code & react-native-cli references outside of the `banner: ejected` guides * [x] [Debugging: Accessing Console Logs](https://facebook.github.io/react-native/docs/debugging.html#accessing-console-logs) isn't needed in CRNA (logs are forwarded alongside packager output) * [x] [Debugging: With Stetho](https://facebook.github.io/react-native/docs/debugging.html#debugging-with-stetho-http-facebook-github-io-stetho-on-android) requires native code * [x] [Debugging: Debugging Native Code](https://facebook.github.io/react-native/docs/debugging.html#debugging-native-code) is native-only * [x] [AppRegistry](https://facebook.github.io/react-native/docs/appregistry.html) only applies to ejected apps, since this is generated from code, I don't think we can set `banner: ejected`? * [x] [Linking](https://facebook.github.io/react-native/docs/linking.html) involves changing Android manifests and other native-side things * [x] [PermissionsAndroid](https://facebook.github.io/react-native/docs/permissionsandroid.html) may be flaky in the Expo client, I can't recall (cc jesseruder) * [x] [PushNotificationIOS](https://facebook.github.io/react-native/docs/pushnotificationios.html) won't work inside Expo, as it has to [handle its own push notifs](https://docs.expo.io/versions/v15.0.0/guides/push-notifications.html) * [x] [Geolocation](https://facebook.github.io/react-native/docs/geolocation.html) requires a polyfill that will most likely ship with next week's release, but that won't have any manifest changes necessary * [ ] Figure out a strategy to handle the fact that CRNA will lag stable RN releases by ~1 week * [x] Confirm linking out to CRNA docs is an OK strategy as opposed to moving ejecting, etc. docs in-tree * [ ] Answer questions (I'll add some review comments to call out a few things) </details> Closes https://github.com/facebook/react-native/pull/13303 Differential Revision: D4950661 Pulled By: hramos fbshipit-source-id: 3dd43828f38ca6ede3f2b0683608c56420dc6525
2017-04-26 14:09:36 +00:00
* ### Configuration and Permissions
*
* <div class="banner-crna-ejected">
* <h3>Projects with Native Code Only</h3>
* <p>
* This section only applies to projects made with <code>react-native init</code>
* or to those made with Create React Native App which have since ejected. For
* more information about ejecting, please see
* the <a href="https://github.com/react-community/create-react-native-app/blob/master/EJECTING.md" target="_blank">guide</a> on
* the Create React Native App repository.
* </p>
* </div>
*
* #### iOS
* You need to include the `NSLocationWhenInUseUsageDescription` key
* in Info.plist to enable geolocation when using the app. Geolocation is
* enabled by default when you create a project with `react-native init`.
*
* In order to enable geolocation in the background, you need to include the
* 'NSLocationAlwaysUsageDescription' key in Info.plist and add location as
* a background mode in the 'Capabilities' tab in Xcode.
*
Include Create React Native App in Getting Started Summary: cc hramos Create React Native App was designed to reduce "time to hello world" to 5-10 minutes for React Native apps. This PR would make CRNA the first way to get started that new users encounter. Included also is some text to help advanced users navigate the question of whether to use CRNA or whether to go straight to `react-native init`. It also includes a new banner for the iOS and Android guides, since they do not apply to CRNA users. Changes are only to the website, screenshots below. This branch was created from the last CI-passing master commit this morning, dependencies were freshly installed and these screenshots are from a clean build. [The Getting Started page](https://www.dropbox.com/s/1s7f3wu3oxr6gpo/Screenshot%202017-04-04%2015.12.29.png?dl=0) [The "native builds only" banner](https://www.dropbox.com/s/nyv51xdiibdkn57/Screenshot%202017-04-04%2015.13.25.png?dl=0) [Pages which still apply to CRNApps have no banner](https://www.dropbox.com/s/qgl0h6uzynqkmy2/Screenshot%202017-04-04%2015.14.10.png?dl=0) <details> * [x] Decide how to handle native code & react-native-cli references outside of the `banner: ejected` guides * [x] [Debugging: Accessing Console Logs](https://facebook.github.io/react-native/docs/debugging.html#accessing-console-logs) isn't needed in CRNA (logs are forwarded alongside packager output) * [x] [Debugging: With Stetho](https://facebook.github.io/react-native/docs/debugging.html#debugging-with-stetho-http-facebook-github-io-stetho-on-android) requires native code * [x] [Debugging: Debugging Native Code](https://facebook.github.io/react-native/docs/debugging.html#debugging-native-code) is native-only * [x] [AppRegistry](https://facebook.github.io/react-native/docs/appregistry.html) only applies to ejected apps, since this is generated from code, I don't think we can set `banner: ejected`? * [x] [Linking](https://facebook.github.io/react-native/docs/linking.html) involves changing Android manifests and other native-side things * [x] [PermissionsAndroid](https://facebook.github.io/react-native/docs/permissionsandroid.html) may be flaky in the Expo client, I can't recall (cc jesseruder) * [x] [PushNotificationIOS](https://facebook.github.io/react-native/docs/pushnotificationios.html) won't work inside Expo, as it has to [handle its own push notifs](https://docs.expo.io/versions/v15.0.0/guides/push-notifications.html) * [x] [Geolocation](https://facebook.github.io/react-native/docs/geolocation.html) requires a polyfill that will most likely ship with next week's release, but that won't have any manifest changes necessary * [ ] Figure out a strategy to handle the fact that CRNA will lag stable RN releases by ~1 week * [x] Confirm linking out to CRNA docs is an OK strategy as opposed to moving ejecting, etc. docs in-tree * [ ] Answer questions (I'll add some review comments to call out a few things) </details> Closes https://github.com/facebook/react-native/pull/13303 Differential Revision: D4950661 Pulled By: hramos fbshipit-source-id: 3dd43828f38ca6ede3f2b0683608c56420dc6525
2017-04-26 14:09:36 +00:00
* #### Android
* To request access to location, you need to add the following line to your
* app's `AndroidManifest.xml`:
*
* `<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />`
*
* Android API >= 18 Positions will also contain a `mocked` boolean to indicate if position
* was created from a mock provider.
*
*/
2015-03-09 10:04:44 +00:00
var Geolocation = {
iOS: Geolocation: Allow skipping of permission prompts Summary: This change enables developers to tell the Geolocation module to skip its permissions requests so the app can manage the permissions requests on its own. React Native Android's Geolocation module already requires apps to request permissions on their own. Currently, the Geolocation module automatically makes permissions requests for you based on what you've specified in your property list file. However, the property list file doesn't always represent what permissions the app wants right now. For example, suppose an app sometimes wants location when "in use" and sometimes wants location "always" depending on what app features the user has engaged with. The Geolocation API will request the "always" location permission even if that's not what the app wants for the current scenario. This change enables developers to tell the Geolocation module to skip permission requests so that the app can explicitly ask for the appropriate permissions. By default, Geolocation will still ask for permissions so this is not a breaking change. This change adds a method to Geolocation that is not supported by the web spec for geolocation (`setRNConfiguration`). This method includes `RN` in the name to minimize the chances that the web spec will introduce an API with the same name. **Test plan (required)** Verified that Geolocation requests permissions by default and when `skipPermissionRequests` is `false`. Verified the permission requests are skipped when `skipPermissionRequests` is `true`. Also, my team is using this change in our app. Adam Comella Microsoft Corp. Closes https://github.com/facebook/react-native/pull/15096 Differential Revision: D5725563 Pulled By: javache fbshipit-source-id: fd23fedb7e57408fa0f0d0568e0f1ef2aea1cdd4
2017-08-29 11:00:41 +00:00
/*
* Sets configuration options that will be used in all location requests.
*
* ### Options
*
* #### iOS
*
* - `skipPermissionRequests` - defaults to `false`, if `true` you must request permissions
* before using Geolocation APIs.
*
*/
setRNConfiguration: function(
config: GeoConfiguration
) {
if (RCTLocationObserver.setConfiguration) {
RCTLocationObserver.setConfiguration(config);
}
},
/*
* Request suitable Location permission based on the key configured on pList.
* If NSLocationAlwaysUsageDescription is set, it will request Always authorization,
* although if NSLocationWhenInUseUsageDescription is set, it will request InUse
* authorization.
*/
requestAuthorization: function() {
RCTLocationObserver.requestAuthorization();
},
2015-04-24 23:10:46 +00:00
/*
* Invokes the success callback once with the latest location info. Supported
* options: timeout (ms), maximumAge (ms), enableHighAccuracy (bool)
* On Android, if the location is cached this can return almost immediately,
* or it will request an update which might take a while.
2015-04-24 23:10:46 +00:00
*/
getCurrentPosition: async function(
2015-03-25 18:12:57 +00:00
geo_success: Function,
geo_error?: Function,
2015-04-24 23:10:46 +00:00
geo_options?: GeoOptions
2015-03-26 17:06:50 +00:00
) {
invariant(
typeof geo_success === 'function',
'Must provide a valid geo_success callback.'
);
let hasPermission = true;
// Supports Android's new permission model. For Android older devices,
// it's always on.
if (Platform.OS === 'android' && Platform.Version >= 23) {
hasPermission = await PermissionsAndroid.check(
PermissionsAndroid.PERMISSIONS.ACCESS_FINE_LOCATION,
);
if (!hasPermission) {
const status = await PermissionsAndroid.request(
PermissionsAndroid.PERMISSIONS.ACCESS_FINE_LOCATION,
);
hasPermission = status === PermissionsAndroid.RESULTS.GRANTED;
}
}
if (hasPermission) {
RCTLocationObserver.getCurrentPosition(
geo_options || {},
geo_success,
geo_error || logError,
);
}
2015-03-09 10:04:44 +00:00
},
2015-04-24 23:10:46 +00:00
/*
* Invokes the success callback whenever the location changes. Supported
Use Apple's significant-change API (for iOS 11 UX) Summary: In the yet-to-be-released iOS 11, Apple has changed the way they notify the user of location services. (You can watch their session from WWDC about all the changes [here](https://developer.apple.com/videos/play/wwdc2017/713/).) The current implementation of `RCTLocationObserver` uses the standard location services from Apple. When the user has granted `Always` location permission and the application uses the background location service, the user is presented with the *_Blue Bar of Shame_* (for more information check out [this blog post](https://blog.set.gl/ios-11-location-permissions-and-avoiding-the-blue-bar-of-shame-1cee6cd93bbe)): ![image](https://user-images.githubusercontent.com/15896334/28285133-281e425c-6af9-11e7-9177-61b879ab593c.png) * Added `useSignificantChanges` boolean to the options passed. * Added `_usingSignificantChanges` boolean based on user options. If `true`, then the CLLocationManager will use functions `startMonitoringSignificantLocationChanges`/ `stopMonitoringSignificantLocationChanges` rather than the standard location services. * Changed method signature of `beginLocationUpdatesWithDesiredAccuracy` to include `useSignificantChanges` flag * Added check for new `NSLocationAlwaysAndWhenInUseUsageDescription` All unit tests passed. Tested in simulator and on device, toggling `useSignificantChanges` option when calling `watchPosition`. Results were as expected. **When `TRUE`, the _Blue Bar of Shame_ was not present.** Changes do not affect Android and location services still work as expected on Android. * Change is for iOS only * Using a different API will have different accuracy results. Adding `useSignificantChanges` as an option was by design so apps that want to have most accurate and most frequent update can still use standard location services. Closes https://github.com/facebook/react-native/pull/15062 Differential Revision: D5443331 Pulled By: javache fbshipit-source-id: 0cf5b6cd831c5a7c8c25a5ddc2e410a9aa989bf4
2017-07-24 18:15:27 +00:00
* options: timeout (ms), maximumAge (ms), enableHighAccuracy (bool), distanceFilter(m), useSignificantChanges (bool)
2015-04-24 23:10:46 +00:00
*/
watchPosition: function(success: Function, error?: Function, options?: GeoOptions): number {
2015-03-09 10:04:44 +00:00
if (!updatesEnabled) {
RCTLocationObserver.startObserving(options || {});
updatesEnabled = true;
}
var watchID = subscriptions.length;
2015-03-09 10:04:44 +00:00
subscriptions.push([
LocationEventEmitter.addListener(
2015-03-09 10:04:44 +00:00
'geolocationDidChange',
success
),
error ? LocationEventEmitter.addListener(
2015-03-09 10:04:44 +00:00
'geolocationError',
error
) : null,
]);
return watchID;
2015-03-09 10:04:44 +00:00
},
2015-03-25 18:12:57 +00:00
clearWatch: function(watchID: number) {
var sub = subscriptions[watchID];
if (!sub) {
// Silently exit when the watchID is invalid or already cleared
// This is consistent with timers
return;
}
2015-03-25 18:12:57 +00:00
2015-03-09 10:04:44 +00:00
sub[0].remove();
2015-03-25 18:12:57 +00:00
// array element refinements not yet enabled in Flow
var sub1 = sub[1]; sub1 && sub1.remove();
subscriptions[watchID] = undefined;
var noWatchers = true;
for (var ii = 0; ii < subscriptions.length; ii++) {
if (subscriptions[ii]) {
noWatchers = false; // still valid subscriptions
}
}
if (noWatchers) {
2015-03-09 10:04:44 +00:00
Geolocation.stopObserving();
}
2015-03-09 10:04:44 +00:00
},
stopObserving: function() {
if (updatesEnabled) {
RCTLocationObserver.stopObserving();
updatesEnabled = false;
for (var ii = 0; ii < subscriptions.length; ii++) {
2015-03-25 18:12:57 +00:00
var sub = subscriptions[ii];
if (sub) {
warning(false, 'Called stopObserving with existing subscriptions.');
2015-03-25 18:12:57 +00:00
sub[0].remove();
// array element refinements not yet enabled in Flow
var sub1 = sub[1]; sub1 && sub1.remove();
}
}
subscriptions = [];
}
}
};
2015-03-09 10:04:44 +00:00
module.exports = Geolocation;