[Android] Implement addUIBlock to allow third party to resolve a view

[gre]

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.

---

With this PR a third party lib can now do...

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 the view!
  }
});

...and we can finally implement that generic view screenshot in a third party library... -> this is a gist implementing it! <-

NB: this gist will turn into a PR for @jsierles' react-native-view-snapshot library, when this gets into React Native.

[ghost]

By analyzing the blame information on this pull request, we identified @dmmiller and @korDen to be potential reviewers.

[gre]

@mkonicek @kmagiera here is finally my PR :) cheers

[christopherdro]

👍 I still vote to make the view snapshot part of core since the API for iOS has already been added.

[gre]

@christopherdro I understand the idea behind not making react-native too monolithic though.
Having snapshot in RN means one more thing to maintain and it's time consuming for the RN team where they should focus on core features. I like react-native to try to stay as minimalist as possible so they focus on "just solve React abstraction on top of Native views".
Making it possible to have third party native libraries is IMO the most important part here. Third party libraries will be easier to patch & improve (rather than having to send PR to react-native every time) AND it allows more alternative implementations, bringing better overall quality (more distributed development to the community!).

[jsierles]

@mkonicek Does FB use the snapshot code internally? If not, I volunteer to extract the missing features out to the module once this is in.

[christopherdro]

@gre I understand that approach and it makes sense to me with functionalities that do not exist in core for any of the platforms. However, I have to disagree with that if the functionality already exists for one of the platforms within core.

Unless the plan is to remove ac12f98 which I doubt is going to happen.

[gre]

@christopherdro yup agreed. APIs should eventually converge to implement same features everywhere.

[mkonicek]

Assigning to @lexs to review. Would you mind taking a look please?

[astreet]

Can you add documentation here? Maybe an example of how you'd expect it to be used?

[astreet]

Code lgtm, can you just add that documentation? I agree we should have this implemented in a single way across platforms, which would hopefully mean implementing it as a separate module in iOS as well at some point.

[gre]

@astreet I've added the doc with the description (it's the same of the iOS implementation, turns out it still make sense for the Android implementation :) ) with an Android example.

Thanks

[astreet]

Great, thanks!

@facebook-github-bot shipit

[facebook-github-bot]

Thanks for importing. If you are an FB employee go to Phabricator to review.

[gre]

@astreet @christopherdro @nicklockwood I've published third party library https://github.com/gre/react-native-view-shot that re-implement part of the takeSnapshot iOS implementation and also have the Android implementation.