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:
[This commit](e730a9fdd0) (_Load assets from same folder as JSbundle (Android)_) causes React Native to look for assets inside the same folder the JSBundle was loaded from and generates asset URIs containing the absolute path to the asset (e.g. _/sdcard/bundle/drawable-xxhdpi/ic_back.png_).
While this is fine for a normal `ImageView`, `ToolbarAndroid`/`ReactToolbar` currently crashes if the icons are located on the file system. This happens because when setting an icon on `ReactToolbar`, Fresco is only used if the icon URI contains `http:// `or `https://`. For all other cases (like in this case where it starts with `file://`), the view tries to load the Drawable from the Android App Resources by it's name (which in this case is an absolute file-URI) and therefore causes it to crash (`getDrawableResourceByName` returns 0 if the Drawable was not found, then `getResources().getDrawable(DrawableRes int id)` throws an Exception if th
Closes https://github.com/facebook/react-native/pull/5753
Reviewed By: svcscm
Differential Revision: D2921418
Pulled By: foghina
fb-gh-sync-id: 7a3f81b530a8c1530e98e7b592ee7e44c8f19df1
shipit-source-id: 7a3f81b530a8c1530e98e7b592ee7e44c8f19df1
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:
This is a cut down version of a previous pull request with just the 4 corners catered for.
Closes https://github.com/facebook/react-native/pull/4252
Reviewed By: svcscm
Differential Revision: D2911959
Pulled By: androidtrunkagent
fb-gh-sync-id: 7ddcd684d90d4d92ccefed906c0126e92818dcde
Summary:
Expose method to implement changing font family cache. Like ide suggested in #4420 , this will helpful for using remote font file (use `Typeface#createFromFile` to load downloaded font file).
iOS's CoreText already allow this in native code.
Closes https://github.com/facebook/react-native/pull/4696
Reviewed By: bestander
Differential Revision: D2911762
Pulled By: andreicoman11
fb-gh-sync-id: a931e2e711dd94fa0df6fdd066827756d862a4ba
Summary:
RefreshControl did not start refreshing when refreshing was set to true initially. It also did not start refreshing on iOS when setting the prop from false to true without doing a pull to refresh gesture.
This was a pain in the ass to make work on iOS because UIRefreshControl seems super sensitive to when beginRefreshing can be called, for the initial render I need to call it in layoutSubviews. I also have to manually adjust the scrollview content offset when calling beginRefreshing. The code is a bit hacky but it was the only solution I found that was actually working.
Fixes#5716
Closes https://github.com/facebook/react-native/pull/5745
Reviewed By: svcscm
Differential Revision: D2910716
Pulled By: nicklockwood
fb-gh-sync-id: d60e73bcfe8d86bb01249ba5f17e6a23c5a5aff6
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:
`debugger.html` contained a ton of hacky code that was needed to ensure we have a clean JS runtime every time a client RN app connects. That was needed because we used the page's global environment as runtime. Some time ago WebWorker support was added and now we run RN code inside an isolated WebWorker instance, and we can safely get rid of all these hacks.
This has a bunch of nice side-effects: debug reload works faster, `console.log`s are preserved, `debuggerWorker.js` selection doesn't change.
Made sure the debugging (breakpoints, etc.) still works as before.
Small demo
Closes https://github.com/facebook/react-native/pull/5715
Reviewed By: svcscm
Differential Revision: D2906602
Pulled By: frantic
fb-gh-sync-id: 1a6ab9a5655d7c32ddd23619564e59c377b53a35
Summary:
The change in 8e603940e3 actually causes a super bad bug when `context.getResources().getDisplayMetrics()` is accessed in other parts of the application.
It turns out that when you dive into the impl of `getRealMetrics`, it mutates whatever `DisplayMetrics` object is passed to it. In this case, `getDisplayMetrics` ends up mutating the `DisplayMetrics` object that sits on the application context's `Resources` instance.
This PR makes that not so.
/cc jesseruder ide jaysoo bestander astreet
Closes https://github.com/facebook/react-native/pull/5764
Reviewed By: svcscm
Differential Revision: D2902386
Pulled By: androidtrunkagent
fb-gh-sync-id: 3f24b68bc7e6b4ca83808c03ef3637e1ac9a673e
Summary:
Perhaps there is a better way to do this, curious to hear it!
- If momentum scroll is active when `scrollEnabled` is toggled, the momentum scroll continues and the onMomentumScrollEnd event fires, which is the same as on iOS.
Closes https://github.com/facebook/react-native/pull/5656
Reviewed By: svcscm
Differential Revision: D2889897
Pulled By: dmmiller
fb-gh-sync-id: b2f44d2bcb48373f9945f6afd966447a118df717
Summary:
I started working on improving the `StatusBar` API and make it work on Android. I added support for `setColor`, `setTranslucent` (the status bar is still visible but the app can draw under) and `setHidden` on Android. Looking for feedback on how to improve the API before I put more time on this :).
Right now I went for a cross platform API and functions that don't exist on a platform are just a no-op but I'm not sure it is the best choice since at the moment what is supported is very different between both platforms. I was wondering what you guys think and if it would be better off as 2 different modules.
It is also possible to port some of the features I added for Android to iOS even if there is no 'standard' way to do it. Like `setColor` could be implemented by drawing a colored view under the status bar and translucent by adding/removing some padding.
Closes https://github.com/facebook/react-native/pull/5360
Reviewed By: svcscm
Differential Revision: D2840417
Pulled By: nicklockwood
fb-gh-sync-id: 5c8d988bccf8035341f0efe27e54dd8402c18d24
Summary:
public
This adds support to set the highlight color on TextInput on Android. See https://github.com/facebook/react-native/pull/5678 for the iOS implementation.
Note : We will merge these two properties with one name 'selectionColor' in a follow on diff, and may move it to a style.
Reviewed By: nicklockwood
Differential Revision: D2895253
fb-gh-sync-id: 6f2c08c812ff0028973185356a8af285f7dd7969
Summary:
The bug occurs for the cases when there is a nested view structure of at least two views with removeClippedSubvews enabled and with a "collapsable" view in between them that migrates from the collapsed state to non-collapsed state.
What happens in that case is that the "inner" view with "removeClippsedSubviews" gets reattached to a new parent, but we never update it's clipping rect because the update is currently only triggered for the size change (and for scroll change in case of scrollview). In the case when the view was doing some "clipping" when attached to its previous parent it needs to update its "clipping" status because the parent has change and clipping rect is calculated based on the parent clipping rect (see `ReactClippingViewGroupHelper#calculateClippingRect`).
This change triggers `updateClippingRect` when the view is attached to the window, which covers the case when it's reattached from one parent to the other.
Closes https://github.com/facebook/react-native/pull/5692
Reviewed By: svcscm
Differential Revision: D2893304
Pulled By: foghina
fb-gh-sync-id: a94ab3674adf9e496fc86dca5a430a91117f2c83
Summary:
Original Android's refreshControl in ScrollView is tightly coupled with AndroidSwipeRefreshLayout. If someone use `ref=` for RefreshControl in ScrollView, it does nothing since RefreshControl in Android return null.
This change allows customized RefreshControl especially for `ref=` as well as making ScrollView's code clearer.
Closes https://github.com/facebook/react-native/pull/5623
Reviewed By: svcscm
Differential Revision: D2890072
Pulled By: nicklockwood
fb-gh-sync-id: a8fc7746bcc050a6e46fedf3583979f4cb9021b6
Summary:
public
This diff fixes two issues:
1) Makes it so that when a keyboard is displayed, all keys in that keyboard actually can be set as text. Previously you could display a Numeric keyboard and it would only allow entering numbers despite the keyboard having other keys like comma, plus, space, etc.
a) This also allows any key entered on a physical keyboard to go through to the view even if not present on the Soft Input keyboard
2) Makes more robust our Filter setting in setMaxLength so that we only affect the InputFilter.LengthFilter if present instead of all.
This works by creating a new KeyListener which will respond to getInputType as the KeyListener it is replacing (like a DigitsKeyListener for a numeric keyboard) but allow all characters when actually entering text.
Reviewed By: andreicoman11
Differential Revision: D2880851
fb-gh-sync-id: fa5eb549a849d8f30c592d7eac48054ca6a75544
Summary:
public
https://github.com/facebook/react-native/pull/5494 added a new `source` property to WebView on Android that provides a better API, as well as allowing for request headers to be set.
This diff ports that functionality over to iOS, so we can have a consistent API cross-platform.
I've also extended the API to include `method` (GET or POST) and `body` when setting the WebView content with a URI, and `baseUrl` when setting static HTML.
Reviewed By: javache
Differential Revision: D2884643
fb-gh-sync-id: 83f24494bdbb4e1408aa8f3b7428fee33888ae3a
Summary:
Related to [issue #5418](https://github.com/facebook/react-native/issues/5418)
This is a follow-up to [this previous pull request.](https://github.com/facebook/react-native/pull/5419)
~~Adds a new ReactProp 'urlWithHeaders' to Android WebViews that takes an object with a 'url' string and a 'headers' map.~~
[Update] Adds a new prop 'source' to Android WebViews
```
{
html: string,
url: string,
headers: map<string, string>,
}
```
Update: resolves TODO 8495359
Closes https://github.com/facebook/react-native/pull/5494
Reviewed By: svcscm
Differential Revision: D2881313
Pulled By: nicklockwood
fb-gh-sync-id: 7cad8490d4932d0a7ef559165f3ec279d873c537
Summary:
public
We recently updated the `ScrollResponder.scrollResponderScrollTo` method to accept an `animated` argument, and deprecated the `scrollResponderScrollWithoutAnimationTo` method. This change was reflected in the native iOS implementation, but not on Android.
This diff updates the Android ScrollViewManager implementation to match the JS API, and removes the platform-specific fork in the JS code.
Reviewed By: dmmiller
Differential Revision: D2883515
fb-gh-sync-id: e5a0e1cf470e21af837b2311cf1048162ac3aff5
Summary:
This change fixes a bug in getTopOffsetForItem method of RecyclerViewBackedScrollView that was causing Y offset of onScroll events to be invalid when user would scroll up. I'm also adding some comments to this method which may help to understand its complexity.
Closes https://github.com/facebook/react-native/pull/5610
Reviewed By: svcscm
Differential Revision: D2880743
Pulled By: androidtrunkagent
fb-gh-sync-id: 7183e3d6760fab5683afc49d454864239260fb91
Summary:
public
This diff adds support for providing custom scaletypes to Drawee. The implementation for the preexisting scale types is preserved.
Breaking changes should be minimal. In fact, only direct usages of `ScalingUtils.getTransform(..., scaleType)` should be converted to `scaleType.getTransform(...)`.
Reviewed By: kirwan
Differential Revision: D2862911
fb-gh-sync-id: ab0355fd13544dc08ce4481eda87287404ea7adb
Summary:
The basic API is consistent with iOS; there are several platform-specific props.
Also fixed the flickering when a value is selected.
public
Reviewed By: bestander
Differential Revision: D2871092
fb-gh-sync-id: f5cdf6858cb7344b28ee46954cb6b0a3b144b646
Summary:
I have an issue when combining `PullToRefreshViewAndroid` and `ViewPagerAndroid`.
`ViewPagerAndroid` will not able to scroll that gesture handler is being taken by `PullToRefreshViewAndroid`
One solution is to disable `PullToRefreshViewAndroid` if `ViewPagerAndroid` is scrolling (i.e. not idle).
[Reference solution here](http://stackoverflow.com/a/29946734/2590265)
So here need to expose the `onPageScrollStateChanged` event.
Some code referenced from DrawerLayoutAndroid, especially the `VIEWPAGER_PAGE_SCROLL_STATES` array.
Please feel free give me comments.
Thanks.
Closes https://github.com/facebook/react-native/pull/5026
Reviewed By: svcscm
Differential Revision: D2830623
Pulled By: andreicoman11
fb-gh-sync-id: c2a6920c6f4c7daab0115f13864db83b93b31abf
Summary:
I've found that when switching between tabs that each have ScrollViews, sometimes `emitScrollEvent` fires without a `contentView`, which causes the following crash:
```
`D/AndroidRuntime(24496): Shutting down VM
E/AndroidRuntime(24496): FATAL EXCEPTION: main
E/AndroidRuntime(24496): Process: com.listexp, PID: 24496
E/AndroidRuntime(24496): java.lang.NullPointerException: Attempt to invoke virtual method 'int android.view.View.getWidth()' on a null object reference
E/AndroidRuntime(24496): at com.facebook.react.views.scroll.ReactScrollViewHelper.emitScrollEvent(ReactScrollViewHelper.java:59)
E/AndroidRuntime(24496): at com.facebook.react.views.scroll.ReactScrollViewHelper.emitScrollMomentumEndEvent(ReactScrollViewHelper.java:46)
E/AndroidRuntime(24496): at com.facebook.react.views.scroll.ReactScrollView$1.run(ReactScrollView.java:159)
E/AndroidRuntime(24496): at android.os.Handler.handleCallback(Handler.java:739)
E/AndroidRuntime(24496): at android.os.Handler.disp
Closes https://github.com/facebook/react-native/pull/5561
Reviewed By: svcscm
Differential Revision: D2876385
Pulled By: androidtrunkagent
fb-gh-sync-id: 33406eaa96352d5adae857088da09fb446b68440
Summary:
public
When initially implemented, the timeout for a request was actually set for all requests that the OKHttpClient handled, not just that request.
The fix is to clone the client, set the timeout for the client which will be used for that request.
Reviewed By: andreicoman11
Differential Revision: D2873220
fb-gh-sync-id: c8c102a6eb9dd0ac57d5a7f53c3ba3b7d6db5ef9
