Summary:
revision of https://github.com/facebook/react-native/pull/5476
It has only one method `shareTextContent` and next will be`shareBinaryContent`.
In Android, Promise can't receive a result, because `startActivityForResult` is not working with `Intent.ACTION_SEND`. Maybe we can use `createChooser(Intent target, CharSequence title, IntentSender sender)` which requires API level 22.
Closes https://github.com/facebook/react-native/pull/5904
Differential Revision: D3612889
fbshipit-source-id: 0e7aaf34b076a99089cc76bd649e6da067d9a760
Summary: This is pure cleanup so that we can make sure that all events are living in the same time space (currently nano seconds).
Reviewed By: foghina
Differential Revision: D3593884
fbshipit-source-id: 71b084362008f1c93c21880630acf11f5c058355
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 removes `node_modules/react` from the list of directories that are used for haste module resolutions. Modules required from React are now imported with `require('react/lib/…')`.
Reviewed By: astreet
Differential Revision: D3509863
fbshipit-source-id: 32cd34e2b8496f0a6676dbe6bb1eacc18124c01e
Summary:
This should revert back to using old bridge by default until we fix gradle script to build new bridge for OSS correctly
Closes https://github.com/facebook/react-native/pull/8539
Differential Revision: D3514263
Pulled By: bestander
fbshipit-source-id: db9e0232b9bde27206814212dedc487c366e3511
Summary:
Currently, DevTools only work under ios (although this is undocumented!),
because the JavaScriptEngine initialization process skips setupDevTools() on
android.
DevTools work fine with Android, as tested on 0.26, 0.27, and 0.28 using
Nuclide's inspector.
For reference, the relevant issue on react-devtools.
Closes https://github.com/facebook/react-native/pull/8095
Reviewed By: bestander
Differential Revision: D3492788
Pulled By: andreicoman11
fbshipit-source-id: 1eda9196d7125da19a8d7baaab22b61b744ca629
Summary:
Currently, DevTools only work under ios (although this is undocumented!), because the JavaScriptEngine initialization process skips setupDevTools() on android.
DevTools work fine with Android, as tested on 0.26, 0.27, and 0.28 using Nuclide's inspector.
For reference, [the relevant issue on react-devtools](https://github.com/facebook/react-devtools/issues/229).
Closes https://github.com/facebook/react-native/pull/8095
Reviewed By: javache
Differential Revision: D3443980
Pulled By: bestander
fbshipit-source-id: ce0f7dd62ae0f7dfe6654380821660f8660318a6
Summary:
Currently, DevTools only work under ios (although this is undocumented!), because the JavaScriptEngine initialization process skips setupDevTools() on android.
DevTools work fine with Android, as tested on 0.26, 0.27, and 0.28 using Nuclide's inspector.
For reference, [the relevant issue on react-devtools](https://github.com/facebook/react-devtools/issues/229).
Closes https://github.com/facebook/react-native/pull/8095
Reviewed By: javache
Differential Revision: D3443980
Pulled By: andreicoman11
fbshipit-source-id: 3d7b2e83cf4158a1228d2e21510509ab63411a5d
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:
1. Make "Remote JS Debug" and "Start/Stop Profile" options persist across app restarts.
2. Check and confirm:
- All options in the Android dev menu are persisted now.
- The behavior is the same on Android and iOS now.
Reviewed By: mkonicek
Differential Revision: D3340097
fbshipit-source-id: 4087b6605031c650e164282244cedb006f8f6fd3
Summary:
- TestIdTestModule instrumentation tests is responsible for too many occasional crashes, e.g. https://circleci.com/gh/facebook/react-native/7054.
This should fix the problem (will monitor over next week)
- Made file naming more consistent
- 5 retries don't make e2e tests more stable, reduced back to 3 but I need to investigate how to make it more reliable
Closes https://github.com/facebook/react-native/pull/7784
Differential Revision: D3354444
fbshipit-source-id: d058362edbec09522a4828998e01988a82a74487
Summary:
Removes the deprecated APIs that were replaced by `RefreshControl`. Those API have been deprecated for a while already so I think it's fine to remove them at this point. Also ported the `SwipeRefreshLayoutTestModule` test to use `RefreshControl` instead of `PullToRefreshViewAndroid`.
**Test plan (required)**
Made sure no references are left in the codebase to `PullToRefreshViewAndroid`, `onRefreshStart` and `endRefreshing`.
Tested that `ScrollView` examples in UIExplorer still work properly.
Check that the `SwipeRefreshLayoutTestModule` passes on CI.
Closes https://github.com/facebook/react-native/pull/7447
Reviewed By: mkonicek
Differential Revision: D3292391
Pulled By: bestander
fbshipit-source-id: 27eb2443861e04a9f7319586ce2ada381b714d47
Summary:
Got this error when trying to run instrumentation tests locally with `./scripts/run-android-local-integration-test.sh`
```
C:\Users\janic\Developer\react-native\ReactAndroid\src\androidTest\java\com\facebook\react\tests\DatePickerDialogTestCase.java:110: error: cannot access com.facebook.react.modules.core.DefaultHardwareBackBtnHandler
return (DialogFragment) getActivity().getSupportFragmentManager()
^
class file for com.facebook.react.modules.core.DefaultHardwareBackBtnHandler not found
C:\Users\janic\Developer\react-native\ReactAndroid\src\androidTest\java\com\facebook\react\tests\ViewRenderingTestCase.java:82: error: cannot access com.facebook.react.touch.ReactInterceptingViewGroup
assertEquals("Incorrect (or not applied) opacity", expectedOpacity, view.getAlpha());
^
class file for com.facebook.react.touch.ReactInterceptingViewGroup not found
C:\Users\janic\Developer
Closes https://github.com/facebook/react-native/pull/7575
Differential Revision: D3306330
fbshipit-source-id: a6d8afd060b54d56f9e2b97f45b642d7b7f46209
Summary:
More instrumentation tests in OSS means less work for FB engineers to investigate if a PR breaks some internal tests.
+ increased timeouts and retries for OSS tests runner
Reviewed By: andreicoman11
Differential Revision: D3292582
fbshipit-source-id: 3f8aa4d3536450ea3af7acff044b9bb62be0f9db
Summary: Fixes a race condition where JS module functions could be called in between ##initializeWithInstance(catalystInstance);## and ##CatalystInstance#runJSBundle##, before the BatchedBridge in JS was set up. We now guarantee that all JS module methods that are called after `ReactContext#hasActiveCatalystInstance()` returns true will have the batched bridge created and ready to use.
Reviewed By: lexs
Differential Revision: D3258651
fb-gh-sync-id: 66e66533cc86d185e7c865376d6a5cdc6520d2d4
fbshipit-source-id: 66e66533cc86d185e7c865376d6a5cdc6520d2d4
Summary:
This change makes all instrumentation tests to be executed in sequence in independent retriable processes.
With a new test being open sourced recently our CI stability degraded.
This PR should bring back stability because tests won't affect each other and will have shorter lifetime
Closes https://github.com/facebook/react-native/pull/7353
Differential Revision: D3259081
fb-gh-sync-id: 48ccdb5dbd561d416526497ff474378db9ca3c60
fbshipit-source-id: 48ccdb5dbd561d416526497ff474378db9ca3c60
Summary:Added ability to run instrumentation tests with BUCK.
This change uses BUCK to build and run instrumentation tests facebook style.
The gains are that we can execute the same tests internally at FB and in OSS.
Also running tests not via graddle:connect command is 1.5 minutes faster.
I'll keep keep an eye on stability Gradle and BUCK builds for a while.
Closes https://github.com/facebook/react-native/pull/6176
Differential Revision: D2999878
Pulled By: bestander
fb-gh-sync-id: d715ba231769e57100685a1256f2e530c589921c
shipit-source-id: d715ba231769e57100685a1256f2e530c589921c
