Summary:
Simplify addLifecycleEventListener for the flaky test because we just want to test that listener is working.
Changelog:
[Android][Changed] - Add a spare implementation of addLifecycleEventListener for test purpose.
Reviewed By: PeteTheHeat
Differential Revision: D26749256
fbshipit-source-id: 5af216e6bfa37a15eb189aa24a3df35a7a7112de
Summary:
There's a field called `surfaceID` in a couple of classes that isn't the same as the integer `surfaceId` in Fabric.
For consistency, I've deprecated a couple of them, or renamed when appropriate.
In addition, now we're passing the actual integer surfaceId into the ThemedReactContext. This means that every single View created in Fabric gets annotated with the surfaceId it's in. Currently this isn't used, but the idea is that now each View has a mapping back to its surface, which could be used to simplify / optimize operations with SurfaceMountingManager. In particular, we might be able to use this in the future to optimize animations and/or event emitters.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26021571
fbshipit-source-id: b7db7de123db07fa928a6f815be86bdbb030e62c
Summary:
`UIManagerHelper.getUIManager()` relies on the bridge (CatalystInstance) to get the proper UIManager depending on which renderer is being used. Unfortunately, this means it will always return null in bridgeless mode, where the CatalystInstance doesn't exist. This diff replaces the implementation of `BridgelessReactContext.getJSIModule()` to return the FabricUIManager from the ReactHost/Instance.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22480968
fbshipit-source-id: 640e3f22a5b39b315ed2f0397be3cba39e80529a
Summary:
This changes how we access the EventDispatcher from the FabricUIManager in bridgeless mode.
Currently, we have implemented a similar API to what we use for Fabric (used in UIManagerHelper): `BridgelessReactContext.getJSIModule(UIManager).getEventDispatcher()`. However, `getJSIModule` does not have a nullable return type, which means that we have to throw an exception if the UIManager can't be found - if, for example, the instance is not initialized yet (or has been destroyed). This is causing crashes when a view tries to access the EventDispatcher before the instance is initialized, which takes longer for Venice because we include JS bundle loading as part of initialization (we may need to revisit that).
Ideally, we'd like to create a first-class API for `getEventDispatcher()`, and make sure that it never crashes if the instance is destroyed, because we don't care if JS events aren't delivered at that point. However, there are some obstacles to making this change for the bridge - mostly related to avoiding circular dependencies between the bridge module and the uimanager module. (Also, this might be a behavior change for the bridge, because I think we currently start queueing events before it's initialized? and product code might be relying on that).
Reviewed By: mdvacca
Differential Revision: D21672949
fbshipit-source-id: a38e96cd40c6f70124b7ca2a5c9722988fe7fcf4
Summary:
In bridgeless mode, we use BridgelessReactContext, which overrides some methods on ReactApplicationContext like `getJSIModule` and returns true for `isBridgeless`. This is needed for things like getting the EventDispatcher, which is currently accessed from the UIManagerModule (which doesn't exist in bridgeless mode).
However, when we create Views in React Native we don't use the ReactApplicationContext directly; instead, we create a ThemedReactContext, which holds a reference to the RAC. It also initializes itself with the RAC's CatalystInstance, so that when you call methods on the TRC it can access native modules, etc.
This doesn't work in bridgeless mode, because the methods are overridden on the RAC, *not* the TRC. So in order for this work as expected, we need to delegate these methods to the RAC member variable. In this diff I'm just doing this for `isBridgeless` and `getJSIModule` so that accessing the EventDispatcher works.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D19190760
fbshipit-source-id: 6dc38560edc1061aec782707306590fa1012d5cb
Summary: Removing the methods I recently added for storing/retrieving an instance key on a ReactContext.
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18710637
fbshipit-source-id: d34683ec660bd999db8112865e15392606fc9237
Summary:
This diff extends ThemeReactContext class to store the surfaceID field
The getSurfaceID method is being exposed as a public method
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18474015
fbshipit-source-id: ee1f859a802d36c51dec537fa91d90022523e88d
Summary:
Adding a new String field for `instanceKey` to ReactContext, which is set via a new constructor on ReactApplicationContext. Also adding getters to ReactContext and ThemedReactContext so that it's accessible from any instance/subclass of ReactContext.
This will only be used in bridgeless mode.
Reviewed By: mdvacca
Differential Revision: D18316556
fbshipit-source-id: 9757da72fde4ba36034c1e129326461fed496229
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary: In the future we're planning to decouple ThemedReactContext from the bridge (CatalystInstance). For now, we just need to be able to create a ThemedReactContext with a ReactContext that has no Catalyst instance.
Reviewed By: mdvacca
Differential Revision: D15246442
fbshipit-source-id: 99ebda6521f4df72969011ea0e6ea41b046875c8
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: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
`ThemedReactContext` wraps the actual `ReactContext` but doesn't actually receive any lifecycle events, which would set `mCurrentActivity`, so that's always stuck as `null`. To fix, we override `has/getCurrentActivity` and forward the call to the wrapped context, which actually has the correct lifecycle status.
Fixes issue #9310 on github.
Reviewed By: mkonicek
Differential Revision: D3703005
fbshipit-source-id: 363e87ac91d50516899b413e823d5312cbb807f4
This is an early release and there are several things that are known
not to work if you're porting your iOS app to Android.
See the Known Issues guide on the website.
We will work with the community to reach platform parity with iOS.
Joshua Gross
Lulu Wu
Emily Janzer
David Vacca
Emily Janzer
Andres Suarez
Oleksandr Melnykov
Eileen Zhang
Héctor Ramos
Sophie Alpert
Felix Oghina
Martin Konicek