Summary:
AccessibilityInfo.announceForAccessibility is currently only available on iOS. I've added the Android specific implementation, updated RNTester, and the documentation.
[Android] [Added] - Added AccessibilityInfo.announceForAccessibility for Android
[General] [Added] - RNTester example for AccessibilityInfo.announceForAccessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/24746
Differential Revision: D15258054
Pulled By: cpojer
fbshipit-source-id: 3e057a5c32b28e30ea2ee74a18854b012cd2dbfd
Summary:
In https://github.com/facebook/react-native/pull/23865, RN introduced support for custom fonts the Android Way. But it introduced performance regression because it'll lookup for a font using getIdentifier() every time fontFamily changed. This PR fixes regression by requiring custom fonts to be listed in **fonts** array, and populating **mTypeCache** at first use using the list.
[Android] [Changed] - Require custom fonts to list in **fonts** array. Fixes performance regression.
Pull Request resolved: https://github.com/facebook/react-native/pull/24595
Reviewed By: mdvacca
Differential Revision: D15184590
Pulled By: fkgozali
fbshipit-source-id: e3feb2396609583ebc95101130186a1f5af931da
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Summary:
In #24095, we removed the code that changes the underlying Android view's enabled state to false when "disabled" is included in the accessibility states, which seems correct. The Android view's state shouldn't mirror the accessibility state, it should be the other way round-- the accessibility state should represent the state of the view.
It seems that the existing test is brokenly setting the disabled state in the Javascript object, and then querying the Android view's enabled state to confirm the change. If the Button implementation is actually the culprit, then IMHO, the correct fix would be to have the Button implementation manipulate the Android View's enabled state, not the accessibilityStates code.
[android] [fix] - Fix internal test case around disabled state of buttons
Pull Request resolved: https://github.com/facebook/react-native/pull/24678
Differential Revision: D15237590
Pulled By: cpojer
fbshipit-source-id: d7ebefbcba9d4d9425da4285175302e4b6435df7
Summary: I'm not sure if this is a good idea. Right now FabricUIManager creates a ThemedReactContext in addRootView() using the RAC you pass in. If you pass in an RAC without a Catalyst instance, this will throw; this diff makes it so it'll throw the next time you try to actually try to access the CatalystInstance, instead. I don't know if we're really relying on this right now, but we need to be able to create a ThemedReactContext without a CatalystInstance for Venice (for now, until we actually go through and get rid of TRC's dependency on the CatalystInstance entirely - but that'll be a lot more work)
Reviewed By: mdvacca
Differential Revision: D15194220
fbshipit-source-id: 64689cbe79c84ae33fe16e3dc396e3c69ec8e20f
Summary: Refactoring ReactContext to move message queue initialization into its own function that can be called independently of initializeWithInstance. This allows you to create a ReactContext with message queue threads without a CatalystInstance.
Reviewed By: mdvacca
Differential Revision: D14817741
fbshipit-source-id: f314a526c6534792714e5ba55dd873f1728c6b9f
Summary:
[General] [Fix] - Reorder operations of native view hierarchy
When we update the native view hierarchy in `manageChildren` we:
1. iterate through all views we plan to remove and remove them from the native hierarchy
2. iterate through all views we plan to add and add them to the native hierarchy
3. iterate through all views we plan to delete and delete them (remove them from memory)
This covers these cases:
a. A view is moved from one place to another -- handled by steps 1 & 2
b. A view is added -- handled by step 2
c. A view is deleted -- handled by step 1 & 3
> Note the difference between remove and delete
Everything above sounds fine! But...
The important bit:
**A view that is going to be deleted asynchronously (by a layout animation) is NOT removed in step 1. It is removed and deleted all in step 3.** See: https://fburl.com/ryxp626i
If the reader may recall we solved a similar problem in D14529038 where we introduced the `pendingIndicesToDelete` data structure to keep track of views that were marked for deletion but had not yet been deleted. An example of an order of operations that we would've solved with D14529038 is:
* we "delete" the view asynchronously (view A) in one operation
* we add a view B that shares a parent with view A in subsequent operation
* view A finally calls its callback after the animation is complete and removes itself from the native view hierarchy
A case that D14529038 would not fix:
1. we add a view B in one operation
2. we delete a view A in the same operation asynchronously because it's in a layout animation
3. ... etc.
What we must remember is that the index we use to add view B in step 1 is based on the indices assuming that all deletions are synchronous as this [comment notes](https://fburl.com/j9uillje): removals (both deletions and moveFroms) use the indices of the current order of the views and are assumed independent of each other. Whereas additions are indexed on the updated order (after deletions!)
This diff re-arranges the order in how we act upon the operations to update the native view hierarchy -- similar to how UIImplementation does its operations on the shadow tree here: https://fburl.com/j9uillje
By doing the removals and deletions first, we know that the addAt indices will be correct because either the view is removed from the native view hierarchy or `pendingIndicesToDelete` should be tracking an async delete already so the addAt index will be normalized
Reviewed By: mdvacca
Differential Revision: D15112664
fbshipit-source-id: 85d4b21211ac802183ca2f0fd28fc4437d312100
Summary:
This diff forces the eager initialization of some additional classes into FabricJSIModuleProvider.loadClasses().
This is a "hack" that will be removed in the near future
Reviewed By: JoshuaGross
Differential Revision: D15208977
fbshipit-source-id: 2e2c7856839b6c6888452800ef6da7f269e46735
Summary: When passing StateWrapper objects across the JNI, we were not ensuring that the Java objects would own the C++ state. This was initially done because I assumed that in Java, State would either be used immediately or discarded, so this wouldn't be unsafe. As it turns out, it makes sense in some cases to store the StateWrapper in Java and use it later, potentially even in other threads, so we need to make sure we maintain ownership of the C++ object from the Java object.
Reviewed By: shergin
Differential Revision: D15206194
fbshipit-source-id: a437d921ba00b194cf08bad80666bd99baf11d52
Summary: This diff implements encapsulating all time metrics in a single class for better extensibility and readability.
Reviewed By: JoshuaGross
Differential Revision: D15179835
fbshipit-source-id: 62bdf94435a0d37a87ad9bad613cc8e38043a235
Summary:
`CatalystInstanceImpl.cpp` now depends on `JSCallInvoker` and `JavaJSCallInvokerHolder`. Therefore, we need to correctly adjust the OSS builds to include these dependencies into the `libreactnativejni.so` file.
I made `ReactCommon/turbomodule/jscallinvoker` a static library `libjscallinvoker.a`. I then made `ReactAndroid/src/main/jni/react/jni`'s `libreactnativejni.so` depend on that static library. Also, because the Android NDK build system doesn't support header namespaces, I had to use the filesystem to simulate them. This is why all the `.cpp` and `.h` files for `JSCallInvoker` were moved to a `jsireact` folder.
Reviewed By: mdvacca
Differential Revision: D15194821
fbshipit-source-id: 0cee682e41db53d0619f56ad017d5882f6d554aa
Summary:
`TurboModuleManagerDelegate` is an abstract base class with the following API:
```
public TurboModule getModule(String name, ReactApplicationContext reactApplicationContext);
public CxxModuleWrapper getLegacyCxxModule(String name, ReactApplicationContext reactApplicationContext);
```
```
std::shared_ptr<TurboModule> getTurboModule(std::string name, jni::global_ref<JTurboModule> turboModule, std::shared_ptr<JSCallInvoker> jsInvoker) override;
std::shared_ptr<TurboModule> getTurboModule(std::string name, std::shared_ptr<JSCallInvoker> jsInvoker) override;
```
On the C++ side, when asked to provide a TurboModule with name `name`:
1. First, is this a CxxModule? If so:
1. Create the CxxModule and return
2. Otherwise:
1. Somehow get a Java instance of the TurboModule
2. If this Java object represents a CxxModule, like `FbReactLibSodiumModule`:
1. Grab the C++ part of this object, and wrap it in a `TurboCxxModule.cpp` and return.
3. Otherwise:
1. Wrap the Java object in a C++ HostObject and return.
This pseudocode demonstrates how we'd use `TurboModuleManagerDelegate` to implement `__turboModuleProxy`.
```
__turboModuleProxy(name, jsCallInvoker):
let cxxModule = TurboModuleManagerDelegate::getTurboModule(name, jsCallInvoker)
if (!cxxModule) {
return cxxModule;
}
// JNI Call that forwards to TurboModuleManagerDelegate.getLegacyCxxModule
let javaCxxModule : CxxModuleWrapper = TurboModuleManager.getLegacyCxxModule(name)
if (!javaCxxModule) {
return std::shared_ptr<react::TurboCxxModule>(javaCxxModule.getModule())
}
// JNI Call that forwards to TurboModuleManagerDelegate.getModule
let javaModule : TurboModule = TurboModuleManager.getModule(name)
if (!javaCxxModule) {
return TurboModuleManagerDelegate::getTurboModule(name, javaModule, jsCallInvoker)
}
return null
```
Reviewed By: mdvacca
Differential Revision: D15111335
fbshipit-source-id: c7b0aeda0e4565e3a2729e7f9604775782b6f893
Summary:
JSCallInvoker requires a `std::weak_ptr<Instance>` to create. In our C++, `CatalystInstance` is responsible for creating this `Instance` object. This `CatalystInstance` C++ initialization is separate from the `TurboModuleManager` C++ initialization. Therefore, in this diff, I made `CatalystInstance` responsible for creating the `JSCallInvoker`. It then exposes the `JSCallInvoker` using a hybrid class called `JSCallInvokerHolder`, which contains a `std::shared_ptr<JSCallInvoker>` member variable. Using `CatalystInstance.getJSCallInvokerHolder()` in TurboModuleManager.java, we get a handle to this hybrid container. Then, we pass it this hybrid object to `TurboModuleManager::initHybrid`, which retrieves the `std::shared_ptr<JSCallInvoker>` from the `JavaJSCallInvokerHandler`.
There were a few cyclic dependencies, so I had to break down the buck targets:
- `CatalystInstanceImpl.java` depends on `JSCallInvokerHolderImpl.java`, and `TurboModuleManager.java` depends on classes that are packaged with `CatalystInstanceImpl.java`. So, I had to put `JSCallInvokerHolderImpl.java` in its own buck target.
- `CatalystInstance.cpp` depends on `JavaJSCallInvokerHolder.cpp`, and `TurboModuleManager.cpp` depends on classes that are build with `CatalystInstance.cpp`. So, I had to put `JavaJSCallInvokerHolder.cpp` in its own buck target. To make things simpler, I also moved `JSCallInvoker.{cpp,h}` files into the same buck target as `JavaJSCallInvokerHolder.{cpp,h}`.
I think these steps should be enough to create the TurboModuleManager without needing a bridge:
1. Make `JSCallInvoker` an abstract base class.
2. On Android, create another derived class of `JSCallInvoker` that doesn't depend on Instance.
3. Create `JavaJSCallInvokerHolder` using an instance of this new class somewhere in C++.
4. Pass this instance of `JavaJSCallInvokerHolder` to Java and use it to create/instatiate `TurboModuleManager`.
Regarding steps 1 and 2, we can also make JSCallInvoker accept a lambda.
Reviewed By: mdvacca
Differential Revision: D15055511
fbshipit-source-id: 0ad72a86599819ec35d421dbee7e140959a26ab6
Summary: Convert FabricUIManager.measure params to floats. Currently we convert parameters to ints across the JNI boundary, and then back to floats several times in Java. This is unnecessary and actually makes measurements trickier. The new implementation uses floats across the JNI boundary and uses Float.POSITIVE_INFINITY to represent unconstrained values, which is consistent with Fabric C++ as well.
Reviewed By: shergin, mdvacca
Differential Revision: D15176108
fbshipit-source-id: cf849b3773007637f059279460163872f300a4aa
Summary:
When acquiring the `PARTIAL_WAKE_LOCK`, Android requires a tag to identify the source, normally the class name. This tag will show on dumpsys call and Google Play developer console.
`getSimpleName` will work fine as long as not enable ProGuard, in my case, it transformed the class name to just `"c"`, and I take my half day to find where the `c` comes from.
`getCanonicalName` will add the package path, which is more friendly for developers.
Later we can even let the developer choose the tag name, but this will require API break changes.
[Android] [Changed] - Use class canonical name for PARTIAL_WAKE_LOCK tag
Pull Request resolved: https://github.com/facebook/react-native/pull/24673
Differential Revision: D15164306
Pulled By: cpojer
fbshipit-source-id: fd65f9e5250c180b0053940b17877fe36af5d48b
Summary: The map of sComponentNames ONLY contains the names of components that are different between JS and Android. This diff adds a method to unify the way we use this map.
Reviewed By: shergin
Differential Revision: D15076549
fbshipit-source-id: 9df750dca305e55cb44037bc63f3ebb6476c8b81
Summary: Trivial diff that adds extra logging information on Exceptions that are thrown by the FabricViewTest
Reviewed By: shergin
Differential Revision: D14817899
fbshipit-source-id: 32e1d1fcd1292715dfcf2750d3f14c668927c8b8
Summary:
This diff fixes a bug that is reproducible when a view is reordered in a different level of hierarchy in the react tree.
Even if this is not supported by react, this can still happen because of viewFlattening.
Reviewed By: shergin
Differential Revision: D14817452
fbshipit-source-id: 13425b0e6a280affe681e80b4a6daa17ee56251a
Summary: This diff refactors the way we synchronize in ReactChoreographer using a lock object
Reviewed By: ejanzer
Differential Revision: D14913056
fbshipit-source-id: e86c4395d5d3c3fd5b7330b72c14920b536f74ce
Summary:
Hello Everyone, this series of commits helps to fix problems related to ART on Android. The main problem in here is that the ART components would disappear if the user turns off the screen and then turn it on again. It's important to note that this behaviour only occurs after Android N (7.1 or higher).
Pull Request resolved: https://github.com/facebook/react-native/pull/22624
Differential Revision: D15122573
Pulled By: cpojer
fbshipit-source-id: e7fb8b9280b4c52562e3d0c1a89759d4d31cd53d
Summary:
On android when borderXColor is null it causes the app to crash with:
```
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: com.facebook.react.bridge.NoSuchKeyException: borderBottomColor
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:111)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:115)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getInt(ReadableNativeMap.java:158)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.uimanager.ViewProps.isLayoutOnly(ViewProps.java:246)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.uimanager.NativeViewHierarchyOptimizer.isLayoutOnlyAndCollapsable(NativeViewHierarchyOptimizer.java:482)
```
Basically it is missing a `isNull` check on the props map before trying to access the value.
Fixes#22727
[Android] [Fixed] - Fix a crash when borderXColor is null
Pull Request resolved: https://github.com/facebook/react-native/pull/24640
Differential Revision: D15120182
Pulled By: cpojer
fbshipit-source-id: bc41da572f04d8abf733b5a4e94a74a0f40acda1
Summary:
Now RN has only ReactActivity which extends AppCompatActivity, subclass of FragmentActivity, therefore no need to check if activity is FragmentActivity or not. This PR changes DialogModule to work only with FragmentActivity.
Also DialogFragment from Android is deprecated in API 28, and recommends to use DialogFragment from Support Library. Excerpt from DialogFragment documentation.
> **This class was deprecated in API level 28.**
> Use the Support Library DialogFragment for consistent behavior across all devices and access to Lifecycle.
**BREAKING CHANGE**: Brown field apps must extend FragmentActivity or its subclasses.
[Android] [Changed] - DialogModule supports only FragmentActivity
Pull Request resolved: https://github.com/facebook/react-native/pull/23365
Differential Revision: D14021986
Pulled By: cpojer
fbshipit-source-id: b0ede60ef19cec48111a12701659a8bc1f66c331
Summary:
Assistive technologies use the accessibility role of a component to tell the disabled user what the component is, and provide hints about how to use it. Many important roles do not have analog AccessibilityTraits on iOS. This PR adds many critical roles, such as editabletext, checkbox, menu, and switch to name a few.
Accessibility states are used to convey the current state of a component. This PR adds several critical states such as checked, unchecked, on and off.
[general] [change] - Adds critical accessibility roles and states.
Pull Request resolved: https://github.com/facebook/react-native/pull/24095
Differential Revision: D15079245
Pulled By: cpojer
fbshipit-source-id: 941b30eb8f5d565597e5ea3a04687d9809cbe372
Summary:
We are seeing crash reports that the webview is missing. In this case
it should fail gracefully so that a missing webview does not block
from using an app built with React Native.
The contains could also be changed to check for "webview" in general
to catch all webview related exception. It's currently checking on
for the specific string that I'm seeing in our app's crashreporting tool.
<img width="1507" alt="Screen Shot 2019-04-19 at 11 26 19 AM" src="https://user-images.githubusercontent.com/741767/56438307-5e1c2f80-6297-11e9-970b-a5095d18e9d7.png">
<img width="935" alt="Screen Shot 2019-04-19 at 11 32 58 AM" src="https://user-images.githubusercontent.com/741767/56438213-fa920200-6296-11e9-8008-5eb344eca8a8.png">
[Android] [Fixed] - The ReactCookieJarContainer/ForwardingCookieHandler now handles the missing WebView gracefully.
Pull Request resolved: https://github.com/facebook/react-native/pull/24533
Differential Revision: D15062824
Pulled By: cpojer
fbshipit-source-id: 80805a47494f0d924b7ee029ce8ca0504eaeee57
Summary:
@public
In order to encapsulate property access on `YGStyle`, as a first measure we wrap all fields with accessors.
This will e.g. enable dynamic property storage and instrumentation in the future.
All accessors have a `const` version that allows direct access via `const&`. For mutation, bit fields are wrapped with a custom reference object.
This style allows for the least amount of changes in client code. Property access simply needs appended parens, eg `style.direction` becomes `style.direction`.
Reviewed By: shergin
Differential Revision: D14999096
fbshipit-source-id: fbf29f7ddab520513d4618f5e70094c4f6330b30
Summary:
React Native Environment Info:
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Memory: 1.12 GB / 15.55 GB
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 8.10.0 - /usr/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 3.5.2 - /usr/bin/npm
SDKs:
Android SDK:
API Levels: 16, 19, 22, 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-16 | Google APIs Intel x86 Atom, android-19 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
npmPackages:
react: 16.8.6 => 16.8.6
react-native: git+https://github.com/facebook/react-native.git#v0.59.5 => 0.59.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
The workaround implemented in https://github.com/facebook/react-native/pull/21117 tries to fix
https://issuetracker.google.com/issues/112385925 scroll direction (according to the latest comments, the scroll direction problem has been reverted in security patches so not sure if the workaround is still valid).
But... proposed solution in fling method is using signum which leads to zero computedVelocityY in case of zero mOnScrollDispatchHelper.getYFlingVelocity() on old devices(Samsung s4 mini) even when real velocityY is non zero
```
final int correctedVelocityY = (int)(Math.abs(velocityY) * Math.signum(mOnScrollDispatchHelper.getYFlingVelocity()));
```
Proposed solution is to take signum from original velocityY in case of zero
```
float signum = Math.signum(mOnScrollDispatchHelper.getYFlingVelocity());
if (signum == 0) {
signum = Math.signum(velocityY);
}
final int correctedVelocityY = (int)(Math.abs(velocityY) * signum);
```
The symptoms are the same as described in issue https://github.com/facebook/react-native/issues/22925, but proposed workaround doesn't work.
[Android][fixed] - Fix smooth scrolling on old devices (SDK >=16)
Pull Request resolved: https://github.com/facebook/react-native/pull/24545
Differential Revision: D15044834
Pulled By: cpojer
fbshipit-source-id: 3f523eb1a438df774e22387aecded433b9031ab9
Summary:
`MountingTransaction` encapsulates all artifacts of `ShadowTree` commit, particularly list of mutations and meta-data.
We will rely on this heavily in the coming diffs.
Reviewed By: JoshuaGross
Differential Revision: D15021795
fbshipit-source-id: 811da7afd7b929a34a81aa66566193d46bbc34f8
Summary: It seems like ReactContext isn't actually needed in measure functions. Changing the signature of ViewManager.measure() to take a Context instead.
Reviewed By: lunaleaps
Differential Revision: D14940330
fbshipit-source-id: b29987fd1d7f9c191a5f26138151082ca61cb351
Summary:
React Native has a `NativeModule` to manipulate programmatically the dev menu options (live reload, hot reload, remote debugging, etc), called [`DevSettings`](https://github.com/facebook/react-native/blob/master/React/Modules/RCTDevSettings.mm#L120). However this module is only available for iOS.
This PR brings the same `DevSettings` for Android, making it a cross-platform NativeModule.
Motivation: Right now if your app needs to programmatically reload RN, one option is to install [`react-native-restart`](https://www.npmjs.com/package/react-native-restart). It's a tiny dependency, but it's annoying to have to install it, while the code to do so is inside RN codebase. According to NPM, react-native-restart has ~12k weekly downloads, shows it's a recurring feature for many apps (my case).
Thus making `NativeModules.DevSettings` is a small increment in the codebase, just exposing the dev menu methods, to improve the Development Experience
[Android] [Added] - Add DevSetting native module (making it cross-platform)
With expection of `setIsShakeToShowDevMenuEnabled`, the following methods will be available for both platforms:
* reload
* setHotLoadingEnabled
* setIsDebuggingRemotely
* setIsShakeToShowDevMenuEnabled
* setLiveReloadEnabled
* setProfilingEnabled
* toggleElementInspector
Pull Request resolved: https://github.com/facebook/react-native/pull/24441
Differential Revision: D14932751
Pulled By: cpojer
fbshipit-source-id: 465e6a89c3beb5fd1ea22e80ea02e9438f596a09
Summary:
In order to meet our accessibility requirements we need to have full support for keyboard navigation. The Touchable components works with press/tap with a finger, but doesn't respond to 'enter' when using a keyboard. Navigation works fine. This PR adds an onClick listener to touchable views that have the onPress prop defined.
[Android] [Added] - Add View.OnClickListener to Touchable components when onPress is defined
Pull Request resolved: https://github.com/facebook/react-native/pull/24359
Differential Revision: D14971230
Pulled By: cpojer
fbshipit-source-id: ca5559ca1308ee6c338532a00dcea4d00fa57f42
Summary: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
Summary:
Would like feedback from the community as this may not be the best solution for all
I would like to restrict (or paginate) the fling of a horizontal ScrollView when `snapToInterval` is set. This is not currently possible with `pagingEnabled`, since the pagination works only when items are the entire width of the ScrollView.
This implementation simply restricts the predicted `targetOffset` found from the `x` velocity and replaces it with the offset when the pan gesture ended.
To get pagination working, I may paginate based on the interval by calculating the offset delta from the beginning of the gesture to current offset and restricting the scrolling behavior to the `snapToInterval`. If this is preferred, I can update this PR or make a new one, but wanted to start a discussion since it seems like there are many in the community that would like this feature #21302 .
[General] [Added] - add prop `disableIntervalMomentum` to disable the predictive scrolling behavior of horizontal ScrollViews
Pull Request resolved: https://github.com/facebook/react-native/pull/24045
Differential Revision: D14939754
Pulled By: sahrens
fbshipit-source-id: 26be19c47dfb8eed4d7e6035df53a77451e23081
Summary:
For a small subset of Android devices, the following line of code caused the device to crash
```
output.transferFrom(input, 0, Long.MAX_VALUE);
```
According to the [Java docs](https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/channels/FileChannel.html), this is what the function does.
> Transfers bytes into this channel's file from the given readable byte channel.
An attempt is made to read up to count bytes from the source channel and write them to this channel's file starting at the given position. An invocation of this method may or may not transfer all of the requested bytes; whether or not it does so depends upon the natures and states of the channels. Fewer than the requested number of bytes will be transferred if the source channel has fewer than count bytes remaining, or if the source channel is non-blocking and has fewer than count bytes immediately available in its input buffer.
Hence, using `Long.MAX_VALUE` seemed to be the standard way to transfer all bytes from one channel to the other.
However, it appeared that for some reason on a subset of old Android devices, the device tries to allocate `count` bytes of memory before transferring the bytes. Obviously, this caused a crash because no device has that much memory. This was fixed transferring bytes using a 1MB buffer.
Differential Revision: D14921778
fbshipit-source-id: 7fa46e10c656e23ae7d5679c72b278188f09ad0a
Summary:
Closes: https://github.com/facebook/react-native/issues/24016
React Native 0.57 introduced cross-platform `accessibilityRole` and `accessibilityStates` props in order to replace `accessibilityComponentType` (for android) and `accessibilityTraits` (for iOS). With #24095 `accessibilityRole` and `accessibilityStates` will increase, receiving more options, which seems to be a good moment to remove deprecated props.
Remove deprecated `accessibilityComponentType` and `accessibilityTraits` props.
[General] [Removed] - Remove accessibilityComponentType and accessibilityTraits props
Pull Request resolved: https://github.com/facebook/react-native/pull/24344
Reviewed By: rickhanlonii
Differential Revision: D14842214
Pulled By: cpojer
fbshipit-source-id: 279945e503d8a23bfee7a49d42f5db490c5f6069
Summary: Create views with props in one call instead of two. Backwards-compatible.
Reviewed By: shergin
Differential Revision: D14846424
fbshipit-source-id: cb53225579089f7e51d4e9d1fc9fc2e331a994c1
Summary: Similar to iOS, here we provide the basic impl of unimplemented view.
Reviewed By: mdvacca
Differential Revision: D14895706
fbshipit-source-id: 9053edfb2175b370d9070b6921794dbcafa1f37a
Summary:
Motivation is following - I'm sure many people encountered this because it has been like this for a long time.
1 . you're developing something on android, HMR and dev mode is enabled
2 . you go to dev settings, you disable dev mode because you want to see how something behaves
3 . you reload the app because that's what is required for the change to take effect
4 . you wait for the bundle to be compiled and served, and when that is done, you get an error message about HMR not being a registered callable module - because HMR is not available when `__DEV__ === false` (todo screenshot)
this fixes the described case by checking if HMR is enabled and dev mode disabled when reloading (step 3) and disables HMR in that case.
this also fixes the case when dev mode is disabled and without knowing it, you try to enable HRM (will enable both dev hmr and dev mode).
[Android] [Changed] - improve developer experience around Dev mode and HMR interop
Pull Request resolved: https://github.com/facebook/react-native/pull/24377
Differential Revision: D14890695
Pulled By: cpojer
fbshipit-source-id: 95b6ff4131c6d05a32aadd09a9d5ed11f602122c
Summary: Running animations sometimes fail in Android. we are ignoring those failures temporarly
Reviewed By: fkgozali
Differential Revision: D14884510
fbshipit-source-id: 66d6113e12b1bd67e8bcc564943b423825b4cea6
Alan Kenyon
Dulmandakh
Piotr Trocki
Marc Mulcahy
Eileen Zhang
Emily Janzer
Luna Wei
David Vacca
Joshua Gross
Valentin Shergin
Ramanpreet Nara
Tim Wang
Michał Pierzchała
Guilherme Iscaro
Janic Duplessis
Kevin Gozali
Thorben Primke
Christoph Nakazawa
David Aurelio
Pavel Rotek
Estevão Lucas
Sam Mathias Weggersen
Rick Ratmansky
Taylor123
Alston Lin
Mike Diarmid
Vojtech Novak
