Summary:
Modify the wrong word in the comment of NativeViewHierarchyManager.java.
Fix the explanation of the code to avoid misunderstanding.
## Changelog
[Android] [Fixed] - Fix the explanation of the code to avoid misunderstanding.
Pull Request resolved: https://github.com/facebook/react-native/pull/25235
Differential Revision: D15779249
Pulled By: cpojer
fbshipit-source-id: d4e7baa9ea9be5551feed8f643fe9774b3226bd8
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: 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:
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 are getting errors where views are being dropped twice.
This is following from logic that viewManagers are only removed from `mTagsToViewManagers` from `dropView`.
This log will hopefully identify if we are getting improper operations because we shouldn't be re-using tags
Reviewed By: mdvacca
Differential Revision: D15152869
fbshipit-source-id: 914ee9c1772fa066adefde0753075ecba6377a0c
Summary:
[General] [Fix] - Reorder operations of native view hierarchy
When we update the native view hierarchy in `manageChildren` we:
1. iterate through all views we plan to remove and remove them from the native hierarchy
2. iterate through all views we plan to add and add them to the native hierarchy
3. iterate through all views we plan to delete and delete them (remove them from memory)
This covers these cases:
a. A view is moved from one place to another -- handled by steps 1 & 2
b. A view is added -- handled by step 2
c. A view is deleted -- handled by step 1 & 3
> Note the difference between remove and delete
Everything above sounds fine! But...
The important bit:
**A view that is going to be deleted asynchronously (by a layout animation) is NOT removed in step 1. It is removed and deleted all in step 3.** See: https://fburl.com/ryxp626i
If the reader may recall we solved a similar problem in D14529038 where we introduced the `pendingIndicesToDelete` data structure to keep track of views that were marked for deletion but had not yet been deleted. An example of an order of operations that we would've solved with D14529038 is:
* we "delete" the view asynchronously (view A) in one operation
* we add a view B that shares a parent with view A in subsequent operation
* view A finally calls its callback after the animation is complete and removes itself from the native view hierarchy
A case that D14529038 would not fix:
1. we add a view B in one operation
2. we delete a view A in the same operation asynchronously because it's in a layout animation
3. ... etc.
What we must remember is that the index we use to add view B in step 1 is based on the indices assuming that all deletions are synchronous as this [comment notes](https://fburl.com/j9uillje): removals (both deletions and moveFroms) use the indices of the current order of the views and are assumed independent of each other. Whereas additions are indexed on the updated order (after deletions!)
This diff re-arranges the order in how we act upon the operations to update the native view hierarchy -- similar to how UIImplementation does its operations on the shadow tree here: https://fburl.com/j9uillje
By doing the removals and deletions first, we know that the addAt indices will be correct because either the view is removed from the native view hierarchy or `pendingIndicesToDelete` should be tracking an async delete already so the addAt index will be normalized
Reviewed By: mdvacca
Differential Revision: D15112664
fbshipit-source-id: 85d4b21211ac802183ca2f0fd28fc4437d312100
Summary:
Closes: https://github.com/facebook/react-native/issues/24016
React Native 0.57 introduced cross-platform `accessibilityRole` and `accessibilityStates` props in order to replace `accessibilityComponentType` (for android) and `accessibilityTraits` (for iOS). With #24095 `accessibilityRole` and `accessibilityStates` will increase, receiving more options, which seems to be a good moment to remove deprecated props.
Remove deprecated `accessibilityComponentType` and `accessibilityTraits` props.
[General] [Removed] - Remove accessibilityComponentType and accessibilityTraits props
Pull Request resolved: https://github.com/facebook/react-native/pull/24344
Reviewed By: rickhanlonii
Differential Revision: D14842214
Pulled By: cpojer
fbshipit-source-id: 279945e503d8a23bfee7a49d42f5db490c5f6069
Summary: Create views with props in one call instead of two. Backwards-compatible.
Reviewed By: shergin
Differential Revision: D14846424
fbshipit-source-id: cb53225579089f7e51d4e9d1fc9fc2e331a994c1
Summary:
In #20288, we solved `com.facebook.react.uimanager.NativeViewHierarchyManager.dropView (NativeViewHierarchyManager.java:536)` by adding codes that prevent to run method on `view` object when `view.getId()` is null.
But if `view` is null, `view.getId()` can make error about NullPointerException. So, I think `dropView` method needs to check if `view` is null.
If you need more information, Please read #24346.
[Android] [Fixed] - Ignore dropView method when view is null.
Pull Request resolved: https://github.com/facebook/react-native/pull/24347
Differential Revision: D14833822
Pulled By: cpojer
fbshipit-source-id: 88b6a05090ea8e8d6737c1f10b40e93649fab151
Summary: We've identified a couple of remaining issues that need to be re-tested before we can ship this more broadly.
Reviewed By: fred2028
Differential Revision: D14775730
fbshipit-source-id: 22402149066c5fbe72c36fcf7f547d63feaf5241
Summary: All animations are scheduled by the UIManager while it processes a batch of changes, so we can just wait to see what the longest animation is and cancel+reschedule the callback.
Reviewed By: mdvacca
Differential Revision: D14656733
fbshipit-source-id: 4cbbb7e741219cd43f511f2ce750c53c30e2b2ca
Summary: This code was shipped as part of the initial open-source release but was never used.
Reviewed By: sahrens
Differential Revision: D14649389
fbshipit-source-id: 0c068ca69b91d275008f4a7af77a23a4f1470c18
Summary:
Potential breaking change: The signature of ReactShadowNode's onBeforeLayout method was changed
- Before: public void onBeforeLayout()
- After: public void onBeforeLayout(NativeViewHierarchyOptimizer nativeViewHierarchyOptimizer)
Implements same feature as this iOS PR: https://github.com/facebook/react-native/pull/7304
Previously, only Text and Image could be nested within Text. Now, any view can be nested within Text. One restriction of this feature is that developers must give inline views a width and a height via the style prop.
Previously, inline Images were supported via FrescoBasedReactTextInlineImageSpan. To get support for nesting views within Text, we create one special kind of span per inline view. This span is called TextInlineViewPlaceholderSpan. It is the same size as the inline view. Its job is just to occupy space -- it doesn't render any visual. After the text is rendered, we query the Android Layout object associated with the TextView to find out where it has positioned each TextInlineViewPlaceholderSpan. We then position the views to be at those locations.
One tricky aspect of the implementation is that the Text component needs to be able to render native children (the inline views) but the Android TextView cannot have children. This is solved by having the native parent of the ReactTextView also host the inline views. Implementation-wise, this was accomplished by extending the NativeViewHierarchyOptimizer to handle this case. The optimizer now handles these cases:
- Node is not in the native tree. An ancestor must host its children.
- Node is in the native tree and it can host its own children.
- (new) Node is in the native tree but it cannot host its own children. An ancestor must host both this node and its children.
I added the `onInlineViewLayout` event which is useful for writing tests for verifying that the inline views are positioned properly.
Limitation: Clipping
----------
If Text's height/width is small such that an inline view doesn't completely fit, the inline view may still be fully visible due to hoisting (the inline view isn't actually parented to the Text which has the limited size. It is parented to an ancestor which may have a different clipping rectangle.). Prior to this change, layout-only views had a similar limitation.
Pull Request resolved: https://github.com/facebook/react-native/pull/23195
Differential Revision: D14014668
Pulled By: shergin
fbshipit-source-id: d46130f3d19cc83ac7ddf423adcc9e23988245d3
Summary:
[Android] [Fixed] - LayoutAnimations cause invalid view operations
The dating team has found a consistent repro where following an order of steps will get you the following exception:
https://lookaside.facebook.com/intern/pixelcloudnew/asset/?id=2113362972287761
The exception is due to the fact that the following operation
`delete child tag 17 from parent tag 481 which is located at index 2`
cannot be performed because parent tag 481 only has 2 children.. and they also happen to not have the tag 17 as a child. Somehow the operations and the tree they act upon are out of sync.
RN receives operations from React via the native module `UIManagerModule`. The operations use tags (an identifier for a view) and indices to determine what view is updated. These operations (grouped together as a batch) are then passed to the UI thread where we perform them on the platform views.
LayoutAnimations are implemented per batch in RN. When LayoutAnimations are on, qualified view updates are animated. Because the delete operation is animated, RN doesn't remove the view from the platform view hierarchy immediately but asynchronously -- after the animation is complete. This is problematic for other view operations that rely on an index on where to insert or delete a view because during the creation of those operations, it was assumed all prior operations were performed synchronously.
This is what was occurring in the repro and there were silent view errors occurring before the exception was thrown.
This diff proposes a solution to track all pending delete operations across operations.
We introduce a map that is keyed on view tags and has a value of a sparse array that represents child index -> count of views that are pending deletion.
`{11: [0=1], 481: [2=1]}` where this would be interpreted as for index 0 under view tag 11, there is one async view deletion that has not completed and under tag 481 there is one async view deletion at index 2.
We use the map to adjust indices on add / delete operations. We also update the count when the deletion animation is complete and remove the tag from the map when it is deleted.
Regarding worst case sizing of the map => O(# of platform views rendered)
Reviewed By: mdvacca
Differential Revision: D14529038
fbshipit-source-id: 86d8982845e25a2b23d6d89ce27852fd77dbb060
Summary: SizeMonitoringFrameLayout was used to set layout contraints on the root shadow node when the native view's size changes. Since then, we introduced ways for the root node to use proper layout contraints using the root view's measure specs, which provides more accurate constraints for the root node, so SizeMonitoringFrameLayout is no longer needed. This ends up making a lot of UIManagerModule's method signatures cleaner
Reviewed By: mdvacca
Differential Revision: D9565720
fbshipit-source-id: c569cd15991a09987cc01e89612dc9193ad99b45
Summary:
React Native's minSdkVersion is 16, or we support Android versions 16 (Jelly Bean) and above. But in the code we have many checks if Android is Jelly Bean or newer, which are unnecessary. This PR removes unnecessary Android version checks, also uses Android version names instead of numbers.
[Android] [Changes] - remove unnecessary Android version checks
Pull Request resolved: https://github.com/facebook/react-native/pull/23277
Differential Revision: D13955909
Pulled By: cpojer
fbshipit-source-id: 6b1caa5ef4fe42273d3c69a6617fff140a697b5c
Summary: It was pointed out to me in https://github.com/facebook/react-native/pull/22508 by raphael-liu that the error message refers to the wrong tag. I didn't merge the PR because I don't have good insight into the effects it could cause, but we should at least fix the error message.
Reviewed By: TheSavior
Differential Revision: D13564266
fbshipit-source-id: fa76f0888364df329d052dbcc2050f906d39dcef
Summary: If a children of a root node is being removed and the Root Node is empty, it was likely already removed and cleaned previously, likely due to a race condition caused by RN's async nature. In those cases, let's avoid crashing the app and instead silently ignore the root view removal.
Reviewed By: fkgozali
Differential Revision: D13405817
fbshipit-source-id: 0179d10a88a2d19f1db5ea35b48cb83d9d7429a6
Summary: There are cases where we're trying to drop a view that is not associated with a ViewManager. This is likely caused by race conditions that can occur if we're dropping a view from JS (when it's no longer used) but at the same time dropping it from native (when layout animation ends, when the rootview gets unmounted). In either of those cases, it should be safe to ignore the drop operation because the view was likely dropped already.
Reviewed By: mdvacca
Differential Revision: D13036643
fbshipit-source-id: 260ffb56d32a0d670ad08f449b8df165b2533195
Summary: Alternative to D10499861. If an app does not have an exception handler, context.handleException will still hard crash. Since this error is just saying that we're reusing an unexpected RootView, it might be safe to continue execution. Let's remove the exception for now while we investigate further
Reviewed By: mmmulani
Differential Revision: D10560413
fbshipit-source-id: 6c08a16cd250a019d2aef5afcaf3ba61534d29f7
Summary:
This is a bandaid fix to address a crash with a stack trace involving
```
com.facebook.react.uimanager.IllegalViewOperationException: Trying to add a root view with an explicit id already set. React Native uses the id field to track react tags and will overwrite this field. If that is fine, explicitly overwrite the id field to View.NO_ID before calling addRootView.
0+com.facebook.react.uimanager.NativeViewHierarchyManager.addRootViewGroup(NativeViewHierarchyManager.java:546) [inlined]
1+com.facebook.react.uimanager.NativeViewHierarchyManager.addRootView(NativeViewHierarchyManager.java:538) [inlined]
2+com.facebook.react.uimanager.UIViewOperationQueue.addRootView(UIViewOperationQueue.java:678) [inlined]
3+com.facebook.react.uimanager.UIImplementation.registerRootView(UIImplementation.java:216) [inlined]
4+com.facebook.react.uimanager.UIManagerModule.addRootView(UIManagerModule.java:355)
5+com.facebook.react.ReactInstanceManager.attachRootViewToInstance(ReactInstanceManager.java:1032)
6+com.facebook.react.ReactInstanceManager.attachRootView(ReactInstanceManager.java:726) [inlined]
7+com.facebook.react.ReactRootView.attachToReactInstanceManager(ReactRootView.java:524)
8+com.facebook.react.ReactRootView.startReactApplication(ReactRootView.java:377)
```
This crash seems to be happening because the root view's id is set to a non NO_ID value, but further up in the stack trace, UIManager.addRootView() is called which always sets the root view's id to NO_ID. It's not clear how this error is happening, but in this code path it's expected that addRootView should always ensure that the id is always reset. In order to avoid crashing for this, let's remove the exception and log the issue instead.
In the future, we should not be overloading the android view id field with these types of react native implementation details. The react tag should be stored as a view tag instead.
Reviewed By: mmmulani
Differential Revision: D10499861
fbshipit-source-id: 4dffedab4e7a34eee7f64bb43ec8209699521c73
Summary:
Fixes our top crash when framework try drop a view from parent, but it's a null (already removed etc.).
Fixes#20288
Pull Request resolved: https://github.com/facebook/react-native/pull/20465
Differential Revision: D10113976
Pulled By: hramos
fbshipit-source-id: 34f5654f3bdbc63eb7f7d0b5c94885576fc3cdcd
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:
/cc janicduplessis mdvacca
This addresses the same issue as #18830 which was reverted since it didn’t handle `removeClippedSubviews` properly.
When subview clipping is on, ReactViewGroup keeps track of its own children directly and accounts for the offset introduced by clipped views when calling ViewGroup methods that modify children.
Instead of accounting for just clipped children (views with no parent), it should account for any children that aren’t in the ViewGroup which also includes children that are being transitioned. If you look at the ViewGroup source code, [it explicitly retains the view parent until the transition finishes](https://github.com/aosp-mirror/platform_frameworks_base/blob/oreo-release/core/java/android/view/ViewGroup.java#L5034-L5036) which caused the `getParent()` checks to pass, even though those views should be ignored. I added a new `isChildInViewGroup` method that handles both clipped and transitioning views to fix this.
I reproduced the [earlier crash](https://github.com/facebook/react-native/pull/18830#issuecomment-382798628) by enabling clipping in [this test app](https://github.com/facebook/react-native/pull/18830#pullrequestreview-111758886) and adding a “clear views” button that resets the state to an empty items array with an animation.
- #18830
[ANDROID] [BUGFIX] [LayoutAnimation] - Removal LayoutAnimations no longer remove adjacent views as well in certain cases.
Pull Request resolved: https://github.com/facebook/react-native/pull/19775
Differential Revision: D9105838
Pulled By: hramos
fbshipit-source-id: 5ccb0957d1f46c36add960c0e4ef2a545cb03cbe
Summary:
Fixes issue #11828 that causes layout animations for removed views to
remove some adjacent views as well. This happens because the animated
views are still present in the ViewGroup, which throws off subsequent
operations that rely on view indices having updated.
This issue was addressed in #11962, which was closed in favour of a more
reliable solution that addresses the issue globally since it’s difficult
to account for animated views everywhere. janicduplessis [recommended][0]
handling the issue through ViewManager.
Since API 11, Android provides `ViewGroup#startViewTransition(View)`
that can be used to keep child views visible even if they have been
removed from the group. ViewGroup keeps an array of these views, which
is only used for drawing. Methods such as `ViewGroup#getChildCount()`
and `ViewGroup#getChildAt(int)` will ignore them.
I believe relying on these framework methods within ViewManager is the
most reliable way to solve this issue because it also works if callers
ignore ViewManager and reach into the native view indices and counts
directly.
[0]: https://github.com/facebook/react-native/pull/11962#pullrequestreview-21862640
I wrote a minimal test app that you can find here:
<https://gist.github.com/lnikkila/87f3825442a5773f17ead433a810d53f>
The expected result is that the red and green squares disappear, a blue
one appears, and the black one stays in place. iOS has this behaviour,
but Android removes the black square as well.
We can see the bug with some breakpoint logging.
Without LayoutAnimation:
```
NativeViewHierarchyOptimizer: Removing node from parent with tag 2 at index 0
NativeViewHierarchyOptimizer: Removing node from parent with tag 4 at index 1
NativeViewHierarchyManager: Removing indices [0] with tags [2]
RootViewManager: Removing child view at index 0 with tag 2
NativeViewHierarchyManager: Removing indices [1] with tags [4]
RootViewManager: Removing child view at index 1 with tag 4
```
With LayoutAnimation tag 3 gets removed when it shouldn’t be:
```
NativeViewHierarchyOptimizer: Removing node from parent with tag 2 at index 0
NativeViewHierarchyOptimizer: Removing node from parent with tag 4 at index 1
NativeViewHierarchyManager: Removing indices [0] with tags [2]
NativeViewHierarchyManager: Removing indices [1] with tags [4]
-> RootViewManager: Removing child view at index 1 with tag 3
RootViewManager: Removing child view at index 2 with tag 4
(Animation listener kicks in here)
RootViewManager: Removing child view at index 1 with tag 2
```
Here are some GIFs to compare, click to expand:
<details>
<summary><b>Current master (iOS vs Android)</b></summary>
<p></p>
<img src="https://user-images.githubusercontent.com/1291143/38695083-fbc29cd4-3e93-11e8-9150-9b8ea75b87aa.gif" height="400" /><img src="https://user-images.githubusercontent.com/1291143/38695108-06eb73a6-3e94-11e8-867a-b95d7f926ccd.gif" height="400" />
</details><p></p>
<details>
<summary><b>With this patch (iOS vs Android, fixed)</b></summary>
<p></p>
<img src="https://user-images.githubusercontent.com/1291143/38695083-fbc29cd4-3e93-11e8-9150-9b8ea75b87aa.gif" height="400" /><img src="https://user-images.githubusercontent.com/1291143/38695137-1090f782-3e94-11e8-94c8-ce33a5d7ebdb.gif" height="400" />
</details><p></p>
Previously addressed in #11962, which wasn’t merged.
Tangentially related to my other LayoutAnimation PR #18651.
No documentation changes needed.
[ANDROID] [BUGFIX] [LayoutAnimation] - Removal LayoutAnimations no longer remove adjacent views as well in certain cases.
Closes https://github.com/facebook/react-native/pull/18830
Reviewed By: achen1
Differential Revision: D7612904
Pulled By: mdvacca
fbshipit-source-id: a04cf47ab80e0e813fa043125b1f907e212b1ad4
Summary:
In native Android apps, like the YouTube app, context menus are closed when the device orientation changes.
In React Native apps instead, when having a [PopupMenu](https://developer.android.com/reference/android/widget/PopupMenu.html) open and rotating the device, the PopupMenu is not dismissed and appears in a wrong position on the screen.
This PR exposes a `dismissPopupMenu` method to allow the application to dismiss any open PopupMenu:
```(javascript)
UIManager.dismissPopupMenu()
```
Closes https://github.com/facebook/react-native/pull/15636
Differential Revision: D6837663
Pulled By: hramos
fbshipit-source-id: 7b0f4f04341129ad45c703a50897e17d93651974
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:
The showPopup method has an error callback. For some reason, it is asserting in case the wrong tagId is passed instead of calling the error callback on Android.
Pass not existing tagId to showPopup method and make sure it is receiving an error in js instead of crashing in native on Android.
[ANDROID] [MINOR] showPopup method calls error callback instead of crashing on errors.
Closes https://github.com/facebook/react-native/pull/17550
Differential Revision: D6776014
Pulled By: hramos
fbshipit-source-id: 1d97b762818d1591018fd43556eb41c3fb491eb9
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:
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
Charley
Luna Wei
Blair Vanderhoof
Joshua Gross
Estevão Lucas
landon
Pieter De Baets
Adam Comella
Dulmandakh
Christoph Nakazawa
David Vacca
Andrew Chen (Eng)
Artur Chrusciel
Héctor Ramos
Leo Nikkilä
miguelsm
Sophie Alpert
Sergei Dryganets
Aaron Chiu
Fred Liu
Janic Duplessis
ASCE1885
Ahmed El-Helw
Gaëtan Renaudeau
Olivier Notteghem
