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:
fc94f1e6d0 and the following commits introduced some changes to the jni build but only changed the BUCK build files and not the gradle ones. This ports the changes to the gradle build files to fix the build.
Closes https://github.com/facebook/react-native/pull/5791
Reviewed By: svcscm
Differential Revision: D2910012
Pulled By: vjeux
fb-gh-sync-id: b6c7edfed6873d501e46e80a0c9f128d9df04ca4
Summary:
Everything below the bridge interacts with just a MessageQueueThread. The implementation (JMessageQueueThread) is injected from react/jni.
public
Reviewed By: astreet
Differential Revision: D2905178
fb-gh-sync-id: 8b138e746d5a96dd70837bb2149cd4e188fcdacc
Summary:
This just moves the jni code that actual figures out the cache dir into OnLoad.cpp and then passes it down to the JSCEXecutorFactory.
public
Reviewed By: astreet
Differential Revision: D2905176
fb-gh-sync-id: bedf52fbeaab6beabac25c87aad00a98ddf182f7
Summary:
So, this makes it so a set of behaviors that require accessing java can be injected from the jni/ folder. The behaviors are logging, perf logging, log markers and loading script from assets.
I'd argue that these should all actually be encapsulated by interfaces that are passed to the JSCExecutor/others (and I'd say that's regardless of whether they are injected from jni/ or not), but I wanted to stick to the least disruptive pattern for these changes.
public
Reviewed By: astreet
Differential Revision: D2905168
fb-gh-sync-id: 7c8c16cb77b8fc3d42750dacc6574259ad512ac2
Summary:
This adds a CountableJSExecutorFactory that derives from Countable. And uses that. Basically it allows code that doesn't need to know about jni or Countable not depend on it.
public
Reviewed By: astreet
Differential Revision: D2905163
fb-gh-sync-id: f2bfd5589a3185bb175ad51660b17be08ba62424
Summary:
Updates uses of FBLOG* and FBASSERT* to their glog equivalents.
public
Reviewed By: astreet
Differential Revision: D2905159
fb-gh-sync-id: 1f916283aa3de68d8469c8d4ca7fa0874cec28ef
Summary:
Native code accesses the Java Application through the ApplicationHolder. The application should be set on the holder as soon as possible. This change fixes a race in WebWorkersTest.
public
Reviewed By: astreet
Differential Revision: D2905157
fb-gh-sync-id: 7e488f4eecefedb8482276776b3a66e14a843f90
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
![](http://g.recordit.co/FPdVHLHPUW.gif)
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:
public
JSC enforces a stack-alignment that wasn't always being provided on x86 builds. See D2886997.
Reviewed By: foghina
Differential Revision: D2900982
fb-gh-sync-id: 3f8dffcc1c528a4c21d7ed0b17e49d87761b1df7
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:
Rather than specifying Babel plugins in the `.babelrc` packaged with react-native, leverage a Babel preset to define the plugins (https://github.com/exponentjs/babel-preset-react-native).
This allows for a much better user experience for those who want (or need) to override options in their project's `.babelrc`.
Prior to this PR, if a user wanted to use a custom babel-plugin (or a custom set of babel plugins), they'd have either 1) manually override the `.babelrc` in the react-packager directory (or fork RN), or 2) specify a custom transformer to use when running the packager that loaded their own `.babelrc`. Note - the custom transformer was necessary because without it, RN's `.babelrc` options would supersede the options defined in the project's `.babelrc`...potentially causing issues with plugin ordering.
This PR makes the transformer check for the existence of a project-level `.babelrc`, and if it it's there, it _doesn't_ use the react-native `.babelrc`. This prevents any oddities with Babel plug
Closes https://github.com/facebook/react-native/pull/5214
Reviewed By: davidaurelio
Differential Revision: D2881814
Pulled By: martinbigio
fb-gh-sync-id: 4168144b7a365fae62bbeed094d8a03a48b4798c
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:
This error occurs primarily when starting the app and the packager is not running.
`source` can be null when the evaluated code does not come from a source file so it just crashes with a SIGSEGV when passing it to `String::adopt`. This restores the beloved 'Can't find variable __fbBatchedBridge' redbox error :)
Seems to be introduced in 17e1ceb543.
cc davidaurelio
Closes https://github.com/facebook/react-native/pull/5689
Reviewed By: svcscm
Differential Revision: D2890634
Pulled By: astreet
fb-gh-sync-id: b96bbe8e26c9ac580b1aa17222d2f59376832560
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