Summary:
An exception is thrown when the native animation code attempts to play an animation on a view that hasn't been created yet. This can happen because views are created in batches. If this particular view didn't make it into a batch yet, the view won't exist and an exception will be thrown when attempting to start an animation on it.
This change eats the exception rather than crashing. The impact is that the app may drop one or more frames of the animation.
**Notes**
I'm not familiar enough with the Android native animation code to know whether or not this is a good fix. My team is using this change in our app because dropping animation frames is better than crashing the app. [This is the code](c612c61544/ReactAndroid/src/main/java/com/facebook/react/uimanager/UIViewOperationQueue.java (L874-L892)) that is creating the views in batches. Hopefully my PR at least provides some insight into the cause of the bug.
This may fix#9887
Closes https://github.com/facebook/react-native/pull/10907
Differential Revision: D4340129
Pulled By: lacker
fbshipit-source-id: 69160d9e71281a96a7445d764b4715a3e54c0357
Summary:
Boost is officially hosted on SourceForge which has ab SSL problem that Gradle complains about and also it is sometimes unavailable.
I switched to using npm hosted (yarnpkg mirrored for performance) boost lib exactly the same as from Source Forge.
Other alternatives considered:
- CDN e.g. mirror.nienbo.com started responding with 4XX code when requested by Gradle
- File sharing like DropBox are not for mass anonymous downloads
- Github is not good for binary files and is throttled for anonymous raw file downloads
- S3 or similar. Requires amazon account for maintenance and does not expose semver API and other nice features that npm has
In the future I'd like to try Yarn as dependency management tool for bridge builds, this could be the first step.
**Test plan (required)**
- Circle (testing with caches cleaned)
- `./gradlew ReactAndroid:packageReactNdkLibsForBuck` (check twice to make sure caches work)
- `REACT_NATIVE_BOOST_PATH=./bridge-dependencies/node_modules/boost-react-native-bundle ./
Closes https://github.com/facebook/react-native/pull/11469
Differential Revision: D4339446
Pulled By: mkonicek
fbshipit-source-id: ccc9196e9b675c16a235a318c4861aaa4e263d6e
Summary:
Android has a text API called breakStrategy for controlling how paragraphs are broken up into lines. For example, some modes support automatically hyphenating words so a word can be split across lines while others do not.
One source of complexity is that Android provides different defaults for `breakStrategy` for `TextView` vs `EditText`. `TextView`'s default is `BREAK_STRATEGY_HIGH_QUALITY` while `EditText`'s default is `BREAK_STRATEGY_SIMPLE`.
In addition to exposing `textBreakStrategy`, this change also fixes a couple of rendering glitches with `Text` and `TextInput`. `TextView` and `EditText` have different default values for `breakStrategy` and `hyphenationFrequency` than `StaticLayout`. Consequently, we were using different parameters for measuring and rendering. Whenever measuring and rendering parameters are inconsistent, it can result in visual glitches such as the text taking up too much space or being clipped.
This change fixes these inconsistencies by setting `breakStrategy` and `hyphenat
Closes https://github.com/facebook/react-native/pull/11007
Differential Revision: D4227495
Pulled By: lacker
fbshipit-source-id: c2d96bd0ddc7bd315fda016fb4f1b5108a2e35cf
Summary:
The reason for this change is to implement `allowFontScaling` on the Android's React Native Text component. Prior to this PR `allowFontScaling` only works for iOS.
The following link contains images of `allowFontScaling` working in Android on small, normal, large, and huge system fonts (from native Android display settings)
http://imgur.com/a/94bF1
The following link is a video of the same thing working on an Android emulator
https://youtu.be/1jTlZhPdj9Y
Here is the sample code snippet driving the video/images
```
render() {
const size = [12, 14, 16, 18];
return (
<View style={{backgroundColor: 'white', flex: 1}}>
<Text>
Default size no allowFontScaling prop (default true)
</Text>
<Text allowFontScaling={true}>
Default size allowFontScaling: true
</Text>
<Text style={{ marginBottom: 10, }} allowFontScaling={false}>
Default size allowFontScaling: false
</Text>
{ size.map(
Closes https://github.com/facebook/react-native/pull/10898
Differential Revision: D4335190
Pulled By: lacker
fbshipit-source-id: 0480809c44983644ff2abfcaf4887569b2bfede5
Summary:
Currently React Native is opinionated in that the easiest approach is to extend ReactActivity. However to more easily allow integrating with existing application, we should allow some of the methods in ReactNativeHost to be public, and this is a very good first step.
* There is no harm in making this public from what I can tell.
* This allows `ReactNativeHost` to be more easily used outside of the `ReactActivity` and `ReactActivityDelegate` ecosystem. (A `ReactFragment` would be a good example)
_No issues found_
**Test plan (required)**
* Run any sample app and verify it still works.
Make sure tests pass on both Travis and Circle CI.
Closes https://github.com/facebook/react-native/pull/11329
Differential Revision: D4287429
Pulled By: AaaChiuuu
fbshipit-source-id: 8cb76f3226aae3737af5f5bd6010d3eea8df9bfe
Summary:
When using React Native on Android on top of a game as an overlay, dialog windows sometimes get created with hardware acceleration disabled. This causes the UI to be unresponsive and anything that uses a TextureView stops working. Added a property for the modal view to make sure hardware acceleration flag is enabled when it's set to true.
**Test plan (required)**
set `hardwareAccelerated` property for Modal to force hardware acceleration on dialog windows on Android. Does nothing on iOS.
Closes https://github.com/facebook/react-native/pull/11421
Differential Revision: D4312912
Pulled By: andreicoman11
fbshipit-source-id: 9db6b2eca361421b92b24234b3501b5de0eecea7
Summary: This changes ReactImageView to pull the transform matrix for rounding from the scale type itself instead of a utility method that forwards to the same thing.
Reviewed By: lambdapioneer
Differential Revision: D4326549
fbshipit-source-id: 82e59e3c20f83beb1d454743e6dbbce8666de8a3
Summary:
The goal of this pull request is to make it easier for contributors to run Android tests locally, specifically the unit tests and integration tests. I added a bunch of checks to the local testing scripts that will warn you if your environment is misconfigured, and tell you how to fix it. I also updated the testing docs, so that the regular "Testing" page should be a decent resource to point people to when you are telling them "hey this pull request needs a test." Just Android, though, I haven't gotten to the iOS parts yet.
I also disabled a couple tests that seemed quite flaky while running on a local machine, and don't seem to be providing much value. In particular, the `TestId` test just hangs on my emulator a lot and has been flaky on CI in the past, so I removed about half of its test cases to make the sample app smaller. The testMetions test appears to be dependent on screen size so I commented it out.
Closes https://github.com/facebook/react-native/pull/11442
Differential Revision: D4323569
Pulled By: bestander
fbshipit-source-id: 9c869f3915d5c7cee438615f37986b07ab251f8c
Summary:
Currently any React Native apps that target API 23 or greater will crash on the first initial debug/dev build due to the overlay permission.
Sadly there isn't a concrete "request permission" baked into the Marshmallow permission system.
However, we can launch the overlay screen without starting the react app and once its turned on start the app.
- https://github.com/facebook/react-native/issues/10454 - targetSdkVersion 23 lead crash / App crash for targeting 23+
- https://github.com/facebook/react-native/pull/10479 - Add the overlay permission information / Larger discussion around targeting API 23+
- Intent to Overlay permission goes directly to the app in question, rather then the general full listing of applications. This allows a developer who is not familiar with the system to easily toggle the overlay without getting confused.
**Test plan (required)**
* Ran UIExplorer App on fresh install with Target 23
```
cd react-native
./gradlew :Examples:UI
Closes https://github.com/facebook/react-native/pull/11316
Differential Revision: D4286351
fbshipit-source-id: 024e97c08c40ee23646dd153794fcde7127b2308
Summary:
By default Android will put extra space above text to allow for upper-case accents or other ascenders. With some fonts, this can make text look slightly misaligned when centered vertically.
We have found that the effect is very noticeable with certain custom fonts on Android. On iOS the font aligns vertically as expected.
Android exposes a property `includeFontPadding` that will remove this extra padding if set to false. This PR exposes that to JS, and adds it to the documentation and UIExplorer.
Closes https://github.com/facebook/react-native/pull/9323
Differential Revision: D4266713
Pulled By: lacker
fbshipit-source-id: f9711254bc26c09b4586a865f0e95ef4bf77cf3f
Summary:
This PR fixes#11096.
I don't know enough the ReactAndroid's source code so I don't know if this is correct but I hope it is.
In a recent commit (d4b8ae7a8a), the `dispatchUpdates` method now returns a boolean to dispatch or not the `onLayout` event. This works well but if the content is unchanged, the line `nativeViewHierarchyOptimizer.handleUpdateLayout(this);` is never called. I don't know if it was intended but it was this which introduces my issue. I called this again even if the content didn't change. This was the behaviour before 0.38 so I guess I didn't break anything.
**Test plan (required)**
I tested my pretty big app with this fix and every screen is ok.
Closes https://github.com/facebook/react-native/pull/11222
Differential Revision: D4252101
Pulled By: astreet
fbshipit-source-id: 551559234631ac37245a854d81ba568f0ddb02dd
Summary:
This change suppresses access checking during reflection which makes reflection faster by decreasing its overhead.
**Test plan (required)**
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11204
Differential Revision: D4250790
Pulled By: astreet
fbshipit-source-id: 0ee2f40dcadccc695980fcae14fafe1050acb52f
Summary:
Suppose that the user is scrolled to the bottom of a ScrollView. Next, the ScrollView's content is edited such that the height of the content changes and the current scroll position is larger than the new height of the content. Consequently, the user sees a blank ScrollView. As soon as the user interacts with the ScrollView, the ScrollView will jump to its max scroll position.
This change improves this scenario by ensuring that the user is never staring at a blank ScrollView when the ScrollView has content in it. It does this by moving the ScrollView to its max scroll position when the scroll position after an edit is larger than the max scroll position of the ScrollView.
Here are some pictures to illustrate how this PR improves the scenario described above:
**Test plan (require
Closes https://github.com/facebook/react-native/pull/11000
Differential Revision: D4250792
Pulled By: astreet
fbshipit-source-id: 940fff6282ad29c796726f68b4519cbdabbfe554
Summary:
ReactAndroid/build.gradle downloads a number of ad-hoc dependencies from the internet such as boost, JSC headers, and folly. Having the build depend on the internet is problematic. For example, if the site hosting the JSC headers was to go down, then CI builds would start failing.
This change introduces the environment variable REACT_NATIVE_DEPENDENCIES which refers to a path. Developers can pre-download all of the ad-hoc dependencies into that path and then the build process will grab the dependencies from that local path rather than trying to download them from the internet. This solution is in the spirit of the existing REACT_NATIVE_BOOST_PATH hook.
**Test plan (required)**
This change is used by my team's app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11195
Differential Revision: D4247080
Pulled By: mkonicek
fbshipit-source-id: 7c4350339c8d509a829e258d8f1bf320ff8eef64
Summary:
Made modification to react-native code that reduces the communication channel overhead to ~50% of prior, in some cases, by caching the class-name of the java-script module/interface.
For me it reduced the run-time of the RCTDeviceEventEmitter.emit function from 1438ms to 715ms, over a period of 8 seconds in my Android app. My project requires many emit calls, as I'm transferring real-time EEG data from a Muse headband to my react-native UI to be graphed, so this optimization was very helpful in my case.
Closes https://github.com/facebook/react-native/pull/11118
Reviewed By: astreet
Differential Revision: D4232794
Pulled By: javache
fbshipit-source-id: 25ca1cfc170a343e71ff8915c3fa7e38884a402b
Summary:
The `FrescoModule` supports providing a custom image pipeline configuration. This module is created by `MainReactPackage` but `MainReactPackage` doesn't expose any way to customize the Fresco configuration. This change adds a parameter to `MainReactPackage`'s constructor so that the `FrescoModule`'s configuration can be customized by the app. A couple of design choices were made in this change:
- `MainReactPackage`'s new constructor parameter is a `MainPackageConfig`. Introducing `MainPackageConfig` enables `MainReactPackage` to nicely support new optional configuration options in the future. Imagine the alternative of each optional configuration being a separate parameter to the `MainReactPackage` constructor.
- `FrescoModule` exposes its default configuration as a builder object through the `getDefaultConfigBuilder` method. This enables app's to start with `FrescoModule`'s default configuration and then modify it.
**Test plan (required)**
Verified that passing a custom config based on React Nati
Closes https://github.com/facebook/react-native/pull/10906
Differential Revision: D4237054
Pulled By: mkonicek
fbshipit-source-id: 8a62a6f0e77ca5f6d35238950094686756262196
Summary:
"com.facebook.react.ReactPackage" is imported twice so fixed it to once.
Closes https://github.com/facebook/react-native/pull/11165
Differential Revision: D4236961
Pulled By: mkonicek
fbshipit-source-id: 84765dd9f8731b978972959f3825bf3c9c0684e3
Summary:
When using text inputs inside a ScrollView with `keyboardShouldPersistTaps=false` (default behavior) tapping another text input dismisses the keyboard instead of keeping it open and focusing the new text input which I think is the better and expected behavior.
See #10628 for more discussion about that. Note that this affects nothing but the behavior with text inputs unlike #10628.
cc satya164 MaxLap ericvicenti
Closes https://github.com/facebook/react-native/pull/10887
Differential Revision: D4178474
Pulled By: ericvicenti
fbshipit-source-id: 0c62ea2fac0017d559d1f8674b0a686a5e1b3d2d
Summary:
This PR removes dependency to Jackson third-party library in Android React Native.
Looking at some older PRs that got merged, it seems like some work had already been done to move away from Jackson.
Anyway, there was only two classes left with a dependency on Jackson. I refactored the code to use android built-in `JsonReader` and `JsonWriter` classes instead.
Prep work was done in https://github.com/facebook/react-native/pull/10516 introducing a few unit tests around serialization, to make sure that refactoring around serialization would not break things.
All references to Jackson in build systems files (BUCK files & build.gradle) have also been removed now that no code depend anymore on this third-party library.
Motivation behind this work is that third-party dependencies in Android React Native can prove to be a pain when trying to integrate React Native components into an already existing large Android application (I know this is not the most common use case for react-native ... yet ;P), that might a
Closes https://github.com/facebook/react-native/pull/10521
Differential Revision: D4226705
Pulled By: mkonicek
fbshipit-source-id: e3a7430a79dd00c871ba3c6a705b0b0c3ec3a701
Summary:
Expose aspectRatio style prop from css-layout to React Native.
This means the following will now work:
<View style={{backgroundColor: 'blue', aspectRatio: 1}}/>
Reviewed By: javache
Differential Revision: D4226472
fbshipit-source-id: c8709a7c0abbf77089a4e867879b42dcd9116f65
Summary:
Downloading from the CDN is much faster than from SourceForge, both on my home WiFi and at the office.
I checked using the `diff` utility that both files are identical.
**Test Plan**
Circle CI build on this PR.
Closes https://github.com/facebook/react-native/pull/11087
Differential Revision: D4226538
fbshipit-source-id: a30ec1d94fe3228342c4a198bf65df7a95e0c005
Summary:
On Android, if there is a small amount of space available around a text input (e.g. landscape orientation on a phone), Android may choose to have the user edit the text inside of a full screen text input mode. This behavior isn't always desirable. For example, if your app offers some UI controls for controlling the formatting of the text, you want the controls to be visible while the user is editing the text. This Android feature conflicts with that desired experience because the UI controls would be hidden while the text is being edited.
The `disableExtractUI` prop enables developers to choose whether or not Android's full screen text input editing mode is enabled. When this prop is true, Android's `IME_FLAG_NO_EXTRACT_UI` flag is passed to the `setImeOptions` method.
**Test plan (required)**
Verified `disableExtractUI` works for both `true` and `false` values in a test app.
My team is also using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10900
Differential Revision: D4226483
Pulled By: mkonicek
fbshipit-source-id: 8f1055f6e612b05bafabe6f07a3705dd8788e3da
Summary:
When native events where handled they were not sent to JS as an optimization but this caused some issues. One of the major one is touches are not handled properly inside a ScrollView with an Animated.event because it doesn't receive scroll events so it can't cancel the touch if the user scrolled.
Closes https://github.com/facebook/react-native/pull/10981
Differential Revision: D4226403
Pulled By: astreet
fbshipit-source-id: 41278d3ed4b684af142d9e273b11b974eb679879
Summary:
Virtual shadow nodes (e.g. text) don't use CSSNodes so we don't need to create them. This shows large savings in CSSNodes allocated, depending on the app.
This could be breaking if:
- You have virtual nodes that still set and get CSS properties. The setters now no-op for virtual nodes (I unfortunately couldn't remove them completely -- see the comment on LayoutShadowNode), but the getters will NPE. If you see these NPE's, you should almost definitely be using your own datastructure instead of a CSSNode as virtual nodes will not participate in the layout process (and the CSSNode is then behaving just as a POJO for you).
I do not anticipate this to be breaking for anyone, but am including breaking in the commit message since this is a change in API contract.
Reviewed By: emilsjolander
Differential Revision: D4220204
fbshipit-source-id: b8dc083fff420eb94180f669dd49389136111ecb
Summary:
When tapping on a link in a WebView with an unknown scheme, the app would crash. For example, if you have the link "something://example/" but your device doesn't have anything to handle the "something" scheme, the app would crash when the user clicks on the link. This change handles the exception to prevent the app from crashing. Instead, the click is a no-op and the WebView doesn't navigate anywhere.
**Test plan (required)**
Verified the app no longer crashes when clicking on unknown schemes in a test app. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10903
Differential Revision: D4226371
Pulled By: mkonicek
fbshipit-source-id: a6d3957806c6063e74fe055b0979cb9d1ce40e51
Summary:
The only callsite of `coalesce` looks like this:
```
newEvent.coalesce(oldEvent);
```
The default `coalesce` implementation returns the event with the most recent timestamp. When the events have the same timestamp then, using the variable names from above, `coalesce` returns `oldEvent`.
This change updates `coalesce`'s implementation to make it explicit that it returns `this` (`newEvent` in the variable names from above) in the case of a tie.
The motivation for this change is related to scroll events. In my team's app, we were seeing scroll events being emitted with the same timestamp and the coalescing logic was causing the oldest scroll event to be chosen. This was causing our JavaScript code to receive stale scroll information and the way the JavaScript code utilized this stale scroll information resulted in the ScrollView settling on the wrong scroll position.
**Test plan (required)**
Verified that scroll events work properly in a ScrollView in a test app. Also, my team's app uses this
Closes https://github.com/facebook/react-native/pull/11080
Differential Revision: D4226152
Pulled By: andreicoman11
fbshipit-source-id: d28a2569225ca95de662f2239a0fa14de0540a7d
Summary:
TextInput rounds padding down with `floor` when measuring. However, it rounds padding up with `ceil` when rendering.
This change makes things consistent by moving TextInput's rendering code to use `floor` as well. It looks like this is the intended behavior because commit bdff10b moved measuring from `ceil` to `floor`. It looks like TextInput's rendering code was just overlooked in that commit.
**Test plan (required)**
Verified TextInput padding works in a test app. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11003
Differential Revision: D4220855
Pulled By: mkonicek
fbshipit-source-id: 95349867ef89c021a8441b383a09052ca0dd569c
Summary:
Added an experimental feature to allow to use only rounded values. See #184. It's not a perfect solution and definitely can be further improved. I'm looking forward to your ideas.
Closes https://github.com/facebook/css-layout/pull/256
Reviewed By: splhack
Differential Revision: D4214168
Pulled By: emilsjolander
fbshipit-source-id: 6293352d479b7b4dad258eb3f9e0afaa11cf7236
Summary: Adds a pool to recycle CSSNodes within UIManager. A follow-up diff will hook this up to a memory pressure listener to drop the pool on memory pressure.
Reviewed By: emilsjolander
Differential Revision: D4189532
fbshipit-source-id: 46583546f71a8c59853e1dd124de31657b3c617b
Summary:
Moves from CSSNodeDEPRECATED to CSSNode. This has shown to be a huge performance win for layout time within FB.
This is BREAKING because CSSNode contains bug fixes that were not migrated to CSSNodeDEPRECATED which may change the way your layout appears. The most common of these by far involves `flex: 1`.
Previously, developers had to put `flex: 1` in many places it didn't belong in order to work around a bug in css-layout. Now `flex: 1` is treated properly and, unfortunately, this means that your layout may no longer look correct. Specifically, you may see that your layout looks collapsed, or children don't render. The fix is to simply remove `flex: 1` from those containers.
Reviewed By: emilsjolander
Differential Revision: D3992787
fbshipit-source-id: 7a3a2a34a8941c0524e6ba3c5379e434d3e03247
Summary: The java enum was recently changed from NOWRAP -> NO_WRAP so the translation from js failed. This fixes that.
Reviewed By: limichaelc
Differential Revision: D4186869
fbshipit-source-id: fe35211a6632d80356d35a01a079279ef4bd7006
Summary:
**Motivation**
Currently to use the `hitSlop` property on Android you must define the object properties `left`, `top`, `right`, and `bottom` or it will crash. iOS allows omitting object properties from the hitSlop.
This change guards and allows the `hitSlop` object properties to be optional like iOS.
**Test plan (required)**
Run the [example](f930270b00/Examples/UIExplorer/js/TouchableExample.js (L318)) and omit a hitslop property and check it does not crash.
Closes https://github.com/facebook/react-native/pull/10952
Differential Revision: D4182815
Pulled By: ericvicenti
fbshipit-source-id: 07d7aca67b5739d5d1939b257476c24dcb10cbb0
Summary: Maintains a single persistent connection to the packager for the inspector. It supports getting the available pages and connecting to them.
Reviewed By: foghina
Differential Revision: D4088690
fbshipit-source-id: 0c445225f5a3de573b199e7868c8693b78f45729
Summary: This is how we compile internally
Reviewed By: emilsjolander
Differential Revision: D4182691
fbshipit-source-id: 314b1a1ead7d299677ce7f71549c986e1b796b3b
Summary: See committed README.md. This is part of the migration to the jni implementation of CSSLayout.
Reviewed By: emilsjolander
Differential Revision: D4177009
fbshipit-source-id: f1860f5d4ffafa1375a9658227e0ac10b7df4845
Summary:
iOS supports an Image onError event. Android was firing the event but it was never reaching JavaScript because Android didn't include this event in `getExportedCustomDirectEventTypeConstants`.
**Test plan (required)**
Verified that the `onError` event now fires in a test app.
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10902
Differential Revision: D4180149
Pulled By: ericvicenti
fbshipit-source-id: 4bf0b9aa7dc221d838d7b6b3e88bb47196dcadef
Summary:
In the wild, our app will occasionally crash with:
```
Fatal Exception: java.lang.NullPointerException
value == null
```
The stack trace brings it back to `okhttp3.Headers$Builder.checkNameAndValue (Headers.java:316)`:
```
if (value == null) throw new NullPointerException("value == null");
```
In the proposed fix, we simply continue the documented functionality of the `extractHeaders` method by returning "null" for invalid data.
Closes https://github.com/facebook/react-native/pull/10861
Differential Revision: D4178624
Pulled By: ericvicenti
fbshipit-source-id: 632e742196339639cb57ea47f9d0efbf04f090be
Summary:
When testing an app on Android using the monkey, the monkey shouldn't be able to open or interact with the dev menu.
**Test plan (required)**
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10901
Differential Revision: D4176167
Pulled By: ericvicenti
fbshipit-source-id: 8eb64715ae7496cdf957ee963777f66ab358546c
Summary: Code refactoring on the dev support class. The idea is to make the code more modular.
Reviewed By: mhorowitz
Differential Revision: D4164676
fbshipit-source-id: 0d29bdaf927cd0e9f399fe6f8e46a16dfa65fb69
Summary: Builds and ships libcsslayout.so with Android builds. This is not used yet, but a follow up diff will shortly move us from CSSNodeDEPRECATED to CSSNode (which uses libcsslayout)
Reviewed By: emilsjolander
Differential Revision: D4168140
fbshipit-source-id: d72bded88df81e4d54df31a08e4b101834770a73
Summary:
This diff makes it so ReactShadowNode holds a CSSNode instead of extending one. This will enable us to pool and re-use CSSNodes and will allow us to keep from breaking the CSSNode api assumption that nodes that have measure functions don't have children (right now, text nodes have measure functions, but they also have raw text children).
BREAKING
This diff makes ReactShadowNode no longer extend CSSNodeDEPRECATED. If you have code that depended on that, e.g. via instanceof checks, that will no longer work as expected. Subclasses that override getChildAt/addChildAt/etc will need to update your method signatures. There should be no runtime behavior changes.
Reviewed By: emilsjolander
Differential Revision: D4153818
fbshipit-source-id: 2836434dd925d8e4651b9bb94b602c235e1e7665
Summary: First step to sharing CSSLayout code between iOS and Android.
Reviewed By: emilsjolander
Differential Revision: D4160286
fbshipit-source-id: 976f5820b19a7011e0a14317c858465f932e1f59
Summary:
This diff attempts to fix a number of Android native animation bugs related to incomplete node invalidation, e.g. https://github.com/facebook/react-native/pull/10657#issuecomment-258297467.
For full correctness, we should mark any node as needing update when it is:
- created
- updated (value nodes)
- attached to new parents
- detached from old parents
- attached to a view (prop nodes)
cc/ janicduplessis
Closes https://github.com/facebook/react-native/pull/10837
Differential Revision: D4166446
fbshipit-source-id: dbf6b9aa34439e286234627791bb7fef647c8396
Summary:
This causes the step to be re-calculated on every update of min, max and step value,
to use the most up to date values for the calculation,
except if step is explicitly set to a non-zero value by the user.
Fixes#10253
**Test plan (required)**
1. Create example app
2. Create a view with a slider that has a `value`, `minimumValue` and `maximumValue` set, but no step value (or step value set to 0).
For example:
```
<Slider
maximumValue={10}
minimumValue={1}
value={4}
/>
```
3. See slider working as expected
Closes https://github.com/facebook/react-native/pull/10343
Differential Revision: D4142646
Pulled By: hramos
fbshipit-source-id: a0df87bbdbbd4b2a291d89f5579f73f517a33dfc
Summary:
This pull request exposes the `setAllowUniversalAccessFromFileURLs` method of Android WebViewSettings as a property. The reason for this is when loading pages with a `file://` baseUrl it's sometimes desirable to allow loading other assets from a file base url. (For example loading an image into a canvas). More information on its use and purpose can be found [in the android docs here](https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowUniversalAccessFromFileURLs%28boolean%29)
Usage example:
``` jsx
return (
<WebView
source={{ html: myhtml, baseUrl: 'file://' }}
allowUniversalAccessFromFileURLs={true}
javaScriptEnabled={true} />
)
```
Closes https://github.com/facebook/react-native/pull/8905
Differential Revision: D4147245
Pulled By: hramos
fbshipit-source-id: 7eaa884b8c0268de52b284954a34acec0fbd4061
Summary:
`flattenOffset` has proven extremely useful, especially when dealing with pan responders and other gesture based animations, but I've also found a number of use cases for the inverse. This diff introduces `extractOffset`, which sets the offset value to the base value, and resets the base value to zero. A common use case would be to extractOffset onGrant and flattenOffset onRelease.
Closes https://github.com/facebook/react-native/pull/10721
Differential Revision: D4145744
fbshipit-source-id: dc2aa31652df0b31450556f611db43548180c7dd
Summary:
This PR updates #6851 from srikanthkh, fixing coding conventions and javadoc, and adding a test plan.
Added testing functions into the WebSocketExample page of the UIExplorer, including a tiny http server to set a cookie on demand. Instructions included in the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/9114
Differential Revision: D4140534
Pulled By: lacker
fbshipit-source-id: e020ad0c6d1d3ea09c0c3564c1795b4e1bc4517d
Summary:
In the JNI portion of CSSLayout, there's a subtle bug where we were caching the jmethodid of the 'measure' of the first object that had measure called on it. However, if that class had overriden measure, then the jmethodid would be specific to that subclass's implementation and would not work for other classes. Conversely, if a regular CSSNode had been called first, then the super method would be called on the subclass instead of the proper overriden method.
Since there's not really a reason to overriden measure anyway (since you can just provide a different measure function), it's safest to just mark it final and explicitly cache the appropriate methodid
Reviewed By: emilsjolander
Differential Revision: D4132428
fbshipit-source-id: 6fb51597d80f1c03681e6611153b52b73b392245
Summary: We don't need to allocate a list for every node since leaf nodes don't have children.
Reviewed By: emilsjolander
Differential Revision: D4130818
fbshipit-source-id: 80d3e98fce9d2daa0676fd1cbed0e81edcf7adb3
Summary: This mimics (some of) the behavior we have on iOS where if you call a JS module method before the JS bundle has started loading, we just queue up those calls and execute them after the bundle has started loading.
Reviewed By: javache
Differential Revision: D4117581
fbshipit-source-id: 58c5a6f87aeeb86083385334d92f2716a0574ba1
Summary:
This diff implements ModulusAnimatedNode on Android, bringing Android up to date with JS and iOS native animation APIs.
Closes https://github.com/facebook/react-native/pull/10681
Differential Revision: D4120162
fbshipit-source-id: 4e58e1b6309c1c7a12ef835547a3f3d321c20714
Summary:
This diff implements NativeAnimation offsets on Android. Running the examples should show no change; however, calling `setOffset()` should offset the final value for any value node by that amount. This brings Android up to date with JS and iOS animation APIs.
Closes https://github.com/facebook/react-native/pull/10680
Differential Revision: D4119609
fbshipit-source-id: 96dccdf25f67c64c6787fd9ac762ec841cefc46a
Summary: This bug was introduced with the bounce-back bug fix. We need to actually set the scroll position to the max scroll position if we've gone over otherwise it can get stuck.
Reviewed By: lexs
Differential Revision: D4118084
fbshipit-source-id: 41a927a40000c526414096c9385f8bd3cbd907f3
Summary:
There was previously a race condition where hasActiveCatalystInstance would return true, but calling a JS module call on it would result in a crash. Now, hasActivtyCatalystInstance will only return true once the instance is actually accepting calls.
I'll follow this up with a more risky diff that gets rid of hasActiveCatalystInstance and just queues JS calls until runJSBundle is called.
Reviewed By: javache
Differential Revision: D4117374
fbshipit-source-id: 60941f68b0906a8213571305c564bfe3d053f51b
Summary:
This is a proposed patch for issue #7192.
Android 4.1-4.4 has support for TLS 1.1 and 1.2 but it is disabled by default. Because of the known security issues and more and more servers switching to TLS 1.2 only, it would be nice for react-native to enable this support.
I demonstrated a demo application which showcases the problem and can be used to test this patch. All sources and documentation for it can be found here:
https://github.com/bringnow/react-native-tls-test
Credits to Alex Gotev (gotev) for the nice implementation.
Closes https://github.com/facebook/react-native/pull/9840
Differential Revision: D4099446
Pulled By: lacker
fbshipit-source-id: 94db320dce6d27f98169e63f834562360c00eef7
Summary:
Followup for #5822, addressing nits.
**Test Plan**
Travis CI (the author of #5822 tested the change).
Closes https://github.com/facebook/react-native/pull/10563
Differential Revision: D4081826
fbshipit-source-id: f3a2e1996bf02f81fecea6e53fe1c522b8c85689
Summary:
**Motivation**
I'm working on a project that uses React Native and needs to add direct synchronous bindings to native stuff through the JavaScriptCore C API. This is because it's performance-sensitive and would benefit from the quickest JS->C path. It does this using cross-platform C++ code that works on both iOS and Android. Most of the infrastructure for getting access to the JSC context is already in React Native actually, just had to add a few more things.
(lexs you mentioned to tag you in this pull request)
**Test plan**
Modify the JavaScriptCore context through the `JSContextRef` returned (eg. add an object at global scope) and verify that it exists in JavaScript.
Closes https://github.com/facebook/react-native/pull/10399
Differential Revision: D4080945
Pulled By: lexs
fbshipit-source-id: 6659b7a01e09fd84475adde183c1d3aca2d4cf09
Summary:
This PR adds a few unit tests to two devsupport classes, repectively
- JSDebuggerWebSocketClient
and
- JSPackagerWebSocketClient
Unit tests do not cover all methods / branches of the code. I solely focused on testing things having to do with JSON serialization as I am considering some quick refactoring to get rid of Jackson. Just prepping safety net with these few tests before starting.
Closes https://github.com/facebook/react-native/pull/10516
Differential Revision: D4067433
Pulled By: bestander
fbshipit-source-id: 97dc356c5eca5965914be074a7175cb48f038c4c
Summary: This is a simple hook to allow native side to fetch any file under the js root folder via packager. Historically, only the `main.jsbundle` is fetched via the packager. This then allows fetching local file like a json file that lives under the same root js folder
Reviewed By: yungsters
Differential Revision: D4037730
fbshipit-source-id: a2d6eb5e30d148fee573d413fc4036d0189f4938
Summary:
In most .gradle files, lines are indented with 4 spaces, but in some places they are indented with 2 spaces. This PR fixes them and enforce it by adding .editorconfig settings.
Closes https://github.com/facebook/react-native/pull/10267
Differential Revision: D4048335
Pulled By: lacker
fbshipit-source-id: df2f2556380f56672cf85690eb1c80e640a6aedf
Summary:
Implemented 2 TODOs from ReactART for Android:
- TODO(7255985): Use TextureView and pass Surface from the view to draw on it asynchronously instead of passing the bitmap (which is inefficient especially in terms of memory usage)
- TODO(6352067): Support dashes in ARTShape
We use ReactNativeART in our Android project.
1. Our app crashes sometimes on large screen smartphones with OutOfMemoryError. Crashes happen in ARTSurfaceShadowNode where TODO(7255985) was suggested in a comment in order to use memory more efficiently.
2. We needed dashes for drawing on ARTSurface.
**Test plan (required)**
I attach a screenshot of our app which shows dashed-lines and two ARTSurfaces on top of each other rendering exactly the same as in the pervious implementation of ARTSurface.
Closes https://github.com/facebook/react-native/pull/9486
Differential Revision: D4021303
Pulled By: foghina
fbshipit-source-id: 880175e841e3c598013982a7748b6fc691c7e8d6
Summary:
JS API very similar to web workers and node's child process.
Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.
I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary:
For some reason the transitive dependency isn't picked up in OSS, so make it hard.
bestander
Closes https://github.com/facebook/react-native/pull/10397
Differential Revision: D4024350
Pulled By: bestander
fbshipit-source-id: 32182857dcc88744ebf6ce0e5cf8eaee390bf067
Summary:
We're seeing a lot of crashes from `PermissionsModule` not being able to access the current activity, mentioned in #10009 and here: https://github.com/facebook/react-native/issues/9310#issuecomment-245657347
As far as I can tell, there is no way to ensure the Activity exists since the `ReactContext` holds a `WeakReference` to the current Activity and it appears that the lifecycle calls are happening in the right order (so not the same as #9310).
This will at least allow people to catch the error in JS and update the UI or try again as opposed to crashing the app.
I'm working on some bigger changes in #10221 but this is a smaller change and important to get fixed I think.
Closes https://github.com/facebook/react-native/pull/10351
Differential Revision: D4010242
fbshipit-source-id: 7a76973bb2b3e45817d4283917740c89a10ec0b0
Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary: Instead of sending a list of modules over to JS on startup (and actually blocking script execution) instead provide a proxy object that constructs each of these lazily.
Reviewed By: lexs
Differential Revision: D3936979
fbshipit-source-id: 71bde822f01eb17a29f56c5e60e95e98e207d74d
Summary:
This allows the React JS code that's running from a Service (ie GcmListenerService) to check permissions (ie check for VIBRATE permissions before delivering notifications)
**Test plan (required)**
I've run this code from a GcmListenerService subclass, and it works correctly.
Closes https://github.com/facebook/react-native/pull/10229
Differential Revision: D3980853
fbshipit-source-id: 026b1f0c953d7093b5af2bec0b4a93ebd228f62e
Summary: This way `UIImplementation` can hold on to it and use it outside of calls from the `UIManagerModule`.
Reviewed By: lexs
Differential Revision: D3899774
fbshipit-source-id: 01e4956c4540bcdf30774a3f40a625e934714ee9
Summary:
Gradle unit tests started failing, this PR fixes mockito to be one specific version instead of loose 1.+
**Explain the **motivation** for making this change. What existing problem does the pull request solve?**
Circle CI started failing without any specific reason https://circleci.com/gh/facebook/react-native/tree/master, looks like a dependency error.
Alas it is, I can reproduce the error on master with clean caches.
**Test plan (required)**
After the fix:
```
bestander-pro:react-native bestander$ ./gradlew :ReactAndroid:testDebugUnitTest
Incremental java compilation is an incubating feature.
:ReactAndroid:preBuild UP-TO-DATE
:ReactAndroid:preDebugBuild UP-TO-DATE
:ReactAndroid:checkDebugManifest
:ReactAndroid:preDebugAndroidTestBuild UP-TO-DATE
:ReactAndroid:preDebugUnitTestBuild UP-TO-DATE
:ReactAndroid:preReleaseBuild UP-TO-DATE
:ReactAndroid:preReleaseUnitTestBuild UP-TO-DATE
:ReactAndroid:prepareComAndroidSupportAppcompatV72301Library UP-TO-DATE
:ReactAndroid:prepareComAndro
Closes https://github.com/facebook/react-native/pull/10239
Differential Revision: D3968396
Pulled By: matryoshcow
fbshipit-source-id: 63374261303fb98dc252898dfd5d3b3346597e4f
Summary:
When using webview on android and trying to link to an html file located on device (using `file://`), the application would crash with an error specifying that nothing handles the fired intent. This is due to [`33a1f28`](33a1f28654) which attempts to intercept all non `http(s)` links.
This is a simple fix so hopefully it can make it into the next stable release.
Closes https://github.com/facebook/react-native/pull/9668
Differential Revision: D3956485
fbshipit-source-id: 5a752abc21802a44e3a26e88669ccb6852076992
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
The hack for the status bar height is not necessary any longer, so we can remove
all code related to it
Reviewed By: lexs
Differential Revision: D3943770
fbshipit-source-id: 2d70f4ea10dd76ea6e6a73bb6edccae388bde1c0
Summary:
On tablets, using Display.getRotation() returned ROTATION_0 or ROTATION_180 when it was in landscape, not portrait as it does on phones. This resulted in the Modal being sized incorrectly on tablets. Using size and comparing width and height is the only way I can think of to figure out the device orientation and give the modal the correct size. With this change, all issues listed in #7708 should be resolved.
**Test plan**
Modal should correctly fill screen on Android phone and tablet in both portrait and landscape.
Closes https://github.com/facebook/react-native/pull/10159
Differential Revision: D3950369
Pulled By: andreicoman11
fbshipit-source-id: 9488c4302a76cc48e4f8a4026eb5770d40b6e3d2
Summary:
I noticed that the example doesn't match the definition below.
cc bestander
Closes https://github.com/facebook/react-native/pull/10175
Differential Revision: D3943967
Pulled By: bestander
fbshipit-source-id: 6941d4d663e1fd42f8723cd722eb8a5712a63dc8
Summary: Provide a base `HeadlessJsTaskService` class that can be extended to run JS in headless mode in response to some event. Added `HeadlessJsTaskEventListener` for modules that are interested in background lifecycle events, and `HeadlessJsTaskContext` that basically extends `ReactContext` without touching it. The react instance is shared with the rest of the app (e.g. activities) through the `ReactNativeHost`.
Reviewed By: astreet
Differential Revision: D3225753
fbshipit-source-id: 2c5e7679636f31e0e7842d8a67aeb95baf47c563
Summary:
This changes modal behavior to resize when the keyboard appears/disappears.
Previously, the modal would not react in any way, or it would pan above to bring the
TextInput into view. Resizing is the correct behavior for android.
This is not trivial, as in, setting the flag, because of the combination of
react native laying out all views and the system reacting to the keyboard
appearance in a weird way. Namely:
- if `windowTranslucentStatus` is not set, the system will just call
`onSizeChanged` on the dialog's content view, and everything works nicely
- with `windowTranslucentStatus` set, the system will consider the dialog as a
full screen view that doesn't resize. In order for it to resize, the base
view of the layout needs to have
`setFitsSystemWindows(true)` called on it. This is needed, so that the system
can call layout on that base view with the new value of `paddingBottom` that
coincides with the height of the keyboard. Neat.
We fix this by wrapping our existing content view (mHostView) in a simple
FrameLayout that has `setFitsSystemWindows` set. That way, `mHostView` will have
`onSizeChanged` called on itself with the correct new size of the dialog.
This has the fortunate consequence of our layout now also getting `paddingTop` as the size of the
status bar, which means that we can remove the JS `top` hack in Modal, which
was necessary for no view getting drawn under the status bar.
This behavior is set as default, since that is the default correct Android behavior.
Reviewed By: astreet
Differential Revision: D3913784
fbshipit-source-id: 4378ada21f466dc7ac6e357abeca10b88009ca3f
Summary:
After D3876927 this test started failing on CI.
Locally we can't reproduce it, and it will take some time to understand what this test is intended for so that we could remove the variable part.
More investigation will follow, t13583009
Reviewed By: emilsjolander
Differential Revision: D3930334
fbshipit-source-id: 279f67eb5a77b5d4250afd48c8b94c828da6925c
Summary:
`ReactSwipeRefreshLayout` extends `SwipeRefreshLayout` which does not play nice with Android's touch handling system.
There are two problems:
1. `SwipeRefreshLayout` overrides and swallows `requestDisallowInterceptTouchEvent`, which means that Views underneath the `SwipeRefreshLayout` will not interact correctly with parent Views of
`SwipeRefreshLayout`. We've seen this in practice by H-ScrollViews having their touches intercepted by an enclosing ViewPager. This is fixed by passing `requestDisallowInterceptTouchEvent` up to the parents of `SwipeRefreshLayout`.
2. `SwipeRefreshLayout` overrides `onInterceptTouchEvent` and never calls `super.onInterceptTouchEvent`, therefore ignoring the value of `disallowIntercept`. That means that it will intercept some touches when it
shouldn't. One such case is again the H-ScrollView, which should receive all horizontal scrolls and stop `SwipeRefreshLayout` from intercepting any touch events after scrolling. Currently, after the H-ScrollView starts scrolling, it is still possible to get the `SwipeRefreshLayout` to detect and emit refresh events. This is fixed by checking and blocking on horizontal scrolls.
Reviewed By: foghina
Differential Revision: D3929893
fbshipit-source-id: e6f8050fb554e53318a7ca564c49c20cb5137df9
Summary:
Combining 2 animated values via addition, multiplication, and modulo are already supported, and this adds another one: division.
There are some cases where an animated value needs to invert (1 / x) another animated value for calculation. An example is inverting a scale (2x --> 0.5x), e.g.:
```
const a = Animated.Value(1);
const b = Animated.divide(1, a);
Animated.spring(a, {
toValue: 2,
}).start();
```
`b` will then follow `a`'s spring animation and produce the value of `1 / a`.
The basic usage is like this:
```
<Animated.View style={{transform: [{scale: a}]}}>
<Animated.Image style={{transform: [{scale: b}]}} />
<Animated.View>
```
In this example, the inner image won't get stretched at all because the parent's scaling gets cancelled out.
Also added this to native animated implementation.
Reviewed By: foghina, mmmulani
Differential Revision: D3922891
fbshipit-source-id: 32508956c4b65b2deb7574d50a10c85b4809b961
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
The styles that get applied to the Dialogs that are created in RN are set in
`themes.xml`, so I'm moving `windowTranslucentStatus` there as well so that we
have all of them collocated.
Reviewed By: astreet
Differential Revision: D3913402
fbshipit-source-id: 8f23e84fb017c8810634ffe8279171061292b351
Summary: Utilizes the build time annotation processor ReactModuleSpecProcessor that creates ReactModuleInfos for modules annotated with ReactModule and listed in the ReactModuleList annotation of LazyReactPackages. This way we don't have to instantiate the native modules to get the name, canOverrideExistingModule, and supportsWebWorkers values of the native modules. In the NativeModuleRegistry, we either store these ReactModuleInfos inside of a ModuleHolder or if we can't get the ReactModuleInfo for a specific module we instantiate that module to get the values (as we previously did) to store in a LegacyModuleInfo.
Reviewed By: astreet
Differential Revision: D3796561
fbshipit-source-id: f8fb9b4993f59b51ce595eb2f2c3425129b28ce5
Summary: Create separate buck library for image events so you can depend on that without depending on all of fresco
Reviewed By: brosenfeld
Differential Revision: D3907894
fbshipit-source-id: dca7a00d38b8b8bb5bab05b6883f6933fff3fa76
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10057
Differential Revision: D3913431
Pulled By: bestander
fbshipit-source-id: c761640839ce0e85196ffd7fc1a4e1c615078b06
Summary:
The dialog intercepts all key events, we need to redirect some of them to the
activity so that it can display the dev menu.
Reviewed By: foghina
Differential Revision: D3894503
fbshipit-source-id: fb62346a4da783f28a73c5a9e20566a451177629
Summary:
In some cases, the size of the content view changes before we add views to the
Modal. That means that the size of that view will not be set through the
`onSizeChanged` method. This can result in some apps apparently freezing,
since the dialog is created, but there are no actual views in it.
For that reason, we still need the ModalHostShadowNode to set the size of the
initial view, so that by the time the view gets added it already has the correct
size.
There's a new helper class so that we can reuse the modal size computation.
Reviewed By: foghina
Differential Revision: D3892795
fbshipit-source-id: 6a32bd7680a74d9912a21bfebb4ebd7a3c3c3e38
Summary:
Since API 18, Android locations have had the `isFromMockProvider()` function, to verify the validity of a provided location. This was one of many methods one could verify location data, but as of Marshmallow, the other ways of detecting if "Mock Locations" is on in developer settings has been deprecated or defunct.
This means some devices can only detect location mocking by exposing the method on the location object.
This change provides that exposure.
Closes https://github.com/facebook/react-native/pull/9390
Differential Revision: D3858205
Pulled By: bestander
fbshipit-source-id: 3bae429cc0596ea01926c5be204f4403e4a2414f
Summary: Some OEMs have changed out the default scroller implementation in their ScrollView. We now check for that case and handle it gracefully instead of crashing.
Reviewed By: foghina
Differential Revision: D3876492
fbshipit-source-id: 4d03b88c4972e939c8352eeb9f30275e3ecf76e2
Summary:
This adds support for `Animated.event` driven natively. This is WIP and would like feedback on how this is implemented.
At the moment, it works by providing a mapping between a view tag, an event name, an event path and an animated value when a view has a prop with a `AnimatedEvent` object. Then we can hook into `EventDispatcher`, check for events that target our view + event name and update the animated value using the event path.
For now it works with the onScroll event but it should be generic enough to work with anything.
Closes https://github.com/facebook/react-native/pull/9253
Differential Revision: D3759844
Pulled By: foghina
fbshipit-source-id: 86989c705847955bd65e6cf5a7d572ec7ccd3eb4
Summary:
The issue here is that on some devices (ie. Nexus 5X), under certain
circumstances, the text gets trimmed. A simple example is P56651885, where the
text is at the end of the line and some padding is set. Digging further with
P56659346, I found that only the paddings that have integer pixel values work
correctly: these are the values P56656483, and this is the screenshot of that
test: {F63510378}.
It turns out that when we set the padding directly on the TextView, we have to
convert from float to int, and use `ceil` in the process. We lose some precision
here, since the csslayout will use the float values to compute the layout of the
views. The ideal solution would be to just set the float values on the TextView,
but since we can't do that, we should avoid using `ceil` instead of `floor`
since it can have bad side-effects in some scenarios.
Going way back to D1881202 and D1710471, we started using `ceil` because that
is how android handles non-integer
density ratios: "This figure is the factor by which you should multiply the dp
units on order to get the actual pixel count for the current screen. (Then add
0.5f to round the figure up to the nearest whole number, when converting to an
integer.)", see https://developer.android.com/guide/practices/screens_support.html.
Reviewed By: emilsjolander
Differential Revision: D3876310
fbshipit-source-id: 701c05a8b1a045d4e06fc89ffe79162c1eecb62c
Summary:
With our previous fix to resize the Modal on orientation change, we broke the
computation of its size. The existing computation in `ModalHostShadowNode` was
in fact correct, and we were overriding it from `onSizeChanged`. By computing the
size of the Modal in `onSizeChanged` directly (and correctly), we fix this, and
simplify code by removing the `ModalHostShadowNode`.
Reviewed By: foghina
Differential Revision: D3863054
fbshipit-source-id: aaf4a8881798df4d2ab1dab882a9d9dfdc0a9342
Summary:
The original method getNativeProps in ViewManagerPropertyUpdater.java create more HashMaps and putAll method need to re-hash the key again to avoid conflicts. This pull request pass the map as params to avoid the problem and update ReactPropertyProcessor.java to adapt the change.
Closes https://github.com/facebook/react-native/pull/9916
Differential Revision: D3873152
fbshipit-source-id: 089840e5272265662cdbf58d88580f9203153b69
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
Pulled By: fred2028
fbshipit-source-id: d346068734c5b987518794ab23e13914ed13b5c4
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
fbshipit-source-id: cab044cfdbe2ccb98e1ecd3e02ed3ceaa253eb78
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 3c365f9e6ef612fd9d9caaaa8c650e9702176e77
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 6077b0bcb68fe5ddd4aa22926acab40ff4d83949
Summary: This is to be able to depend on ReactClippingViewGroup from BaseViewManager. Devs using ReactClippingViewGroup may need to update their imports when updating past this commit.
Reviewed By: lexs
Differential Revision: D3835328
fbshipit-source-id: 290c08b130d837e553b68a90377bd9a30b7ec6dc
Summary:
This automatically changes the size of the modal by listening to dialog size changes and propagating
those changes through UIManager.
In detail: I've looked into three ways of doing this:
1. Send `onSizeChanged` events/info from the View to the CSSNode directly. This is kinda hacky because you would need to hold a reference to the CSSNode somewhere, either in the View or in the ViewManager. But then you'll have to take care of the lifecycle of the CSSNode, so that you don't update it after it has been dismissed. Not great.
2. The version we went for, is to just update the size of the corresponding CSSNode in the same way we do it for root nodes: we inform the UIManager that the size of the root node has changed, and it will propagate that change, triggering a `dispatchViewUpdates` if none is underway, so that the layout is updated.
3. The other solution we thought of is to treat the Modal as a root view. This would mean rendering an application with the tag of the Modal as the root of the application. That tag would be received by calling some method into UIManager and ReactModalHostManager to create a new RootView, create a Dialog and plop the root view in it. The idea was to maintain the JS API that we now have, but make the implementation more correct (ie. since both RootView and the Modal must deal with touch handling), and could have other benefits (ie. no hacks necessary for making the inspector work on top of modals). However, the change is not trivial and I don't know just how much code would have to be changed to make this work correctly. We might revisit this at a later stage, after we've done more work on having several root views at the same time in the app.
Reviewed By: foghina
Differential Revision: D3841379
fbshipit-source-id: f5e363e27041b785cf44eb59da04bc789306ddb9
Summary:
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3841658
fbshipit-source-id: 7257df4f1b2ce037554c7a7a5ca8f547a2056939
Summary:
This is just D3835023 again since it got reverted, plus the fix from D3841918 baked in. Here's the old summary:
We never actually closed the websocket connection. Furthermore, upon calling `closeQuietly()`, `onClose()` is called, which does `reconnect()`. This results in ReactInstanceManager leaking after calling `destroy()` and nullifying all references to it.
To fix this I made sure `closeQuietly()` actually closes the connection for good, and made sure we actually call it when destroying an instance.
Reviewed By: AaaChiuuu
Differential Revision: D3849353
fbshipit-source-id: e1ce5e2d5840bfbd42a13043c3cc8c617e9fa64a
Summary:
Here's a little background. Resizing is inferior to scaling. See http://frescolib.org/docs/resizing-rotating.html#_
Currently, React Native has a heuristic to use resize when the image is likely to be from the device's camera. However, there may be other cases where a developer wants to use resize. For example, when the developer knows they'll be downloading a large image from a service but the image will be rendered at a small size on the device.
This change adds a `resizeMethod` prop to the `Image` component so developers can choose how Fresco resizes the image. The options are 'auto', 'resize', or 'scale'. When 'auto' is specified, a heuristic is used to choose between 'resize' and 'scale'. The default value is 'auto'.
**Test plan (required)**
In a small test app, verified that the `resizeMethod` prop properly influences the mechanism that is used to resize the image (e.g. resize or scale).
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9652
Differential Revision: D3841322
Pulled By: foghina
fbshipit-source-id: 6c78b5c75ea73053aa10386afd4cbff45f5b8ffe
Summary:
Ugh. We never actually closed the websocket connection. Furthermore, upon calling `closeQuietly()`, `onClose()` is called, which does `reconnect()`. Beautiful. This results in `ReactInstanceManager` leaking after calling `destroy()` and nullifying all references to it.
To fix this I made sure `closeQuietly()` actually closes the connection for good, **and** made sure we actually call it when destroying an instance.
Reviewed By: AaaChiuuu
Differential Revision: D3835023
fbshipit-source-id: 31811805dd97b725ea5887cffed9bed49addda83
Summary: Get rid of the old behaviour of JSON encoding in `nativeRequireModuleConfig` and consistently use the same names for function types "async/promise/sync"
Reviewed By: lexs
Differential Revision: D3819348
fbshipit-source-id: fc798a5abcaf6a3ef9d95bd8654afa7825c83967
Summary:
Currently, `<Text>` and `<TextInput>` components on Android do not support borders.
This change adds support for the borderRadius, borderColor, and
borderWidth props on the `<Text>` and `<TextInput>` components on Android.
ReactViewGroup already implements this functionality so
we copied its implementation over into the ReactTextView
and ReactEditText classes.
**Test plan (required)**
Verified that the various border props work on Text and TextInput components in a test app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9658
Differential Revision: D3819993
Pulled By: lexs
fbshipit-source-id: 183b0aa95369dd781f03b5a1f0f409ab47284e39
Summary: It's called `timestamp` on iOS, making it consistent.
Reviewed By: foghina
Differential Revision: D3820937
fbshipit-source-id: 2805f1fc10d6445d8b31676e0e3dca348510ffe7
Summary: Casting to long too early here and dropping some precision, resulting in skipped (not dropped) frames.
Reviewed By: sahrens
Differential Revision: D3819153
fbshipit-source-id: 83676cf4c9129638348890c74d563db121049e4a
Summary:
Add native support on iOS and Android for `Animated.diffClamp` that was added in #9419.
**Test plan**
Tested that it works properly using the native animations UIExplorer example.
Closes https://github.com/facebook/react-native/pull/9691
Differential Revision: D3813440
fbshipit-source-id: 48a3ecddf3708fa44b408954d3d8133ec8537f21
Summary:
Adds support for the `extrapolate` parameter on the native interpolation node. This is pretty much a 1 to 1 port of the JS implementation.
**Test plan**
Tested by adding the `extrapolate` parameter in the native animated UIExplorer example.
Closes https://github.com/facebook/react-native/pull/9366
Differential Revision: D3824154
fbshipit-source-id: 2ef593af827a8bd3d7b8ab2d53abbdc9516c6022
Summary:
ReactRootView currently intercepts and swallows all
`requestDisallowInterceptTouchEvent` calls, which made sense when the
ReactNativeView was the root of all views. In the context of react native views
embedded in other views though, we want to propagate the call to all parents
views, but not set it on the ReactRootView itself (because we still need the
`onInterceptTouchEvent` calls to dispatch the touch events to JS).
Reviewed By: foghina
Differential Revision: D3819255
fbshipit-source-id: 21f2dd173c76e98342193de384292fef2b407250
Summary:
This diff changes the textinput component to only scroll (and interrupt parent
views from scrolling), when it is possible for the text inside the component to
be scrolled. Before (D3735237), we would intercept all touch events on the
textinput if it's focused. But this makes it: a.) impossible to scroll a scrollview from within
a textinput that cannot be scrolled; b.) different from iOS behavior.
What the component now does is intercept move touches, and check if it can
scroll in any direction. If it does, it will intercept the touches and stop the parent
component from scrolling; otherwise, it will give the control back to the parent
component.
Note: this might change in the future to also detect the direction of the scroll, and
only block the scroll if the component can scroll in that direction. This is however not
trivial, since the scroll needs to be above some threshold of pixels. Blocking the
parent view from scrolling until that threshold is passed might cause incorrect behavior
in the parent component.
Reviewed By: astreet
Differential Revision: D3764267
fbshipit-source-id: 47e7b5e03855b3c85789e04fc31a8317afbafa84
Summary:
This adds the `didUpdateDimensions` event that already exists on iOS, and
updates the internal native dimensions data that needs repopulation after
orientation change.
Reviewed By: foghina
Differential Revision: D3819364
fbshipit-source-id: fc2b3b4d1991d101e5de4439ccef2189bc65fd58
Summary:
Landing D3528215 again, now that D3593884 has landed and makes that easier.
Copy-paste summary from previous diff:
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.
Reviewed By: foghina
Differential Revision: D3819761
fbshipit-source-id: fd2d85748ae6a9cde6af715aabb620f340c2220c
Summary:
Similar to iOS, send device orientation changes events. This does not have the
`getCurrentOrientation` method, because it's not used. If necessary, we'll
add it separately.
This also adds a simple example for testing.
We listen to orientation changes in `onGlobalLayout`, and check if the rotation of the device has changed. If it has, we emit the event.
But:
- `onGlobalLayout` (and `onConfigurationChanged` - which is the method usually used for checking for device orientation changes) is *not* called when the device goes from landscape
to reverse landscape (same with portrait), as that is not a relayout / configuration change. We could detect if this happens with the help of an `OrientationEventListener`. However, this listener notifies you if the degree
of the phone changes by a single degree, which means that you need to know by how many degrees the phone needs to change in order for the orientation to change. I haven't looked into how accurate this could be, but I suspect that in practice it would cause a lot of bugs. A simple `abgs` and google search reveals that everybody uses a different margin for detecting a rotation change (from 30 to 45 degrees), so I suspect that this won't work
as expected in practice. Therefore, we're not using this here, and we're sticking to what android provides via `onConfigurationChanged`. If we find that we have issues because users need to know when the user goes
from landscape to reverse landscape, then we'll have to revisit this.
Reviewed By: foghina
Differential Revision: D3797521
fbshipit-source-id: 62508efd342a9a4b41b42b6138c73553cfdefebc
Summary:
This fixes some inaccuracies in our reporting of textinput's contentsize.
First, we were not using the correct padding info. Then, we are converting the
contentSize width and height to ints right before sending
them over to JS. This adds some inaccuracy with the textinput behaviour,
especially in the case of auto expending text inputs, since those same sizes are
then sent right back.
Reviewed By: astreet
Differential Revision: D3806008
fbshipit-source-id: 7e32f91fde50099fd8a122833fd0042683e68df1
Summary:
Android PR for TextInput selection, based on the iOS implementation in #8958.
** Test plan **
Tested using the text selection example in UIExplorer.
Closes https://github.com/facebook/react-native/pull/8962
Differential Revision: D3819285
Pulled By: andreicoman11
fbshipit-source-id: 9a2408af2a8b694258c88ab5c46322830c71452a
Summary:
There are a couple of buggy behaviors in the current implementation of the `ellipsizeMode` prop on Android:
- Setting the `numberOfLines` prop stomps on whatever value you provided for `ellipsizeMode` earlier.
- The value you've provided for `ellipsizeMode` is used even if you've configured your view to have an unlimited size (i.e. `numberOfLines` is 0 or unspecified).
This change fixes these issues which makes Android's `ellipsizeMode` prop more consistent with iOS's. Additionally, it renames LineBreakMode to EllipsizeMode in a couple of places.
**Test plan (required)**
Verified that the `numberOfLines` and `ellipsizeMode` props work correctly in an Android test app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9594
Differential Revision: D3810166
Pulled By: foghina
fbshipit-source-id: 229c9bfc3ef10670a1090311ea9d095cb2c1121a
Summary:
This is similar to the iOS feature that was implemented by 84f68c338a.
**Test plan (required)**
Verified that the image dimensions are included in the `onLoad` callback in a test app. Also, this change is used in my team's app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9608
Differential Revision: D3797659
Pulled By: foghina
fbshipit-source-id: ea83a907bf6b0b61d9bc1e90fc7c64b7132db81f
Summary:
Fresco should only be initialized once. Re-initializing causes a few problems (https://github.com/facebook/react-native/issues/8677) and we don't need to do it.
If a Fresco configuration needs to change, you can just restart the application or add delegates for parts that can change and manually update them instead.
Reviewed By: astreet
Differential Revision: D3790908
fbshipit-source-id: 9df4c3be15ca49433120abd7ba1a4f5ae2a3f1c1
Summary:
When an absolutely positioned node appeared inside an overflow:hidden
parent, we were limiting its height. This is inconsistent with how
layout behaves on the web.
Closes https://github.com/facebook/css-layout/pull/218
Reviewed By: lucasr
Differential Revision: D3797285
Pulled By: emilsjolander
fbshipit-source-id: 98f98e77aa26edce86b9882c1cac284799b69a27
Summary:
One of the impacts of this bug is that Java is firing timer
completion events into JavaScript for timers that should have
been deleted. JavaScript filters these out so it doesn't impact
the app developer. However, Java is completing more timers
than necessary.
When cleaning up a timer, we were accidentally deleting the
whole set of timers for that context. Instead, we should
just delete that timer from its context.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9361
Differential Revision: D3797573
fbshipit-source-id: c30ed600af741601f2babdfc61da9aac549cbadb
Summary: Add a static `Image.queryCache` function that can query multiple URLs at once. The result is a map where each URL that is in cache is mapped to the cache type (memory/disk). URLs that are not cached do not appear in the result.
Reviewed By: lexs
Differential Revision: D3791333
fbshipit-source-id: b183015d97423f0c095bf891f035dac2e23d8d11
Summary: I noticed we're doing too much manual work here, when Fresco has a nice handy shortcut for clearing all caches.
Reviewed By: kirwan
Differential Revision: D3791356
fbshipit-source-id: 4a55d0280e9483267741ae75383b50ca0b74c5c6
Summary:
`mRCTEventEmitter` is used by 2 different threads. It's assigned on the UI thread and it's accessed on the JavaScript thread. Currently, it can be the case that the UI thread assigns `mRCTEventEmitter` and later the JS thread accesses it but still sees null.
This change fixes the issue by marking the `mRCTEventEmitter` variable as `volatile` to ensure that both threads see the same value for `mRCTEventEmitter`.
**Test plan (required)**
This change is currently used in my team's app. We're no longer seeing a crash in `EventDispatcher`.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9655
Differential Revision: D3790888
Pulled By: andreicoman11
fbshipit-source-id: 68cdbc74faffb36dc2bca8ad3d4a78929badbe9c
Summary: Added support for WebViews to take in an onContentSizeChange prop, which will return a native event that contains the width and height of the html content in the WebView. Also moved the ContentSizeChangeEvent from the recyclerview dir to the uimanager/events dir
Reviewed By: andreicoman11
Differential Revision: D3775399
fbshipit-source-id: 19a0579f8345e5853cc7311b80f1f1393c77ab58
Summary: added API to in UIManager to find the rootTag/View of any reactTag based on its layout (shadow views) hierarchy (not to be used by JS)
Reviewed By: javache
Differential Revision: D3750410
fbshipit-source-id: 68611e39930d53ece478f25245ddc7f7838daaa6
Summary:
Running the command `./gradlew clean` resulted in the following error:
```
./node_modules/react-native/ReactAndroid/src/main/jni//xreact/jni/Android.mk:42: *** Android NDK: Aborting. . Stop.
Android NDK: ./node_modules/react-native/ReactAndroid/src/main/jni//xreact/jni/Android.mk: Cannot find module with tag 'cxxreact' in import path
Android NDK: Are you sure your NDK_MODULE_PATH variable is properly defined ?
Android NDK: The following directories were searched:
```
The problem was that `REACT_COMMON_DIR` wasn't defined.
**Test plan (required)**
Running `./gradlew clean` now works.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9607
Differential Revision: D3780364
fbshipit-source-id: 2b45d538413f7ee2cf0b36a1fa33287f0b1bf23f
Summary:
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3751097
fbshipit-source-id: 6c5a8d01a6dca4ff6eef9c3aadd1b550054432d2
Summary:
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3751097
fbshipit-source-id: c3574a1080efec26436a5c61afbff89afa8679e7
Summary: Runtime annotation processing uses reflection which is slow. We'll use build time annotation processing instead and create at build time static ModuleInfo classes which have "name", "canOverrideExistingModule", "supportsWebWorkers", "needsEagerInit".
Reviewed By: lexs
Differential Revision: D3752243
fbshipit-source-id: 3518c6f38087d8799a61410864007041389c0e15
Summary: Add support for `useNativeDriver: true` to `Animated.decay`. Add example in Native Animated Example UIExplorer app.
Reviewed By: ritzau
Differential Revision: D3690127
fbshipit-source-id: eaa5e61293ed174191cec72255ea2677dbaa1757
Summary: Border colors broke with recent change to default values in csslayout Spacing. This is a quick fix until we move react-native borders away from using Spacing.java which is a hack in the first place.
Reviewed By: lexs
Differential Revision: D3735435
fbshipit-source-id: 747c85798cb02e1a5139de038eb26b64ac4c5bf3
Summary: Sometimes the main component name is not known at activity construction time and depends on e.g. reading shared preferences. To support this use case, make `(Fragment)ReactActivity#getMainComponentName()` nullable and return `null` by default. In this case, the app will not be loaded in `onCreate` by default and the user has to call `loadApp` manually once the component name is known.
Reviewed By: andreicoman11
Differential Revision: D3722517
fbshipit-source-id: 062eed158798606e4160f1c142b23fd98ca618c8
Summary:
The Android lifecycle is weird: turns out `onActivityResult` is called before `onResume`. This means `getCurrentActivity()` could return the wrong instance, or `null` if the activity was destroyed. To give developers access to the Activity receiving the result (which is also about to become the current activity), pass it as an argumento the listener.
Fixes github issue #8694.
Reviewed By: donyu
Differential Revision: D3704141
fbshipit-source-id: e7e00ccc28114f97415e5beab8c9b10cb1e530be
Summary: This dependency on okhttp is unused. Removing this to lower the method-count increase from including the core RN modules.
Reviewed By: AaaChiuuu
Differential Revision: D3711870
fbshipit-source-id: 54b92edb4a55140b33cc74a5e9270650ced56ab9
Summary: This move lets us remove the dependency on okhttp3 from react/bridge. The classes I moved are all strictly related to dev support features and don't need to go into the core bridge module that gets shipped to production.
Reviewed By: AaaChiuuu
Differential Revision: D3698977
fbshipit-source-id: 6ba1517377061690cef289a544ec1622122cef85
Aaron Chiu
Adam Comella
Andrew
Konstantin Raev
Emil Sjolander
Steven Goff
Delyan Kratunov
John Shelley
Üstün Ergenoglu
Kirwan Lyster
Kevin Lacker
Lukas Piatkowski
Don Yu
Martin Konicek
David Aurelio
Ben Clayton
Yann Pringault
Venryx
Ryan Gomba
Vishal Kakadiya
Janic Duplessis
Connor McEwen
Benoit Lemaire
Andy Street
Pandiarajan Nagarajan
Lukas Woehrl
Michał Gregorczyk
Pieter De Baets
leeight
Kazuki Sakamoto
Andrew Jack
Alexander Blom
Pete Huitsing
Charles Chen
Christian Brevik
king6cong
Rene Weber
Andrew Y. Chen
Thomas Beverley
Antoine Rousseau
Ben Nham
Howard Yeh
Fabian Köster
Ovidiu Viorel Iepure
Emily Janzer
Giuseppe Ottaviano
Nikhilesh Sigatapu
Benoit Lemaire
Kevin Gozali
Yoshiya Hinosawa
Dmitry Petukhov
Jacob Parker
Tim Yung
Felix Oghina
Satyajit Sahoo
Mike Lambert
Andy
Hoa Dinh
Alexander Pantyuhov
Andrei Coman
Dave Pack
Nicolas Charpentier
Chris Hopman
Marc Horowitz
Aaron Chiu
Brad Daily
Gant Laborde
ransj
Fred Liu
William Liu
Andrei Coman
Alexander Oprisnik
Scott Buckfelder
Lucas Rocha
Michal Lowicki
Jennifer Wang
Sriram Ramasubramanian
Mani Ghasemlou
