Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
This fixes#17486
make sure locationManager is being set before continuing.
Used if !locationManager vs else on previous statement as we should NEVER enter this code without _locationManager set. Also the else version might experience issues if someone touches the auth code and doesn't check this case, so seems more "long term stable".
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
This fixes#17486
1) Have a working geolocation demo
2) Add navigator.geolocation.setRNConfiguration({'skipPermissionRequests':true}); to your code. I added it to the constructor or componentWillMount for the app.
3) Observe that geolocation no longer works (times out)
4) Apply patch
5) Observe that geolocation works again
re #15096
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[IOS] [BUGFIX] [GeoLocation] - Fix skipPermissionRequests by setting _locationManager
Closes https://github.com/facebook/react-native/pull/17487
Differential Revision: D6718389
Pulled By: hramos
fbshipit-source-id: 08c1c9306b4d87cc40acdaa1550bb6df8345db02
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
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)):
* 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
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
Set the flag 'allowsBackgroundLocationUpdates' to YES if the location background mode is enabled and the 'Always Allow Location' key is set in the App Plist.
**motivation**
We found that on iOS 9.x, the allowsBackgroundLocationUpdates flag must be set on location manager in order to receive updates when the app is in the background (seems to affect actual device only).
**Test plan (required)**
Example app using the forked branch [here](https://github.com/briancalvium/react-native-geolocation-pr-example). Run this example through XCode on a device with 9.x, observe that location update logs continue to appear when the app is in the background. Switch to react native 0.32.0, observe that location update logs stop once the app is in the background.
Closes https://github.com/facebook/react-native/pull/9717
Differential Revision: D4167685
Pulled By: hramos
fbshipit-source-id: 5a62f8433bf8b553561a276fdaa544363298442a
Summary:
Fixes an issue where location request timeout errors always reported "Unable to fetch location within **0s**".
Previously we had `@"Unable to fetch location within %zds.", (NSInteger)(timer.timeInterval * 1000.0)` but from the [NSTimer.timeInterval docs](https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/#//apple_ref/occ/instp/NSTimer/timeInterval) "If the receiver is a non-repeating timer, returns 0 even if a time interval was set.".
Change to use `request.options.timeout` instead, which is a `Double` defaulting to `INFINITY`. Tested on an iOS simulator.
Closes https://github.com/facebook/react-native/pull/9888
Differential Revision: D3902788
Pulled By: javache
fbshipit-source-id: aef717d6c39f3177cb7056a17adc35c1bfd94132
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: bestander
Differential Revision: D3346129
fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
Allow changing distanceFilter after _locationManager has been initialized.
There is 2 reasons for this PR:
- When calling `getCurrentPosition`, `_observerOptions` is possibly not set properly ( as it is set only in `startObserving`), in this case it would have default values so `distanceFilter` will be 0 in this case ( which can be the right value but we should be more explicit about it, `kCLDistanceFilterNone` or `RCT_DEFAULT_LOCATION_ACCURACY`):
<img width="961" alt="screen shot 2016-04-14 at 8 44 09 pm" src="https://cloud.githubusercontent.com/assets/159813/14551465/6aa8791a-0288-11e6-9c98-1687357f8c2a.png">
- Another issue is that `distanceFilter` is cached so it can't be changed afterwards:
```javascript
let options;
options = {
enableHighAccuracy: true,
distanceFilter: 20,
};
this.watchId = this.geolocation.watchPosition(
() => { },
() => { },
options,
);
// => sets distanceFilter to 20
this.geolocation.clearWatch(this.watchId);
options = {
enableHighAccuracy:
Closes https://github.com/facebook/react-native/pull/6987
Differential Revision: D3258956
fb-gh-sync-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
fbshipit-source-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
Summary:There are two issues:
1. When calling startObserving or getCurrentPosition for the first time, _locationManager is not initialized and the accuracy value set in options is lost.
2. When using the cached location _lastLocationEvent, current timestamp retrieved by CFAbsoluteTimeGetCurrent() is from 2001, but the timestamp of the location is from 1970. In addition, the comparison between _lastLocationEvent[@"coords"][@"accuracy"] and options.accuracy is incorrect. Less value indicates more accurate location.
Closes https://github.com/facebook/react-native/pull/6198
Differential Revision: D3023786
Pulled By: nicklockwood
fb-gh-sync-id: 869c0e34252470275bf99cf0e5861747247f1158
shipit-source-id: 869c0e34252470275bf99cf0e5861747247f1158
Summary:Geolocation timestamp is different for Android and iOs. For Android it is returning in UTC time in milliseconds since January 1, 1970, for iOS it was returned as time interval relative to an absolute reference date (00:00:00 UTC on 1 January 2001). Also for iOS time returned was "current system absolute time" and not the time at which this location was determined.
Tested with 0.21.0-rc React Native. Init project with this additional code:
`constructor(props) {super(props);
navigator.geolocation.getCurrentPosition(
(position) => {
let initialPosition = JSON.stringify(position);
console.log(position.timestamp);
},
(error) => alert(error.message),
{enableHighAccuracy: true, timeout: 20000, maximumAge: 1000} );
}
`
Tested with iOs simulator (iPhone 6S plus 9.2; iPhone 5s 8.4 )
sample result with change: 1456407795021.235
sample result without change: 23478100615007.884
Explaining links for iOS:
https://developer.apple.com/library/ios/do
Closes https://github.com/facebook/react-native/pull/6150
Differential Revision: D2976909
Pulled By: nicklockwood
fb-gh-sync-id: 9607ed669d7200591f8387e4186cf7c225ae9b3a
shipit-source-id: 9607ed669d7200591f8387e4186cf7c225ae9b3a
Summary:
My original implementation involved creating a `RCT_ENUM_CONVERTER` with `CLLocationAccuracy` on iOS and a Hashmap on Android that would convert `string` values to `doubles` for distance filtering.
I got this to work just fine but realized that I made things more complicated than they needed to be and simplified everything by just have the option be a decimal value (in meters) that works both for iOS and Android.
The only thing i'm not sure about is if we can set arbitrary values for CLLocationManager's distance filter.
nicklockwood Any idea?
Closes https://github.com/facebook/react-native/pull/5563
Reviewed By: svcscm
Differential Revision: D2908250
Pulled By: nicklockwood
fb-gh-sync-id: d83c12b3ce7c343f413749a2cd614b3bf04d6750
Summary:
brentvatne this is the pull request you requested
See issue #4886
On iOS the plist key NSLocationAlwaysUsageDescription was ignored and the location could not be retreived when using this key. Now both keys NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription are supported. If NSLocationAlwaysUsageDescription is set, NSLocationWhenInUseUsageDescription will be simply ignored according to https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW18
I read the contribution guidelines regarding the Objective-C coding standards. Hopefully my line length breaks are okay - otherwise just give me a shout and I will fix that. Didn't write any line of Objective-C before so^^
Closes https://github.com/facebook/react-native/pull/5093
Reviewed By: svcscm
Differential Revision: D2823206
Pulled By: nicklockwood
fb-gh-sync-id: dd856a18416796749025e4b32d9c72895401916d
Summary:
Instantiates the _pendingRequests array before trying to add to it. As it currently stands, we try to add the pending request before the array is created. getCurrentPosition always fails on the first try.
Closes https://github.com/facebook/react-native/pull/4764
Reviewed By: svcscm
Differential Revision: D2764751
Pulled By: androidtrunkagent
fb-gh-sync-id: 411a03ff16d40725d8cc0909607632045eb5a27b
Summary: public
The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed.
This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead.
The rules are now as follows:
* Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created
* Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread.
* All other modules will be initialized lazily when a method is first called on them.
These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily.
I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results:
Out of the 65 modules included in UIExplorer:
* 16 are initialized on the main thread when the bridge is created
* A further 8 are initialized when the config is exported to JS
* The remaining 41 will be initialized lazily on-demand
Reviewed By: jspahrsummers
Differential Revision: D2677695
fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
Summary: public
Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.
Fixed some type bugs and improved bridge validation in a few places.
Reviewed By: javache
Differential Revision: D2600189
fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
Summary:
Just trying to [getCurrentPosition](https://github.com/facebook/react-native/blob/master/Libraries/Geolocation/Geolocation.js#L45) , and found the `errorBlock` of location request in timeout handler would cause red error like this:
```
2015-05-10 17:50:39.607 [warn][tid:com.facebook.React.JavaScript] "Warning: Cannot find callback with CBID 5. Native module may have invoked both the success callback and the error callback."
2015-05-10 17:50:39.610 [error][tid:com.facebook.React.JavaScript] "Error: null is not an object (evaluating 'cb.apply')
stack:
_invokeCallback index.ios.bundle:7593
<unknown> index.ios.bundle:7656
<unknown> index.ios.bundle:7648
perform index.ios.bundle:6157
batchedUpdates index.ios.bundle:13786
batchedUpdates index.ios.bundle:4689
<unknown> index.ios.bundle:7647
applyWithGuard index.ios.bundle:882
guardReturn index.ios.bundle:7421
processBatch index.ios.bundle:7646
URL: http://192.168.100.182:8081/index
Closes https://github.com/facebook/react-native/pull/1226
Github Author: henter <henter@henter.me>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
As per #750, throw error when trying to use the geolocation module and this key is not set. cc @frantic
Closes https://github.com/facebook/react-native/pull/762
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Sophie Alpert
ngandhy
Adam Comella
Jason Gaare
Marcus do Nascimento
Pieter De Baets
Héctor Ramos
Rob Hogan
Martin Kralik
Nick Lockwood
Konstantin Raev
Jean-Richard Lai
realaboo
Gašper Žnidaršič Bečaj
Christopher Dro
Sebastian Gronewold
Marc Shilling
Jiajie Zhu
henter
Tadeu Zagallo
Brent Vatne
Alex Akers
Christopher Chedeau
