Summary:
Add example showing regression before this fix is applied.
https://github.com/facebook/react-native/pull/18187 Was found to introduce a regression in some internal facebook code-base end to end test which couldn't be shared. I was able to create a reproducible demo of a regression I found, and made a fix for it. Hopefully this will fix the internal test, such that the pr can stay merged.
## Changelog
[GENERAL] [Fixed] - Fix connection of animated nodes and scroll offset with useNativeDriver.
Pull Request resolved: https://github.com/facebook/react-native/pull/24177
Reviewed By: rickhanlonii
Differential Revision: D14845617
Pulled By: cpojer
fbshipit-source-id: 1f121dbe773b0cde2adf1ee5a8c3c0266034e50d
Summary: This moves the Android related files to FB internal and moves the BUCK deps around.
Reviewed By: fkgozali
Differential Revision: D15392573
fbshipit-source-id: 251d2766729ed42a6fe312b3ab9c6b8f1a8c46d1
Summary: This moves the Toolbar Java files out RN and into our internal React shell.
Reviewed By: fkgozali
Differential Revision: D15469205
fbshipit-source-id: 15298505d74260618eb89673deb12d1b837b559f
Summary: Adding TurboModule for PlatformConstantsAndroid, and adding to Catalyst and Venice
Reviewed By: mdvacca
Differential Revision: D15630344
fbshipit-source-id: df6d5868cd3c9f54297bfea58683c8c1fd9375f0
Summary: Making DeviceInfo support TurboModule on Android; implementing the interface in the Java class and setting up codegen for the spec.
Reviewed By: mdvacca
Differential Revision: D15616194
fbshipit-source-id: 6326f23d95295e570df6f6c88289102ac733def7
Summary:
## Description
To initialize `TurboModuleManager`, we first need to wait until `ReactContext` is initialized. Then, we get the `TurboModuleManager` instance and assign it as the `TurboModuleRegistry` of `CatalystInstanceImpl`. This allows `CatalystInstanceImpl` to return TurboModules from its `getNativeModule` method. In `FbReactFragment`, we also wait until the `ReactContext` is initialized before then eagerly initialize a bunch of NativeModules. All this waiting is done by adding instances of `ReactInstanceEventListener` to `ReactInstanceManager`'s `mReactInstanceEventListeners` synchronized Set. When the `ReactContext` is finally initialized, we loop over this set and invoke all the listeners.
## Problem
We want to initialize `TurboModuleManager` and set it as the `TurboModuleRegistry` of `CatalystInstanceImpl` before we start eagerly initializing our NativeModules. Why? Because otherwise TurboModules that need to be eagerly initialized won't be. The fact that we're using a Set to manage the `ReactInstanceEventListener`s means that our listeners can be invoked in any order. This is bad because we can start to eagerly initialize NativeModules before we've had the chance to assign `TurboModuleManager` as the `TurboModuleRegistry` of `CatalystInstanceImpl`. In development, this race was leading to the following crash:
```
06-05 11:11:02.020 10461 10617 E AndroidRuntime: FATAL EXCEPTION: CombinedTP8
06-05 11:11:02.020 10461 10617 E AndroidRuntime: Process: com.facebook.wakizashi, PID: 10461
06-05 11:11:02.020 10461 10617 E AndroidRuntime: java.lang.AssertionError: Could not find module with name PrimedStorage
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.infer.annotation.Assertions.assertNotNull(Assertions.java:35)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.NativeModuleRegistry.getModule(NativeModuleRegistry.java:147)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:444)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.fbreact.fragment.FbReactFragment$4$1.run(FbReactFragment.java:418)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:457)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.WrappingExecutorService$1.run(WrappingExecutorService.java:82)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedSimpleTask.run(CombinedSimpleTask.java:81)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedLifetimeThreadFactory$1.run(CombinedLifetimeThreadFactory.java:40)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.NamedThreadFactory$1.run(NamedThreadFactory.java:53)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.lang.Thread.run(Thread.java:764)
```
## Diagnosing the crash
It looks like `NativeModuleRegistry.getModule` was throwing an error because `PrimedStorage` was null. `PrimedStorage` was turned into a TurboModule, so of course it wouldn't be in the `NativeModuleRegistry`. It should be in the `TurboModuleRegistry`. So, I placed an assertion in `CatalystInstanceImpl`:
```
Override
public NativeModule getNativeModule(String moduleName) {
Assertions.assertNotNull(mTurboModuleRegistry, "TurboModuleRegsitry is not null");
if (mTurboModuleRegistry != null) {
TurboModule turboModule = mTurboModuleRegistry.getModule(moduleName);
if (turboModule != null) {
return (NativeModule)turboModule;
}
}
return mNativeModuleRegistry.getModule(moduleName);
}
```
Sure enough, this assertion started tripping, which meant that `mTurboModuleRegistry` was null. From this information, I hypothesized that we started to eagerly initialize our NativeModules before `TurboModuleManager` was initialized. To verify this hypothesis, I added logging statements in each `ReactInstanceEventListener`: P65477469. `eagerInitializeReactNativeComponents (START)` documents when we start to eagerly intialize our NativeModules. `getReactInstanceManager (START)` documents when we start to initialize `TurboModuleManager` inside `FbReactInstanceHolder.getReactInstanceManager` method. Sure enough, when the program finally crashed, I saw in our logs that we started eagerly initializing our NativeModules before we initialized the TurboModuleManager:
```
06-05 11:11:01.951 10461 10617 V Ramanpreet: eagerInitializeReactNativeComponents (START): 1559758261951
06-05 11:11:01.956 10461 10461 V Ramanpreet: getReactInstanceManager (START): 1559758261956
06-05 11:11:01.958 10461 10461 D SoLoader: About to load: libturbomodulejsijni.so
06-05 11:11:01.960 10461 10461 D SoLoader: libturbomodulejsijni.so not found on /data/data/com.facebook.wakizashi/lib-zstd
06-05 11:11:01.960 10461 10461 D SoLoader: libturbomodulejsijni.so not found on /data/data/com.facebook.wakizashi/lib-xzs
06-05 11:11:01.960 10461 10461 D SoLoader: libturbomodulejsijni.so not found on /data/data/com.facebook.wakizashi/lib-assets
06-05 11:11:01.961 10461 10461 D SoLoader: libturbomodulejsijni.so found on /data/data/com.facebook.wakizashi/lib-main
06-05 11:11:01.965 10461 10461 D SoLoader: Loading lib dependencies: [libfb.so, libfbjni.so, libglog.so, libdouble-conversion.so, libxplat_jsi_jsiAndroid.so, libxplat_jsi_JSIDynamicAndroid.so, libfbsystrace.so, libmemalign16.so, libgnustl_shared.so, libm.so, libc.so]
06-05 11:11:01.999 10461 10769 D SoLoader: init exiting
06-05 11:11:01.999 10461 10461 D SoLoader: Loaded: libturbomodulejsijni.so
06-05 11:11:01.999 10461 10461 D SoLoader: About to load: libfb4aturbomodulemanagerdelegate.so
06-05 11:11:01.999 10461 10769 W fb4a.ImagePipelineFactory: ImagePipelineFactory has already been initialized! `ImagePipelineFactory.initialize(...)` should only be called once to avoid unexpected behavior.
06-05 11:11:02.002 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so not found on /data/data/com.facebook.wakizashi/lib-zstd
06-05 11:11:02.002 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so not found on /data/data/com.facebook.wakizashi/lib-xzs
06-05 11:11:02.002 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so not found on /data/data/com.facebook.wakizashi/lib-assets
06-05 11:11:02.004 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so found on /data/data/com.facebook.wakizashi/lib-main
06-05 11:11:02.007 10461 10461 D SoLoader: Loading lib dependencies: [libturbomodulejsijni.so, libfb.so, libfbjni.so, libxplat_jsi_jsiAndroid.so, libxplat_jsi_JSIDynamicAndroid.so, libreactnativejni.so, libmemalign16.so, libgnustl_shared.so, libc.so]
06-05 11:11:02.020 10461 10617 E AndroidRuntime: FATAL EXCEPTION: CombinedTP8
06-05 11:11:02.020 10461 10617 E AndroidRuntime: Process: com.facebook.wakizashi, PID: 10461
06-05 11:11:02.020 10461 10617 E AndroidRuntime: java.lang.AssertionError: Could not find module with name PrimedStorage
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.infer.annotation.Assertions.assertNotNull(Assertions.java:35)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.NativeModuleRegistry.getModule(NativeModuleRegistry.java:147)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:444)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.fbreact.fragment.FbReactFragment$4$1.run(FbReactFragment.java:418)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:457)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.WrappingExecutorService$1.run(WrappingExecutorService.java:82)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedSimpleTask.run(CombinedSimpleTask.java:81)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedLifetimeThreadFactory$1.run(CombinedLifetimeThreadFactory.java:40)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.NamedThreadFactory$1.run(NamedThreadFactory.java:53)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.lang.Thread.run(Thread.java:764)
06-05 11:11:02.038 1647 1667 I WifiService: requestActivityInfo uid=1000
06-05 11:11:02.038 1647 1667 I WifiService: reportActivityInfo uid=1000
06-05 11:11:02.038 1647 1667 I WifiService: getSupportedFeatures uid=1000
06-05 11:11:02.044 1647 1667 E BluetoothAdapter: Bluetooth binder is null
06-05 11:11:02.049 1647 1667 E KernelCpuSpeedReader: Failed to read cpu-freq: /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state (No such file or directory)
06-05 11:11:02.050 1647 1667 E BatteryExternalStatsWorker: modem info is invalid: ModemActivityInfo{ mTimestamp=0 mSleepTimeMs=0 mIdleTimeMs=0 mTxTimeMs[]=[0, 0, 0, 0, 0] mRxTimeMs=0 mEnergyUsed=0}
06-05 11:11:02.057 2147 10435 W ctxmgr : [AclManager]No 2 for (accnt=account#-517948760#, com.google.android.gms(10013):IndoorOutdoorProducer, vrsn=13280000, 0, 3pPkg = null , 3pMdlId = null , pid = 2147). Was: 3 for 57, account#-517948760#
06-05 11:11:02.077 10461 10461 D SoLoader: Loaded: libfb4aturbomodulemanagerdelegate.so
06-05 11:11:02.079 10461 10461 V Ramanpreet: getReactInstanceManager (END): 1559758262079
```
Reviewed By: mdvacca
Differential Revision: D15676746
fbshipit-source-id: a7ac02d868abf31c5d664b10f70b6db247f388f5
Summary:
## Summary
If a NativeModule Spec interface extends `TurboModule`, we want to make the auto-generated Java base class for that NativeModule to implement `com.facebook.react.turbomodule.core.interfaces.TurboModule`. This makes it so that our Android code recognizes that Java module as a TurboModule.
When this diff lands, all internal FB4A NativeModules will start going through the TurboModule system.
Reviewed By: fkgozali
Differential Revision: D15327683
fbshipit-source-id: e295dafdab7a0e130820318aeaf0cafa41487689
Summary: This diff introduces `TurboModuleManagerDelegate` in Fb4a and Workplace. `Fb4aTurboModuleManagerDelegate` is responsible for creating TurboModules for Fb4a. `WorkTurboModuleManagerDelegate` is responsible for creating TurboModules for Workplace.
Reviewed By: mdvacca
Differential Revision: D15268563
fbshipit-source-id: c254c31856c59b3551bfe54b25c715c848646c5a
Summary:
### Problem
According to https://github.com/facebook/react-native/issues/9145, the `--port` setting is not respected when executing `react-native run-android`. The templates that report things like what port the dev server runs on are hard coded as well.
### Solution
This commit replaces the hardcoded instances of port 8081 on Android with a build configuration property. This allows setting of the port React Native Android connects to for the local build server.
For this change to work, there must also be an update to the react native CLI to pass along this setting:
https://github.com/react-native-community/react-native-cli/compare/master...nhunzaker:9145-android-no-port-hardcode-cli
To avoid some noise on their end, I figured I wouldn't submit a PR until it's this approach is deemed workable.
## Changelog
[Android][fixed] - `react-native run-android --port <x>` correctly connects to dev server and related error messages display the correct port
Pull Request resolved: https://github.com/facebook/react-native/pull/23616
Differential Revision: D15645200
Pulled By: cpojer
fbshipit-source-id: 3bdfd458b8ac3ec78290736c9ed0db2e5776ed46
Summary: `TurboModuleManagerDelegate` is an interface used to query/create TurboModules. It doesn't need to know anything about `ReactApplicationContext`. So, I'm removing all references of `ReactApplicationContext` from this class.
Reviewed By: mdvacca
Differential Revision: D15590552
fbshipit-source-id: 761d3ed71f124955f9c6b997e68a7a8338182126
Summary:
Android followup for #24745. This adds a jsi object that removes blobs when it is gc'ed. We don't have many modules with native code on Android so I've added the native code directly in the blob package as a separate .so. I used a similar structure as the turbomodule package.
## Changelog
[Android] [Fixed] - [Blob] Release underlying resources when JS instance is GC'ed on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/24767
Differential Revision: D15279651
Pulled By: cpojer
fbshipit-source-id: 2bbdc4bbcbeae8945588ac5e3e895c49e6ac9e1a
Summary:
Addresses a number of pieces of feedback regarding the debug menu.
- Simplify labels for the debugger actions (e.g. no "remote", no emoji).
- Reorder actions so that modal items are generally lower.
- Renamed "Live Reloading" to "Reload-on-Save".
- Renamed "Dev Settings" to "Settings".
Changelog:
[Android] [Changed] - Cleaned up debug menu.
Reviewed By: cpojer
Differential Revision: D15553883
fbshipit-source-id: d30e8cd0804e010985c0cf40d443defc7c0710ac
Summary:
Every call site is either already using `createReactContextInBackground` correctly or guarding the invocation using `hasStartedCreatingInitialContext`. This is an unnecessary and overly complex dance that can be simplified.
This revision simplifies the use of `createReactContextInBackground` by integrating the check. This is not a breaking change.
Reviewed By: zackargyle, mdvacca
Differential Revision: D15566632
fbshipit-source-id: 7b50285c9ac6776d1297d2c9c53dff208851b722
Summary: D15391408 (https://github.com/facebook/react-native/pull/24695) added a new event type with the registration name 'onAccessibilityAction' on Android, using the key 'performAction'. On iOS the same event uses the key 'topAccessibilityAction', which caused a runtime error after I started registering both using the unified JS view config in D15488008. This diff changes Android to use the same name as iOS since the convention is to start with 'top'.
Reviewed By: cpojer
Differential Revision: D15542623
fbshipit-source-id: c339621d2b4d3e1700feb5419ae3e3af8b185ca8
Summary:
This diff fixes the bug of the switch component on Android being stuck in the middle when a user releases their finger whily dragging the thumb.
When a user releases their finger while dragging the thumb, `setChecked` will be called and if `mAllowChange` is set to false, `super.setChecked` is never called. The supper method will actually make sure the thumb will be animated to the correct edge. Without calling the super method, the thumb might stay in the middle of the switch where a user released their finger.
The fix had to be applied both to ReactSwitch and FbReactSwitchCompat.
One more fix had to be made to FbReactSwitchCompat since D5884661 was applied to ReactSwitch, but not to FbReactSwitchCompat:
if (mAllowChange && **isChecked() != checked**) {
...
}
Reviewed By: mdvacca
Differential Revision: D15535611
fbshipit-source-id: 22ca1fe3fa993ae65cbd677bfae2208a02c368d4
Summary:
We currently have two different codepaths for actually rendering a surface with Fabric on iOS and Android: on iOS we use Fabric's `UIManagerBinding.startSurface` to call `AppRegistry.runApplication`, but on Android we don't; instead we use the same codepath as paper, calling `ReactRootView.runApplication`.
This diff does a few different things:
1. Unify iOS and Android by removing the `#ifndef` for Android so that we call `startSurface` for both
2. Pass through the JS module name on Android so that this actually works (it currently passes in an empty string)
3. Remove the call to `ReactRootView.runApplication` for Fabric so that we don't end up doing this twice
4. Copy over some logic that we need from `ReactRootView.runApplication` (make sure that root layout specs get updated, and that content appeared gets logged)
Reviewed By: mdvacca
Differential Revision: D15501666
fbshipit-source-id: 5c96c8cf036261cb99729b1dbdff0f7c09a32d76
Summary:
[Android][Fix] - Fix how we normalize indices
Before, we were incorrectly normalizing indices given pending view deletion in the view hierarchy (namely, using LayoutAnimations)
What we had before (that was wrong):
* Maintained a pendingIndices sparse array for each tag
* For each pendingIndices sparse array we'd keep track of how many views we deleted at each abstract index
* Given an abstract index to delete a view at, we'd consult `pendingIndices` array to sum how many pending deletes we had for indices equal or smaller than and add to abstract index
^ Above algorithm is wrong and you can follow along with the following example to see how.
## The correct approach
Given these operations in this order:
1. {tagsToDelete: [123], indicesToDelete [2]}
2. {tagsToDelete: [124], indicesToDelete [1]}
3. {tagsToDelete: [125], indicesToDelete [2]}
4. {tagsToDelete: [126], indicesToDelete [1]}
The approach we want to be using to calculate normalized indices:
### Step 1: Delete tag 124 at index 2
|Views:|122|123|124|125|126|127|
|Actual Indices:|0|1|2|3|4|5|
|Abstract Indices:|0|1|2|3|4|5|
=> simple, we just mark the view at 2
### Step 2: Delete tag 123 at index 1
View tags and indices:
|Views|122|123|~~124~~|125|126|127|
|Actual indices|0|1|~~2~~|3|4|5|
|Abstract Indices|0|1||2|3|4|
=> again, simple, we can just use the normalized index 1 because no pending deletes affect this operation
### Step 3: Delete tag 126 at index 2
View tags and indices:
|Views|122|~~123~~|~~124~~|125|126|127|
|Actual Indices|0|~~1~~|~~2~~|3|4|5|
|Abstract Indices|0|||1|2|3|
=> Here we want to normalize this index to 4 because we need to account the 2 views that should be skipped
### Step 4: Delete tag 125 at index 1
View tags and indices:
|Views|122|~~123~~|~~124~~|125|~~126~~|127|
|Actual Indices|0|~~1~~|~~2~~|3|~~4~~|5|
|Abstract Indices|0|||1||2|
=> The normalized index should be 3.
This diff updates the function `normalizeIndex` to do the above algorithm by repurposing `pendingIndicesToDelete` to instead be a sparse int array that holds [normalizedIndex]=[tag] pairs
It's required that `pendingIndicesToDelete` is ordered by the normalizedIndex.
Reviewed By: mdvacca
Differential Revision: D15485132
fbshipit-source-id: 43e57dffa807e8ea50fa1650c5dec13a6fded624
Summary:
This PR solves bug https://github.com/facebook/react-native/issues/24393 for Android. Allows an app to be opened with an NFC tag and getting the url trough Linking.getInitialURL()
## Changelog
[Android] [Fixed] - This branch checks also for `ACTION_NDEF_DISCOVERED` intent matches to set the initialURL
Pull Request resolved: https://github.com/facebook/react-native/pull/25055
Differential Revision: D15516873
Pulled By: cpojer
fbshipit-source-id: e8803738d857a69e1063e926fc3858a416a0b25e
Summary:
Add prop showSoftInputOnFocus to TextInput. This fixes#14045. This prop can be used to prevent the system keyboard from displaying at all when focusing an input text, for example if a custom keyboard component needs to be displayed instead.
On Android, currently TextInput always open the soft keyboard when focused. This is because `requestFocus` calls `showSoftKeyboard`, which in turn instructs `InputMethodManager` to show the soft keyboard.
Unfortunately even if we were to define a new input type that extends ReactEditText, there is no way to overcome this issue.
This is because `showSoftKeyboard` is a private method so it can't be overriden. And at the same time `requestFocus` needs to invoke `super.requestFocus` to properly instruct Android that the field has gained focused, so overriding `requestFocus` in a subclass of ReactEditText is also not an option, as when invoking `super.requestFocus` we would end up calling again the one defined in ReactEditText.
So currently the only way of doing this is to basically add a listener on the focus event that will close the soft keyboard immediately after. But for a split second it will still be displayed.
The code in the PR changes `requestFocus` to honor showSoftInputOnFocus as defined in Android TextView, displaying the soft keyboard unless instructed otherwise.
## Changelog
[Android] [Added] - Add showSoftInputOnFocus to TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25028
Differential Revision: D15503070
Pulled By: mdvacca
fbshipit-source-id: db4616fa165643d6ef2b3185008c4d279ae08092
Summary:
Okay, I think this is the best I can do David, I don't think there's an obvious/easy way for me to try to get `getIdentifier()` to return a non zero value. Setting it to what Spencer suggested works for my use case.
## Changelog
[Android] [Changed] - Update spinner mode to render spinner instead of calendar
Reviewed By: sahrens
Differential Revision: D15427793
fbshipit-source-id: b04f024a9a1f052f69f3bda47d77821782dc2c0e
Summary: trivial diff to remove warnings because of the lack of Nullable annotations in MountingManager.ViewState
Reviewed By: shergin
Differential Revision: D15476040
fbshipit-source-id: 2b9a4efa1be1d5aa29d4e32cf32c8ff502f7c60c
Summary: This is an optimization to avoid transfering updateState instructions twice during the frist render of a view (same a props)
Reviewed By: shergin
Differential Revision: D15476041
fbshipit-source-id: 8a62035dbbb63c93f86a2f8d217986a325cb1805
Summary: This diff fixes the rendering of Bottom Sheet in Fabric Android. In D15343702 we added state as part of the "preallocateView" method but we forgot to call viewManager.updateState(), this prevents the state to be updated during the first render.
Reviewed By: shergin
Differential Revision: D15476042
fbshipit-source-id: cd6fc9bdd178589d2e04f85723425b5e5c3e5a04
Summary: This class is not necessary anymore, this diff deletes it from the repo
Reviewed By: JoshuaGross
Differential Revision: D15457346
fbshipit-source-id: c7293d93b50271efe3b3d2121c128ba6e13c7627
Summary:
Changelog: [Android] [FIXED] - Fix backgroundColor top level prop of TextInput
This diff fixes two issues with the `backgroundColor` top level property of TextInput on Android:
* Now it is possible to set a **string** value for the top-level `backgroundColor` property of TextInput (crashed the app previously):
```
<TextInput backgroundColor="#ffccbb">Hello, React Native</TextInput>
```
* Now it's possible to set an **integer** value for the top-level `backgroundColor` property of TextInput (had no effect previously):
```
<TextInput backgroundColor={0xffccbbff}>Hello, React Native</TextInput>
```
A `customType = "Color"` annotation parameter must be provided for `ReactBaseTextShadowNode.setBackgroundColor(...)` since the color value must be previously processed in JS before sending it over the bridge to the native code. The JS code will parse the color value and return the proper ARGB color integer to the native platforms (https://fburl.com/uqup52tn).
Without providing the custom type for the background color, if a string value is set for the top-level `backgroundColor` property in the JS code, the Android code will crash since it expects an integer value for the color in `ReactBaseTextShadowNode.setBackgroundColor(...)`, but a string will be passed from JS without any conversion and there will be a `ClassCastException` thrown. If an integer value without the alpha component (like `0xffccbb`) is set, the Android native view would get an integer color value with its alpha component set to `0x00`, which means a transparent color.
On a side note: the alpha component of a color must always be set when using an integer value for `backgroundColor` since the JS code, while processing the color type, shifts the rightmost 8 bytes (alpha component) to the leftmost position. If those 8 bytes are not the alpha component, you will get the wrong color in the end. It doesn't seem to be a problem for string values of `backgroundColor` though.
Reviewed By: mdvacca
Differential Revision: D15453980
fbshipit-source-id: f3f5d9c9877cdbce79a67f2ed93ad4589576d166
Summary:
This diff fixes a bug on the update of accessibiltyState prop in RN Android.
In particular, this bug was reproducible when a view has an accessibiltyState = ['disabled'] and there was a state update to set the {accessibiltyState = {null}}. In this scenario, the BaseViewManager.setViewStates method did not update the view with the default values for accessibilityState
Reviewed By: sahrens
Differential Revision: D15446078
fbshipit-source-id: 75f160916e55f0ee469516db2fe9b0a7d4758cd8
Summary:
Right now calling FabricUIManager.addRootView() doesn't actually start running the application on Android. This diff:
1. Removes the #ifndef so that we actually call UIManagerBinding.startSurface() on Android
2. Passes through the JS module name from addRootView so we can render the surface (falls back to an empty string if not provided, which is the current behavior)
3. Adds an option for starting the surface using `RN$SurfaceRegistry` instead of `AppRegistry`, if that global property has been defined in JS. This is used for Venice (bridgeless RN)
Reviewed By: shergin
Differential Revision: D15366200
fbshipit-source-id: 4a506a589108905d4852b9723aac6fb0fad2d86e
Summary:
I just learned about Nuclide's auto-formatting (cmd-shift-c) and started using it in another diff, but I didn't want to pollute the diff with a bunch of formatting changes, so here we are.
I don't know if anyone else uses Nuclide's auto-formatting, or something else - happy to ditch this if that's not how we roll.
Reviewed By: shergin
Differential Revision: D15389601
fbshipit-source-id: e3b20acd073adf3cc7bab1f62d86c5b5dab8c4fc
Summary:
As currently defined, accessibilityStates is an array of strings, which represents the state of an object. The array of strings notion doesn't well encapsulate how various states are related, nor enforce any level of correctness.
This PR converts accessibilityStates to an object with a specific definition. So, rather than:
<View
...
accessibilityStates={['unchecked']}>
We have:
<View
accessibilityStates={{'checked': false}}>
And specifically define the checked state to either take a boolean or the "mixed" string (to represent mixed checkboxes).
We feel this API is easier to understand an implement, and provides better semantic definition of the states themselves, and how states are related to one another.
## Changelog
[general] [change] - Convert accessibilityStates to an object instead of an array of strings.
Pull Request resolved: https://github.com/facebook/react-native/pull/24608
Differential Revision: D15467980
Pulled By: cpojer
fbshipit-source-id: f0414c0ef6add3f10f7f551d323d82d978754278
Summary: As of D14529038, LayoutAnimations can sometimes throw an exception due to the view being null. This can happen when elements are removed/added and is not fixable in product code. This is a temporary fix - the root cause for this issue will be fixed soon.
Reviewed By: lunaleaps
Differential Revision: D15428791
fbshipit-source-id: 41200e572ed7d5d470754792c5576a0ea23fe946
Summary:
## Background
Legacy Cxx NativeModules are implemented as Hybrid classes. Essentially, when a Cxx NativeModule is requested, you instantiate its hybrid class, which then creates a C++ counterpart. Then, the bridge uses the C++ counterpart's `getModule()` method to obtain ownership of the Cxx NativeModule.
## Summary
This diff implements backwards-compability for Cxx NativeModules.
If a Cxx NativeModule implements the `TurboModule` interface, then when the module is requested by name, we:
1. Instantiate its Java hybrid class, createing a C++ counterpart.
3. Obtain the CxxModule from the C++ counterpart using `getModule()` and use it to create a `TurboCxxModule` instance (this forwards all JavaScript method calls to the CxxModule) inside `TurboModuleManager`.
5. Return this `TurboCxxModule` to JS.
Reviewed By: mdvacca
Differential Revision: D15252041
fbshipit-source-id: cdbb62632d7a8735f7687daf62de63df9e3ad2c5
Summary:
## Summary
If the Java instance of a TurboModule is null, then the resultant JS object returned from `TurboModuleRegistry` should also be null.
Reviewed By: mdvacca
Differential Revision: D15253476
fbshipit-source-id: 83a6b9aa97b547aeecf9b285986ad0f5b9e413da
Summary:
## Summary
This diff does a bunch of things:
1. The TurboModule resolution algorithm on Android now supports C++ TurboModules.
2. `SampleTurboCxxModule` is moved from `ReactCommon/turbomodule/samples/platform/ios/` to `ReactCommon/turbomodule/samples` so that both iOS and Android can share it.
3. `CatalystTurboModuleManagerDelegate::getTurboModule(std::string, JSCallInvoker)` now understands and returns `SampleTurboCxxModule`.
Reviewed By: mdvacca
Differential Revision: D15253477
fbshipit-source-id: 3def91911b091f8cf93be17decd245a0499ed718
Summary:
## Summary
People use `ReactPackage` instances to create NativeModules. To make the migration from NativeModule to TurboModule easy, I'm introducing a `TurboModuleManagerDelegate` that understands `ReactPackage`s, and uses them to lookup and create the Java TurboModule objects. This way, we don't have to change the way we declare NativeModules for the migration.
## TurboModule registration
Each application should have its own subclass of `ReactPackageTurboModuleManagerDelegate`. This subclass is a hybrid class with a C++ and a Java part. The Java part can (and probably should) do nothing (for now). The C++ part has to implement the `moduleName -> jni::HostObject` and `moduleName, javaInstance -> jni::HostObject` functions for all TurboModules in the application.
**Use Case: Migrating a NativeModule to TurboModule system**
1. Make the Java NativeModule extend `TurboModule`. (The reason why this doesn't happen automatically is probably because we haven't changed the Java codegen yet).
2. Modify the `moduleName -> jni::HostObject` or `moduleName, javaInstance -> jni::HostObject` functions to return the `TurboModule`.
**Use Case: Adding a new TurboModule**
1. Add the TurboModule to a `ReactPackage` in the application.
2. Modify the `moduleName -> jni::HostObject` or `moduleName, javaInstance -> jni::HostObject` functions to return the TurboModule `jsi::HostObject`.
**Note:** It's also possible to declare TurboModules by overriding the `getModule(String moduleName)` function of `ReactPackageTurboModuleManagerDelegate`. It's not a good idea, because it'll make switching between the NativeModule/TurboModule system difficult.
Reviewed By: mdvacca
Differential Revision: D15209129
fbshipit-source-id: 4b0a303595145be9b19d6f4934f956b91990f859
Summary: `ReactContext.getNativeModule` can be used to access NativeModules. With these changes, it can also be used to instantiate (if necessary) and retrieve a TurboModule.
Reviewed By: mdvacca
Differential Revision: D15167631
fbshipit-source-id: 3cb0d9a4be16cbadebbf6648c3f1481ba26513c3
Summary:
Set duration=0 for android keyboard events. Brings actual implementation closer to existing flowtypes, and duration is set to 0 to minimize impact on existing keyboard event consumers.
Follow up to #24947, upon cpojer's [input](https://github.com/facebook/react-native/pull/24947#issuecomment-494681618) :)
## Changelog
[Android] [Added] - Set duration=0 for android keyboard events
Pull Request resolved: https://github.com/facebook/react-native/pull/24994
Differential Revision: D15449394
Pulled By: cpojer
fbshipit-source-id: d43096238bd38d189fbec54fc2d93f17010d9ddb
Summary:
For some components, we will have state as soon as the ShadowNode is created that may be meaningful. In those cases, ViewManagers should be able to use State to create or preallocate views.
FB: This will be used in following diffs for Litho support.
Reviewed By: mdvacca
Differential Revision: D15343702
fbshipit-source-id: 8fd672251cb88dea662b5cae5a9efc96877d28a9
Summary:
We're working on a custom EditText that supports some rich text editing, and one of the places where our logic has to be different from the textinput provided by RN is the text setting logic:
https://github.com/facebook/react-native/blob/7abfd23b90db08b426c3c91b0cb6d01d161a9b9e/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java#L377
However, some of the important members are private and our subclass cannot access them (we work around this now with reflection). It would be nice if we could work with them directly, either using getters and setters or by changing the access. Let me know what you think about this. Thanks.
## Changelog
[Android] [Added] - allow custom maybeSetText logic for ReactEditText subclasses
Pull Request resolved: https://github.com/facebook/react-native/pull/24927
Differential Revision: D15431682
Pulled By: cpojer
fbshipit-source-id: 91860cadac0798a101ff7df6f6b868f3980ba9b1
Summary:
This pull request enhances the Keyboard API event emitter for Android upon `keyboardDidHide` by returning a `KeyboardEvent` with a meaningful `endCoordinates` property (instead of emitting a null as of current implementation). This change standardizes the `keyboardDidHide` keyboard event emission across both iOS and Android, which makes it easier for developers to use the API.
In particular, the semantics of `endCoordinates` emitted during the `keyboardDidHide` event on Android will match nicely with semantics of the same event emitted on iOS:
- `screenY` will be height of the screen, as that the keyboard has collapsed to the bottom of the screen
- `screenX` will be 0, as the keyboard will always be flush to the sides of the screen
- `height` will be 0, as the keyboard has fully collapsed
- `width` will be the width of the screen, as the keyboard will always extend to the width of the screen
Also, the flowtypes for `KeyboardEvent` have been further improved and are more explicit to better highlight the different object shapes (see `IOSKeyboardEvent` and `AndroidKeyboardEvent`) depending on the platform.
## Changelog
[Android] [Added] - Return endCoordinates for keyboardDidHide keyboard event
Pull Request resolved: https://github.com/facebook/react-native/pull/24947
Differential Revision: D15413441
Pulled By: cpojer
fbshipit-source-id: aa3998542b7068e9852467038f57310355018379
Summary:
Easy diff to refactor the sComponentNames map out of the FabricUIManager class.
This is a necessary clean-up to perform a slightly major refactor of the Fabric classes
Reviewed By: JoshuaGross
Differential Revision: D15421769
fbshipit-source-id: 3be73a6e20b338c8cea23ef0c88db417df7e3aa9
Mikael Sand
Christoph Nakazawa
Emily Janzer
Ramanpreet Nara
Krzysztof Borowy
Nate
Kody Greenbaum
Hermanyo
Janic Duplessis
Tim Yung
Ram N
Oleksandr Melnykov
Luna Wei
Andrea Cimitan
valerio.ponte
rkang
Shen Jin
David Vacca
Marc Mulcahy
Vojtech Novak
Blair Vanderhoof
nossbigg
Joshua Gross
