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:
Implement a handler to allow intercepting all RN redboxes in Android, including exceptions in both JS and Java.
The handler is not open sourced, so there is only an open-source interface called **RedBoxHandler** in //fbandroid/java/com/facebook/catalyst/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/devsupport//, meantime there is an internal class called **FBRedBoxHandler**, which implements **RedBoxHandler** and is located in //fbandroid/java/com/facebook/fbreact/redboxhandler//, actually handles the exception information.
The code structure is as follows:
- **AdsManagerActivity** has a member variable of **FBRedBoxHandler**.
- **AdsManagerActivity** passes this handler all the way down to the **DevSupportManagerImpl**, through** ReactInstanceManager**, **ReactInstanceManagerImpl**, **DevSupportManagerFactory**.
- **DevSupportManagerImpl** intercepts the exceptions just before showing the redboxes, like this:
mRedBoxDialog.setExceptionDetails(message, stack);
mRedBoxDialog.setErrorCookie(errorCookie);
if (mRedBoxHandler != null) {
mRedBoxHandler.handleRedbox(message, stack);
}
mRedBoxDialog.show();
By now, the internal class just prints information for each redbox to logcat, including exception message and stack trace.
Reviewed By: mkonicek
Differential Revision: D3369064
fbshipit-source-id: 199012c4b6ecf4b3d3aff51a26c9c9901847b6fc
Summary:
Issue reported here
https://github.com/facebook/react-native/issues/7755#issuecomment-222950463
Converting int to Integer explicitly and not cancelling the call more than once
should fix it.
Reviewed By: bestander
Differential Revision: D3371238
fbshipit-source-id: cb00663b4ca19a788bd27b971b6447cc0788a818
Summary: These will, eventually, need to be moved to the new bridge and so must become standalone things. For *NativeArray, this is almost just moving them out into their own .h/.cpp files. The *NativeMaps are updated to be hybrids instead of countables (in addition to getting their own .h/.cpp).
Reviewed By: mhorowitz
Differential Revision: D3325169
fbshipit-source-id: 40cfcab92b3fb2310bcd4de8f39e82f85d404abd
Summary:
Just rename and rearrange the dev menu options in Android, so as to be consistent with those in iOS.
{F61192593} {F61192595}
{F61192594} {F61192597}
There are other issues to solve on the inspector and profiling in Android, so I just ignore them for now.
Reviewed By: mkonicek
Differential Revision: D3361415
fbshipit-source-id: ffa823a0c54a27f7918e4e43ecea3c845d2a2f90
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:
As for symbolicated stack trace in the red box in Android, make column number not shown if it's zero.
Format Before:
{F61180667}
Format After:
{F61180666}
Reviewed By: mkonicek
Differential Revision: D3358317
fbshipit-source-id: 87981e678e22ab9f483727002175c8835941ceee
Summary:
When the activity hosting a Modal goes away, we should dismiss the dialog from the stack and then reconstitute it when the activity comes back. This means that if an activity is paused because another activity is placed on top of it but our ui operation was delayed, it will not blow up finding no window since it is gone.
Also fixes a place where we should remove a listener for lifecycle events which we were not doing.
Reviewed By: halfjuice
Differential Revision: D3357286
fbshipit-source-id: c5c6dd8e5ef299762ed9aa15a6910ce9c0b111dc
Summary:
The API for `ActivityIndiatorIOS` and `ProgressBarAndroid` is very similar and can be merged in a cross platform component that displays a circular indeterminate loading indicator.
This deprecates `ActivityIndiatorIOS` and non-horizontal `ProgressBarAndroid` in favor of this new component.
**Test plan (required)**
Tested with the ActivityIndicator example in UIExplorer on android and ios. Also made sure that `ActivityIndicatorIOS` still works and displays a deprecation warning. Also tested that `ProgressBarAndroid` with `indeterminate == true` and `styleAttr != 'Horizontal'` displays a deprecation warning.
Closes https://github.com/facebook/react-native/pull/6897
Differential Revision: D3351607
Pulled By: dmmiller
fbshipit-source-id: b107ce99d966359003e8b3118cd97b90fa1d3d7d
Summary:
Improved version of #7317.
`setRefreshing` and `setProgressViewOffset` needs to be called after the view has been layed out. Instead of using `post` to do that we update the `refreshing` and `progressViewOffset` values in the first call to `onLayout`.
I also noticed that `progressViewOffset` default value wasn't exactly the same as when not calling `setProgressViewOffset` at all. Tweaked the values to match android defaults.
**Test plan (required)**
Make sure the integration test passes,
In UIExplorer: test RefreshControl with `refreshing = true` initially, test `progressViewOffset`.
Closes https://github.com/facebook/react-native/pull/7683
Differential Revision: D3334426
fbshipit-source-id: ddd63a5e9a6afe2b8b7fe6a25e875a40f4e888c6
Summary:
The JSCExecutor API gets passed script data and a URL, but
the proxy's purpose in life is to load from the network, so the script
data is useless. The code was failing to handle null script data, so
rather than just passing nullptr all the time, I removed the argument.
if there's a use case in the future for it, we can put it back.
Reviewed By: steveluscher
Differential Revision: D3312467
fbshipit-source-id: 986c48f1ef3c24e6b5569046ccb08d7864cdcd3d
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:
Hi,
This changelist is for fixing a crash issue on Android devices. For detail please see, https://github.com/facebook/react-native/issues/7080
In short, the crash occurred when a RN app with a Alert dialog shown at front switches back after it is destroyed at background due to lack of phone memory.
My fix is to let those Alert fragment classes accessible from android.support.v4.app.Fragment instantiate() function, so that it won't crash. And since other UI will be reloaded whatever, mListener is set to null to avoid any callback happen.
Closes https://github.com/facebook/react-native/pull/7105
Differential Revision: D3212435
Pulled By: mkonicek
fbshipit-source-id: d900a33a4f0fd49258be94c277def55555ec8d73
Summary:
We want to give people the ability to log scroll performance (including Fb).
This adds an interface that can be enabled and disabled from the react scroll views.
This is a prerequisite to implementing the actual framerate logger that will log dropped
frames while scrolling in prod.
Reviewed By: astreet
Differential Revision: D3283588
fbshipit-source-id: ed9736cb9ed3f441511647f36b1460092bd91e56
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:
I ran into problems when using Clipboard.getString() in Android. The method seems to work fine when there is *something* in the clipboard, but when it's empty the app crashes. I think I've tracked down the bug to ClipboardModule.java@58.
When clipData is null, the promise is resolved with an empty string. However, after that the rest of the block is executed. There should be a return or an 'else if' like in my pr.
Screenshot of the error message when clipboard is empty:
Closes https://github.com/facebook/react-native/pull/7527
Differential Revision: D3292232
fbshipit-source-id: d2191286c49ee31233203fab4648449964b9d950
Summary:
There was a race condition with `SwipeRefreshLayout` that cause the `RefreshControl` to keep refreshing when it shouldn't.
It was caused because we have to use `post` to set the refreshing state otherwise it doesn't work when setting `refreshing=true` on initial mount. What happened is that `post` doesn't guarantee the order the runnables will be called so calling post with `refreshing=true` followed by `refreshing=false` caused the `resfreshing=false` runnable to be called before the `resfreshing=true` one. This made it stay in refreshing state when it should not.
```
D/test ( 6171): setRefreshing true
W/ReactNativeJS( 6171): false
D/test ( 6171): setRefreshing false
D/test ( 6171): setRefreshing post false
D/test ( 6171): setRefreshing post true
```
This change adds an instance variable and uses it in the `post` runnable to make sure the last set value is always used.
**Test plan (required)**
Tested that it fixed the issue in the [original issue app](https://github.com/digisqu
Closes https://github.com/facebook/react-native/pull/7317
Differential Revision: D3290464
Pulled By: andreicoman11
fbshipit-source-id: 15cabcfc6d2f191443be96e8845b924ce66c369f
Summary:
This is a nice feature to have.
I've tested this by copying and renaming the ViewPager java and javascript files from the react-native repo and including them in a project. Whats the best way to test this directly from the repo?
Closes https://github.com/facebook/react-native/pull/5968
Differential Revision: D3240651
Pulled By: mkonicek
fbshipit-source-id: 5f1d157216df4f3314915496188a92aec1b85e91
Summary:
Older Android devices don't have a large stack by default and with about 16 levels of views the app will crash. Modern Android devices are fine so we can continue to use the system defaults while using a 2MB stack on older Android devices.
Closes https://github.com/facebook/react-native/pull/7416
Differential Revision: D3276805
Pulled By: astreet
fbshipit-source-id: a7b31a1be62e13f333148ca0908eb01a11aa4562
Summary:
Currently the Modal component on Android is rendered below the Status Bar, which changes it's color to grey, and in the UIExplorer example the backdrop is just formatted to look the same color. In some scenarios users may want to preserve the color of their status bar and make it look as though the modal is appearing on top. This PR allows for that.
This GIF shows current behavior and new behavior with the translucentStatusBar prop set to true.
I've updated the UIExplorer app to demonstrate and the docs as shown below
Thanks!
Closes https://github.com/facebook/react-native/pull/7157
Differential Revision: D3264497
Pulled By: dmmiller
fb-gh-sync-id: 61346d99414d331d3420f44a4c5f6341b0973be6
fbshipit-source-id: 61346d99414d331d3420f44a4c5f6341b0973be6
Summary:
We previously were unmounting the react application unconditionally when the ReactRootView#onDetachedFromWindow. This is nice in that it automatically allows us to reclaim memory, but there are many scenarios where a ReactRootView can be embedded in another piece of UI that detaches its children as part of its normal function (e.g. ListView, RecyclerView, ViewPager, etc).
As such, we will now enforce that the hosting Activity/Fragment/??? explicitly calls unmountReactApplication in the same way it calls startReactApplication. For Applications extending ReactActivity/AbstractReactActivity, this will happen automatically in onDestroy.
Reviewed By: foghina
Differential Revision: D3265161
fb-gh-sync-id: 4d49b0c41256213f00874f57e784aa8741dbf394
fbshipit-source-id: 4d49b0c41256213f00874f57e784aa8741dbf394
Summary:
Add the possibility to define a progress view top offset to RefreshControl on android. As i comment in #6740, contentInset does the trick on IOS.
Looking android documentation seems that exists a possible solution:
http://developer.android.com/reference/android/support/v4/widget/SwipeRefreshLayout.html#setProgressViewOffset(boolean, int, int)
This pull request implement that but keeping it simple, only a top offset.
For example, now we could put navigation bar over the scrollview (or listview) and define a progressViewOffset on RefreshView in order to start behind the navigation. At this point we could make some kind of coordinator layout to hide/show navigation on scroll.
To maintain the default behavior, start point is equal to start point minus progress circle diameter in order to create that progress circle before the start point.
Closes https://github.com/facebook/react-native/pull/6759
Differential Revision: D3240664
Pulled By: mkonicek
fb-gh-sync-id: ccf866272e871811c1c6dcc2a34f5c217967feee
fbshipit-source-id: ccf866272e871811c1c6dcc2a34f5c217967feee
