Summary:
In preparation for Blob support (wherein binary XHR and WebSocket responses can be retained as native data blobs on the native side and JS receives a web-like opaque Blob object), this change makes RCTNetworking aware of the responseType that JS requests. A `xhr.responseType` of `''` or `'text'` translates to a native response type of `'text'`. A `xhr.responseType` of `arraybuffer` translates to a native response type of `base64`, as we currently lack an API to transmit TypedArrays directly to JS. This is analogous to how the WebSocket module already works, and it's a lot more versatile and much less brittle than converting a JS *string* back to a TypedArray, which is what's currently going on.
Now that we don't always send text down to JS, JS consumers might still want to get progress updates about a binary download. This is what the `'progress'` event is designed for, so this change also implements that. This change also follows the XHR spec with regards to `xhr.response` and `xhr.responseText`:
- if the response type is `'text'`, `xhr.responseText` can be peeked at by the JS consumer. It will be updated periodically as the download progresses, so long as there's either an `onreadystatechange` or `onprogress` handler on the XHR.
- if the response type is not `'text'`, `xhr.responseText` can't be accessed and `xhr.response` remains `null` until the response is fully received. `'progress'` events containing response details (total bytes, downloaded so far) are dispatched if there's an `onprogress` handler.
Once Blobs are landed, `xhr.responseType` of `'blob'` will correspond to the same native response type, which will cause RCTNetworking to only send a blob ID down to JS, which can then create a `Blob` object from that for consumers.
Closes https://github.com/facebook/react-native/pull/8324
Reviewed By: javache
Differential Revision: D3508822
Pulled By: davidaurelio
fbshipit-source-id: 441b2d4d40265b6036559c3ccb9fa962999fa5df
Summary:
So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events.
This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.)
As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy.
Closes https://github.com/facebook/react-native/pull/8199
Differential Revision: D3528215
Pulled By: davidaurelio
fbshipit-source-id: d81732e50a5ece2168e8347309d8d52a0db42951
Summary:
So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events.
This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.)
As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy.
Closes https://github.com/facebook/react-native/pull/8199
Differential Revision: D3528215
Pulled By: dmmiller
fbshipit-source-id: cbd25bb7e7bb87fa77b661a057643a6ea97bc3f1
Summary:
This diff translates implementation of transform matrix decomposition from JS to java. This is to support offloading animations of transform property, in which case it is required that we can calculate decomposed transform in the UI thread.
Since the matrix decomposition code is not being used for other platform I went ahead and deleted parts that are no longer being used.
**Test plan**
Run UIExplorer Transform example before and after - compare the results
Closes https://github.com/facebook/react-native/pull/7916
Reviewed By: ritzau
Differential Revision: D3398393
Pulled By: astreet
fbshipit-source-id: 9881c3f565e2050e415849b0f76a0cefe11c6afb
Summary:
This adds support for specifying multiple sources for an image component, so that native can choose the best one based on the flexbox-computed size of the image.
The API is as follows: the image component receives in the `source` prop an array of objects of the type `{uri, width, height}`. On the native side, the native component will wait for the layout pass to receive the width and height of the image, and then parse the array to find the best fitting one. For now, this does not support local resources, but it will be added soon.
To see how this works and play with it, there's an example called `MultipleSourcesExample` under `ImageExample` In UIExplorer.
Reviewed By: foghina
Differential Revision: D3364550
fbshipit-source-id: 66c5aeb2794f2ffeff8da39a9c0b95155fb2d41f
Summary:
Reduce the public surface area of TextInput. It only exposes a secureTextEntry property, but on Android was also accepting password as a prop.
This removes that.
Reviewed By: javache
Differential Revision: D3392223
fbshipit-source-id: 67c36fbe16fe493e2841d5d9deb78e3be2209ebd
Summary:
When using FormData upload images or files, in Android version, network module cannot send an event for showing progress.
This PR will solve this issue.
I changed example in XHRExample for Android, you can see uploading progress in warning yellow bar.
Closes https://github.com/facebook/react-native/pull/7256
Differential Revision: D3390087
fbshipit-source-id: 7f3e53c80072fff397afd6f5fe17bf0f2ecd83b2
Summary:
Update to [OkHttp](https://github.com/square/okhttp) to [OkHttp3](https://publicobject.com/2015/12/12/com-squareup-okhttp3/)
We must also update:
- Fresco to 0.10.0
- okio to 1.8.0
**Motivation**
Reasons for upgrading:
* Issue #4021
* "We discovered that RN Android sometimes fails to connect to the latest stable version of NGINX when HTTP/2 is enabled. We aren't seeing errors with other HTTP clients so we think it's specific to RN and OkHttp. Square has fixed several HTTP/2 bugs over the past eight months." - ide
* OkHttp3 will be maintained & improved, but OkHttp2 will only receive [security fixes](https://publicobject.com/2016/02/11/okhttp-certificate-pinning-vulnerability/)
* Cleaner APIs - "Get and Set prefixes are avoided"
* Deprecated/Removed - HttpURLConnection & Apache HTTP
* React Native apps are currently being forced to bundle two versions of OkHttp (v2 & v3), if another library uses v3
* Improved WebSocket performance - [CHANGELOG.md](https://github.com/square/okhttp/blob/master
Closes https://github.com/facebook/react-native/pull/6113
Reviewed By: andreicoman11, lexs
Differential Revision: D3292375
Pulled By: bestander
fbshipit-source-id: 7c7043eaa2ea63f95854108b401c4066098d67f7
Summary: Use the more accurate timestamp that we have computed for the touch event rather than the event timestamp that Android provides.
Reviewed By: andreicoman11
Differential Revision: D3292705
fbshipit-source-id: dad082ab74406d391481d16cdac19629751aa1eb
Summary:This change adds native animated support for Animated.interpolate
Animated.interpolate allows for defining nodes that outputs an interpolated value of their input node based on the interpolation node configuration. For now native animated implementation only supports a linear interpolation for a given input and output ranges (ranges can consists of multiple segments). Native interpolation node is compatible with the JS implementation with the exception that not all attributes that can be used in JS are supported. Before we migrate interpolation node from JS->native we verify that only supported props are used.
**Test Plan**
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Run java tests: `buck test ReactAndroid/src/test/java/com/facebook/react/animated`
Closes https://github.com/facebook/react-native/pull/7141
Differential Revision: D3216546
fb-gh-sync-id: 29876e33956615c6370ca4d332abe048f8dba5b8
fbshipit-source-id: 29876e33956615c6370ca4d332abe048f8dba5b8
Summary:This change extends animated native module API with `stopAnimation` method that is responsible for interrupting actively running animation as a reslut of a JS call. In order for the `stopAnimation` to understand `animationId` argument I also had to add `animationId` to `startAnimation` method. As JS thread runs in parallel to the thread which executes the animation there is a chance that JS may call `stopAnimation` after the animation has finished. Because of that we are not doing any checks on the `animationId` parameter passed to `stopAnimation` in native and if the animation does not exists in the registry we ignore that call.
**Test Plan**
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Run java tests: `buck test ReactAndroid/src/test/java/com/facebook/react/animated`
Closes https://github.com/facebook/react-native/pull/7058
Differential Revision: D3211906
fb-gh-sync-id: 3761509651de36a550b00d33e2a631c379d3900f
fbshipit-source-id: 3761509651de36a550b00d33e2a631c379d3900f
Summary:This change adds native animated support for Animated.multiply nodes.
Animated.multiply allows for defining nodes that would output a product of values of the input nodes.
**Test Plan**
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Run java tests: `buck test ReactAndroid/src/test/java/com/facebook/react/animated`
Closes https://github.com/facebook/react-native/pull/7071
Differential Revision: D3197663
fb-gh-sync-id: 35f64244a2482c487a81e5e7cd08f3c0e56d9b78
fbshipit-source-id: 35f64244a2482c487a81e5e7cd08f3c0e56d9b78
Summary:This change adds suport native animated support for Animated.add.
Animated.add lets you declare node that outputs a sum of it input nodes.
**Test Plan**
Play with the following playground app: https://gist.github.com/39de37faf07480fcd7d1
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Run java tests: `buck test ReactAndroid/src/test/java/com/facebook/react/animated`
Closes https://github.com/facebook/react-native/pull/6641
Differential Revision: D3195963
fb-gh-sync-id: bb1e1a36821a0e071ad0e7d0fa99ce0d6b088b0a
fbshipit-source-id: bb1e1a36821a0e071ad0e7d0fa99ce0d6b088b0a
Summary:This change adds some basic unit tests for native animated traversal algorithm. The following tests are added:
1) Build simple animated nodes graph, verify that frame-based animation execute updates and when it runs out of the frames we no longer schedule updates for the native view
2) Build simple animated nodes graph and start short timing animation, verify that animation JS callback gets called.
As a part of this change I'm fixing an issue that tests allowed me to discover, where I forgot to clear updates queue at the end of `runUpdates` method. It was causing the view to be updated even if there was no active animation for it (actually it was mitigated by another bug in `hasActiveAnimations` I'm fixing here too).
I'm also adding Nullable annotation in a bunch of places. To lazy to send it as a separate change - sorry.
Going forward I'm planning on adding more tests. Currently the number of nodes is pretty limited so it's difficult to construct more complex graphs, but once I land Add/Multiply
Closes https://github.com/facebook/react-native/pull/6858
Differential Revision: D3168549
Pulled By: astreet
fb-gh-sync-id: 5295c75f3c7817775b5154bb808888650ff74e12
fbshipit-source-id: 5295c75f3c7817775b5154bb808888650ff74e12
Summary:Adds a `center` option to `Image`'s `resizeMode` prop, which doesn't enlarge images.
This is how it looks in UIExplorer:
{F60386921}
Reviewed By: dmmiller
Differential Revision: D3064284
fb-gh-sync-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
shipit-source-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
Summary: Calling setTimeout(f, 0) will currently schedule f to be called the next frame instead of immediately (which is how it behaves on iOS). This immediately calls back to JS and invokes the function.
Reviewed By: astreet, tadeuzagallo
Differential Revision: D3006125
fb-gh-sync-id: 9fa109ed82836a718cbb2e8cb21da4943d96f5f6
shipit-source-id: 9fa109ed82836a718cbb2e8cb21da4943d96f5f6
Summary: Example of a conversion to web worker support using the ExecutionContext API changes made in the last set of web worker diffs. WebWorkerSample now creates timers to show that we can dispatch timer calls to multiple JS contexts.
Reviewed By: lexs
Differential Revision: D2928657
fb-gh-sync-id: 17c5f8cd7c63624da43383da7c4160dc48482fe5
shipit-source-id: 17c5f8cd7c63624da43383da7c4160dc48482fe5
Summary:To support native modules in web workers, native modules need to have an notion of the JS executor/thread that called into them in order to respond via Callback or JS module call to the right executor on the right thread.
ExecutorToken is an object that only serves as a token that can be used to identify an executor/message queue thread in the bridge. It doesn't expose any methods. Native modules Callback objects automatically have this ExecutionContext attached -- JSModule calls for modules that support workers will need to supply an appropriate ExecutorToken when retrieving the JSModule implementation from the ReactContext.
Reviewed By: mhorowitz
Differential Revision: D2965458
fb-gh-sync-id: 6e354d4df8536d40b12d02bd055f6d06b4ca595d
shipit-source-id: 6e354d4df8536d40b12d02bd055f6d06b4ca595d
Summary:
public
https://github.com/facebook/react-native/pull/4935 changed the window dimensions for android by replacing them with the actual screen dimensions. This changes the window dimensions back to their original values and adds `Dimensions.get('screen')` for the actual screen dimensions of the device.
Reviewed By: astreet
Differential Revision: D2921584
fb-gh-sync-id: 5d2677029c71d50691691dc651a11e9c8b115e8f
shipit-source-id: 5d2677029c71d50691691dc651a11e9c8b115e8f
Summary:
As a part of this change I'm also renaming SimpleArray to JavaOnlyArray and SimpleMap to JavaOnlyMap. The main reason for the change is to support use-cases such as driving animations form the native code. In the case of native "animated" I'd like to be able to use the same interface as JS is using for updating the View properties. As view setters can take ReadableMap and ReadableArray as an argument in some cases it is necessary to create and pass those types to the setter. Using WritableNativeArray and WritableNativeMap for this purpose seems to me like a misuse and IMO will be less performant (vs java-only map/array) as those implementations of ReadableMap and ReadableArray proxies all their methods through JNI.
I'm also adding some additional class-level comments for the moved classes to avoid confusion and hopefuly prevent people from using those classess accidentally while writing native modules or methods that calls to JS.
Closes https://github.com/facebook/react-native/pull/5816
Reviewed By: svcscm
Differential Revision: D2911339
Pulled By: foghina
fb-gh-sync-id: 5b9a98d64f48d8bba34c15e3eecba2151da3577a
shipit-source-id: 5b9a98d64f48d8bba34c15e3eecba2151da3577a
Summary:
public
KeyboardListener needs DisplayMetrics to be initialized when it is attached. At
the moment, this breaks easily whenever we change these components, since DisplayMetrics are intialized
in a module and KeyboardListener is created eagerly in ReactRootView, whereas
ReactRootView can exist without the instance.
This changes to create DisplayMetrics as soon as possible, when the react
instance is built. The KeyboardListener is created and attached after the ReactRootView is
attached to an existing instance, point at which DisplayMetrics have to be
initialized.
Reviewed By: dmmiller
Differential Revision: D2911351
fb-gh-sync-id: 64d1805c5d5b2f6876adb694b565a2df059b381d
Summary:
Catalyst is the old project name. Rename a few files.
public
Reviewed By: bestander
Differential Revision: D2859553
fb-gh-sync-id: 65a87cc7bcc22f20326971becec02aa1c573e5b9
Summary:
Opening this in a separate PR but the discussion can be viewed on #4832.
Basically, this is a native implementation and is a bit more elegant. The consensus on my previous PR was that it should be done natively rather than in JS.
There's now no maximum valid timeout value and a timeout of 0 will never time out.
ontimeout isn't implemented (yet) in this PR.
cc nicklockwood ide philikon
Closes https://github.com/facebook/react-native/pull/5038
Reviewed By: svcscm
Differential Revision: D2838743
Pulled By: nicklockwood
fb-gh-sync-id: 774f864ac35082bf522f7665f4311bd3affbe82c
Summary:
public
The `DialogModule` requires `android.support.v4.app.FragmentManager` which means
every app that wants to use Dialogs would need to have its Activity extend the legacy
`android.support.v4.app.FragmentActivity`.
This diff makes the `DialogModule` work with both the Support `FragmentManager`
(for AdsManager & potentially other fb apps) and the `android.app.FragmentManager`
(for new apps with no legacy dependencies).
Also wrap the native module in the same `Alert` API that we have on iOS and provide
a cross-platform example. In my opinion the iOS Alert API is quite nice and easy to use.
We still keep `AlertIOS` around because of its `prompt` function which is iOS-specific
and also for backwards compatibility.
Reviewed By: foghina
Differential Revision: D2647000
fb-gh-sync-id: e2280451890bff58bd9c933ab53cd99055403858
Summary:
public
- Open source the unit test for `ClipboardModule`, start using the `ReactTestHelper` in two unit tests
- Fixes a few references to "pasteboard" in strings
Reviewed By: bestander
Differential Revision: D2739614
fb-gh-sync-id: e076940a3ae5c22314e181a37fe2c3f77a18cf85
