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 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: These are helpful for development and shouldn't affect anything when DEBUG=false
Reviewed By: lexs
Differential Revision: D3515015
fbshipit-source-id: 0bd5ff833f90fea8e70b3103eb1f9bc803bef27c
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: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: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:
public
KeyboardListener needs DisplayMetrics to be initialized when it is attached. At
the moment, this breaks easily whenever we change these components, since DisplayMetrics are intialized
in a module and KeyboardListener is created eagerly in ReactRootView, whereas
ReactRootView can exist without the instance.
This changes to create DisplayMetrics as soon as possible, when the react
instance is built. The KeyboardListener is created and attached after the ReactRootView is
attached to an existing instance, point at which DisplayMetrics have to be
initialized.
Reviewed By: dmmiller
Differential Revision: D2911351
fb-gh-sync-id: 64d1805c5d5b2f6876adb694b565a2df059b381d
Summary:
The change in 8e603940e3 actually causes a super bad bug when `context.getResources().getDisplayMetrics()` is accessed in other parts of the application.
It turns out that when you dive into the impl of `getRealMetrics`, it mutates whatever `DisplayMetrics` object is passed to it. In this case, `getDisplayMetrics` ends up mutating the `DisplayMetrics` object that sits on the application context's `Resources` instance.
This PR makes that not so.
/cc jesseruder ide jaysoo bestander astreet
Closes https://github.com/facebook/react-native/pull/5764
Reviewed By: svcscm
Differential Revision: D2902386
Pulled By: androidtrunkagent
fb-gh-sync-id: 3f24b68bc7e6b4ca83808c03ef3637e1ac9a673e
Summary: public UIImplementationProvider allows plugging in an alternative UIImplementation. A follow up diff adds a toggle under FB Dev Settings and uses this class to control an implementation. This allows us experimenting with other ways of generating UI hierarchy from JavaScript components.
Reviewed By: astreet
Differential Revision: D2554774
fb-gh-sync-id: 6574a893020e3519bd2ab00b9620a6dbdfaed595
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
Summary: public There is really no reason NativeViewHierarchyManager.addRootView() should be performed synchroniously when called from background thread, as long as it is executed before every other command in UIViewOperationQueue, and we can ensure that by putting add view command at the front of the queue. When that happpens, the queue should always be empty anyway, but it's best to be safe.
This eliminates an unnecessary blocking call and should overall make the code simpler and safer (Semaphores can timeout).
Reviewed By: astreet
Differential Revision: D2462680
fb-gh-sync-id: 784ac6573a455019b93628c70992f3830b9d6f1f
Summary: public UIManageModule creates AnimationRegistry but never uses it, this diff moves it to NativeViewHierarchyManager who owns it. UIViewOperationQueue depends on AnimationRegistry to perform some of the enqueued operations, so it accessed it through a getting in NativeViewHierarchyManager. This will also make sure NativeViewHierarchyManager. and UIViewOperationQueue operate on the same AnimationManager (previously, that wasn't really enforced). This is needed so I can move away UIViewOperationQueue creation off the UIManagerModule. This diff should have no functional changes whatsoever.
Reviewed By: astreet
Differential Revision: D2462605
fb-gh-sync-id: 1e3cd64908f51126362f2b5fb39b1efa6521854e
Summary: public
Native view recycling implementation based on limited pools of views.
In this diff I introduced new UIManager method: dropViews. Instead of removing views from tag->view maps when they are detached we keep them there until we get a call to dropViews with the appropriate tag. JS may keep a pool of object and selectively decide not to enqueue drop for certain views. Then instead of removing those views it may decide to reuse tag that has been previously allocated for a view that is no longer in use.
Special handling is required for layout-only nodes as they only can transition from layout-only to non-layout-only (reverse transition hasn't been implemented). Because of that we'd loose benefits of view flattening if we decide to recycle existing non-layout-only view as a layout-only one.
This diff provides only a simple and manual method for configuring pools by calling `ReactNativeViewPool.configure` with a dict from native view name to the view count. Note that we may not want recycle all the views (e.g. when we render mapview we don't want to keep it in memory after it's detached)
Reviewed By: davidaurelio
Differential Revision: D2677289
fb-gh-sync-id: 29f44ce5b01db3ec353522af051b6a50924614a2
