Summary:
Add the ability for UIManager to check if a node is an ancestor of anther one on Android like #7876 did on iOS
Closes https://github.com/facebook/react-native/pull/13129
Differential Revision: D4938319
Pulled By: hramos
fbshipit-source-id: abe20779be2142a1ea9ac46f52d8cd8609236419
Summary:
See https://github.com/facebook/react-native/issues/10845
onSizeChanged is enqueueing a runnable from the ui thread that references a shadow view by id on the native modules thread. Since the shadow thread 'runs ahead' of the UI thread (e.g. it has a newer state of the world than the UI thread), this isn't safe. By the time that code block runs, it's possible that an update from JS has already removed that view from the shadow hierarchy (a change which would then propagate to the native hierarchy on the UI thread).
Reviewed By: AaaChiuuu
Differential Revision: D4706521
fbshipit-source-id: 0915f081068709b895f70b2edce12163b39e5456
Summary:
I don't remember exactly where we talked about this but LayoutAnimation on Android is pretty stable now so there's no reason to keep it behind an experimental flag anymore. The only part that is not really stable is delete animations, so what I did is remove the default delete animation that we provide in presets.
**Test plan**
Tested that layout animations work properly without any config.
Closes https://github.com/facebook/react-native/pull/12141
Differential Revision: D4494386
Pulled By: mkonicek
fbshipit-source-id: 5dd025584e35f9bff25dc299cc9ca5c5bf5f17a3
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:
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: 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:
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:
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: 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:
This PR follows the work started in #6431 but instead of implementing the snapshot for Android, will just allow that feature to be implemented by a third party library.
The missing feature is the ability to resolve a View for a given tag integer. which is now possible with a `addUIBlock` on the `UIManagerModule` method where you give a `UIBlock` instance (a new class) that implements a `execute(NativeViewHierarchyManager)` function.
This is already possible in iOS API. a third party can use the `addUIBlock` too.
I have kept the name `addUIBlock` so it's the same as in the [iOS' API](https://github.com/facebook/react-native/search?q=addUIBlock&type=Code&utf8=%E2%9C%93).
---
With this PR a third party lib can now do...
```java
UIManagerModule uiManager = reactContext.getNativeModule(UIManagerModule.class);
uiManager.addUIBlock(new UIBlock() {
public void execute (NativeViewHierarchyManager nvhm) {
View view = nvhm.resolveView(tag);
...do something with view... like... screenshot t
Closes https://github.com/facebook/react-native/pull/8217
Differential Revision: D3469311
Pulled By: astreet
fbshipit-source-id: bb56ecc7e8936299337af47ca8114875ee1fd2b0
Summary: This adds support for UIManager.setChildren on Android like D2757388 added for iOS.
Reviewed By: andreicoman11
Differential Revision: D3235369
fb-gh-sync-id: b538556ec4abdb606f9be26d1b74734046bca0cd
fbshipit-source-id: b538556ec4abdb606f9be26d1b74734046bca0cd
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:This is the first from the series of PRs I'm going to be sending shorty that would let Animated.js animations to run off the JS thread (for Android only).
This PR introduce a new native module that will be used for offloading animations - NativeAnimatedModule. It has a simple API that allows for animated nodes management via methods like: create/drop animated node, connect/disconnect nodes, start animation of a value node, attach/detach animated from a native view.
Similarly to how we handle UIManager view hierarchy updates we create a queue of animated graph operations that are then executed on the UI thread. This isolates us from problems that may be caused by concurrent updates of animated graph while UI thread is "executing" the animation.
The most important class NativeAnimatedNodesManager.java implements a management interface for animated nodes graph as well as implements a graph traversal algorithm that is run for each animation frame. For each animation frame we visit animated nodes th
Closes https://github.com/facebook/react-native/pull/6466
Differential Revision: D3092739
Pulled By: astreet
fb-gh-sync-id: 665b49900b7367c91a93b9d8864f78fb90bb36ba
shipit-source-id: 665b49900b7367c91a93b9d8864f78fb90bb36ba
Summary: Split dispatchViewUpdates into two methods, which enables subclasses to commit pending ui operations, even when no root node is present.
Differential Revision: D3011191
fb-gh-sync-id: a3491179441223aeffe21ff483dda582053768e7
shipit-source-id: a3491179441223aeffe21ff483dda582053768e7
Summary:public
This adds the capability to get a View in absolute position on the screen, not just relative to the RootView. This is the Android implementation
Reviewed By: andreicoman11
Differential Revision: D2939170
fb-gh-sync-id: 658f1ebe6a458088f657a7469389add1a12222cd
shipit-source-id: 658f1ebe6a458088f657a7469389add1a12222cd
Summary:
Catalyst is the old project name. Rename a few files.
public
Reviewed By: bestander
Differential Revision: D2859553
fb-gh-sync-id: 65a87cc7bcc22f20326971becec02aa1c573e5b9
Summary: public This patch adds an alternative UIImplementation based on an idea of creating UI hierarchy off-the-main-thread (everything but Views), flattening ReactShadowNode hierarchy and displaying it within a single View when possible. While NativeViewHierarchyOptimizer allows removing layout-only RCTViews, this allows removing RCTView, RCTText and RCTImage.
This is an initial bare-bones implementation that doesn't really draw anything, only lays out the shadow nodes. Followup diffs will add missing features.
Reviewed By: astreet
Differential Revision: D2564309
fb-gh-sync-id: 2dda4c8cfc2bac3eb39c5c15e97bd23a57550a1d
Summary: public NativeViewHierarchyManager.createView() takes int rootViewTag which is only used to resolve ThemedReactContext, but we already have it resolved before we enqueueCreateView, so we can just pass it directly. This makes mRootViewsContext tag -> to ThemedReactContext mapping unnecessary in NativeViewHierarchyManager. Makes the class simpler.
Reviewed By: kmagiera, astreet
Differential Revision: D2460280
fb-gh-sync-id: 68c503f4fb37ca0b1dcb2abc9e0c33a5225d1f6a
Summary: public UIManagerModule should not be creating UIImplementation. Instead, UIImplementation instance should be supplied to it to allow plugging in different implementations. No functional changes.
Reviewed By: astreet
Differential Revision: D2464632
fb-gh-sync-id: e7372977c93ceb7ef5e8658e5ee7e8e87f52d851
Summary: public
We're seeing related crashes. The diff has no tests, the perf tests weren't conclusive, and the person who'd be supporting it no longer is available to work on it. We can try this again later in a less rushed manner with proper perf testing.
Reviewed By: davidaurelio
Differential Revision: D2696615
fb-gh-sync-id: 3b6814ac12af19516146d5c42d2add8321b10db5
Summary: public This diff extracts all shadow hierarchy-specific logic from UIManagerModule into a UIImplementation class. This will later allow using in alternative UIImplementations in future.
Reviewed By: astreet
Differential Revision: D2457849
fb-gh-sync-id: 532128ce1d67b525cdf03794a5a29d7e9ed0ab90
