Summary:
With the updates to touch processing rolled out, we can remove the feature flag and clean up the old code. The old path is now used exclusively by legacy renderer and Fabric uses new `EventEmitter#receiveTouches` method to process touches.
Changelog:
[Changed][Android] - Update touch processing internals
Reviewed By: mdvacca
Differential Revision: D32953664
fbshipit-source-id: 517a4ce6ce9bc15528c2db94d7d11bdff8b78743
Summary:
Propagate event category definition to every event that is using `dispatchModernV2` (gated in production), providing opportunity to override categories of some events if needed. No events are meaningfully affected by this change, as coalesced events (e.g. scroll) are always dispatched as continuous and touch events are handled separately.
Changelog:
[Internal] Expose event category in Event class
Reviewed By: cortinico
Differential Revision: D31276249
fbshipit-source-id: f9a756b3a5cf5897e17209f3d0aed6a1c16cbd2e
Summary:
Updates event category deduction to match iOS implementation.
The event priority is used by concurrent mode to prioritize certain events, where Cxx part already assigns the correct priority based on the `ContinuousStart` -> `ContinuousEnd` spans. These spans can be deduced from the touch events, which we do in this implementation.
All events that can be "coalesced" (dispatched through `invokeUnique`) are assigned `Continuous` by default in Fabric core, so scroll/slider change events will never be discrete.
Changelog:
[Internal] Add category deduction to Android touch events
Reviewed By: mdvacca
Differential Revision: D31233233
fbshipit-source-id: f5b039aa137f1b4d2e2b15578bfc29ab6903a081
Summary:
For iOS, event category deduction is done from the C++ code, but the touch events are handled on Java layer in Android. This change exposes the category parameter through the `EventEmitterWrapper` called from Java, allowing to define category for events in the future.
Changelog:
[Internal] - Expose event category through JNI
Reviewed By: mdvacca
Differential Revision: D31205587
fbshipit-source-id: f2373ce18464b01ac08eb87df8f421b33d100be2
Summary:
In T94154173, when calling ```EventEmitterWrapper->invoke()```, hybrid function ```invokeEvent``` is null, even if we checked that ```mHybridData``` is valid before calling ```invokeEvent```.
**Theory:**
```invoke()``` is called from ```mqt_js``` thread, ```desotry()``` is called from ```main``` thread, which cause multi-thread access of```mHybridData```.
So if ```desotry()``` is called after ```isValid()``` check and before calling ```invokeEvent()```, ```invokeEvent``` could be destroyed and is null.
I can reproduce with above theory:
{F633411001}
**Fix:**
Make functions synchronized so ```mHybridData``` can be thread safe.
Changelog:
[Android][Fixed] - Make mHybridData thread safe
Reviewed By: RSNara
Differential Revision: D29792453
fbshipit-source-id: 8b4c754d53ece933be7b2cf99c6cd026b39e24ad
Summary:
Because of T92179998, T93607943, and T93394807, we are still seeking resolution to tricky crashes wrt the use of EventEmitters.
I believe the recent spike is because of two recent changes: we pass in EventEmitters earlier, during PreAllocation; and we clean them up earlier, during stopSurface, to avoid jsi::~Pointer crashes.
Additionally, the gating previously added around the PreAllocation path was incorrect and led to more nullptrs being passed around as EventEmitters.
To mitigate these issues:
1) I am adding/fixing gating to preallocation and early cleanup paths
2) I am making EventEmitterWrapper more resilient by ensuring EventEmitter is non-null before invoking it.
3) I am making sure that in more cases, we pass a non-null EventEmitter pointer to Java.
4) I am backing out the synchronization in EventEmitterWrapper (java side) as that did not resolve the issue and is a pessimisation
There are older, unchanged paths that could still be passing in nullptr as the EventEmitter (Update and Create). As those have not changed recently, I'm not going to fix those cases and instead, we can now rely on the caller to ensure that the EventEmitter is non-null before calling.
Changelog: [internal]
Differential Revision: D29252806
fbshipit-source-id: 5c68d95fa2465afe45e0083a0685c8c1abf31619
Summary:
Changelog: [internal]
Why does the crash happen?
We call method on invalid address. We crash on `std::weak_ptr::lock` because that's the first accessed ivar.
In D29020768 (https://github.com/facebook/react-native/commit/25e8fbe8ffa1c91522e91819a781434093f8b759), eventEmitter may be destroyed before an event is dispatched. Calling destroy on hybrid object destroys only C++ part.
Reviewed By: JoshuaGross
Differential Revision: D29194906
fbshipit-source-id: ae8d9d90aa8d98d69d29884e80d6b930b1e66870
Summary:
TL;DR: simplify and delete a bunch of stuff that shouldn't be necessary in Fabric.
I discovered that this event dispatcher (and the older one this is based on) is triple-queueing: we queue events into "staging", and then post "dispatch events" to only run /on the JS thread/. Even in Fabric. Then, each of these events is emitted into C++ where they are queued /again/! This refactor eliminates one more level of queueing - instead of scheduling dispatch for the JS thread, we just emit them directly to C++ when they're received in Java.
Unfortunately, the EventDispatcher is also used to drive AsyncEventBeat in C++:
1. EventBeatManager.onBatchEventDispatched: https://fburl.com/diffusion/qf6dyhsw
In the C++ impl, it indirectly will drive the AsyncEventBeat/AsyncEventBeatV2.
2. onBatchEventDispatched is ONLY called from EventDispatcherImpl: https://fburl.com/codesearch/mxk8ifyj
3. Which is queued and only runs on the JS thread: https://fburl.com/codesearch/czvbst4u
This means the AsyncEventBeat is only ticked when the JS thread is free, and ticks will be skipped when the JS thread is occupied for long periods.
Now, in this refactor, when this class is used it will drive AsyncEventBeat on every UI tick. This is also potentially not correct. On iOS (Fabric), AsyncEventBeat is driven when the UI thread is "about to sleep".
For now I'm not going to worry about that detail - it is significant, but Fabric+Android is currently /not doing the right thing/ and it's not clear that we want to maintain iOS behavior. This is something we need to discuss further and figure out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28654033
fbshipit-source-id: b3cb9b706343c8dd3c4cf84f24388908c57e2138
Summary:
Refactor EventEmitters to take an optional SurfaceId that Fabric will use, and non-Fabric will not.
Migrating touches is a good proof-of-concept for how this could be used generally, and as it turns out, TouchEvent's API is more flexible than most other event APIs (because it uses a dictionary to pass data around, so we can just stuff SurfaceId into it - not efficient, but flexible).
All new APIs are backwards-compatible and designed to work with old-style events, with Fabric and non-Fabric. Native Views that migrate to the new API will be backwards-compatible and get an efficiency boost in Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26025135
fbshipit-source-id: 5b418951e9d0a3882f2d67398f2aaadac8a3a556
Summary:
Create V2 EventEmitter that surfaceId can be passed into, with a backwards-compat layer, and some debug-only logging to help assist with migration.
Changelog: [Changed][Android] RCTEventEmitter has been deprecated in favor of RCTModernEventEmitter for optimal Fabric support; RCTEventEmitter will continue to work in Fabric, but there are minor perf implications.
Reviewed By: mdvacca
Differential Revision: D26027104
fbshipit-source-id: 784ca092bbc88d19c82f6c42537c34460d96de86
Summary:
The C++ counterpart of EventBeatManager uses RuntimeExecutor for that, so it's redundant to do that in EventBeatManager.java.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18307657
fbshipit-source-id: 65823b25d691a56540247d317e3c0e86685150c8
Summary:
This diff annotates Fabric MountingManager and Events classes with NonNull annotations, this will help analysis of nullability plus improving integration with Kotlin clients
Changelog: Add NonNull annotation to Fabric Event classes
Reviewed By: shergin
Differential Revision: D18010923
fbshipit-source-id: fb9d5683bbd51fa25dda9b2023f9c411c3ff541d
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 removes the Fabric Android implementation in favor of Fabric C++, as part of another diff I'm going to move the fabricxx package into fabric package
Reviewed By: shergin
Differential Revision: D9841240
fbshipit-source-id: c7922b7bfb9885f33b1f52237ec7cf00c1df96fb
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:
Removes the concept of instance handle. Instead we pass the event target
to createNode and don't pass it to subsequent clones.
The life time of the event target is managed by native (the event emitter).
It has to be released manually.
Reviewed By: shergin
Differential Revision: D8688330
fbshipit-source-id: e11b61f147ea9ca4dfb453fe07063ed06f24b7ac
Andres Suarez
Andrei Shikov
Lulu Wu
Joshua Gross
Samuel Susla
Valentin Shergin
David Vacca
Héctor Ramos
Sebastian Markbage