Added support for corner radii in Android

[mattds]

This is a cut down version of a previous pull request with just the 4 corners catered for.

[facebook-github-bot]

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

[nicklockwood]

@mkonicek is this good-to-go?

[satya164]

@mattds Can you rebase?

[facebook-github-bot]

@mattds updated the pull request.

[mattds]

@satya164, apologies for the delay, sure, I've rebased.

[satya164]

Thanks @mattds . cc @mkonicek @nicklockwood

[facebook-github-bot]

@mattds updated the pull request.

[mattds]

It's a pleasure, I updated the pull request with a minor change to getOutline of ReactViewBackgroundDrawable - now it sets mNeedUpdatePathForBorderRadius = true only if mPathForBorderRadius == null so that the subsequent call to updatePath will only update the path if it's not set or changed.

[mkonicek]

@kmagiera Does this look OK to you?

[kmagiera]

You can perhaps use setCornersRadii(float topLeft, float topRight, float bottomRight, float bottomLeft) and this way have mBorderRadius to only store 4 floats

[kmagiera]

nit: [position * 2]

[kmagiera]

@mattds Thanks for your work on this PR. Please see my comments inline. Also do you mind adding an example to UIExplorer/BorderExample.js of a component with 2 different radii + another example with elevation?

[mattds]

@kmagiera thanks for reviewing, I will make the changes mentioned and resubmit. I see now that borderRadius will potentially overwrite corner radii as you mentioned - I think I will need to keep borderRadius around as a separate value as a default for unset corners, will revise and add the examples mentioned.

[nicklockwood]

@mattds since that's basically how subviews inside <Image> are implemented on Android anyway, I'll wager you can make that work without the extra wrapper view by just debugging the code in Image.android.js - it's probably applying the border styles to the wrong element or something.

[joelcloralt]

@mattds that works perfectly. Thank you!

[mattds]

@joelcloralt it's a pleasure :) @nicklockwood you're right, changing

var imageProps = merge(nativeProps, {
          style: styles.absoluteImage,
          children: undefined,
        });

to

var imageProps = merge(nativeProps, {
          style: flattenStyle([styles.absoluteImage, nativeProps.style.borderRadius ? {borderRadius: nativeProps.style.borderRadius} : null]),
          children: undefined,
        });

in Image.android.js seems to work without the extra view.

[brentvatne]

ping @kmagiera ;)

[kmagiera]

@joelcloralt @nicklockwood is right. On android Image component with children is implemented in JS by wrapping children in a View with Image inside of it as a first child. Therefore corner radius won't work as you may expect as on Android we don't support children clipping based on the corner radius (see the explanation here)

[kmagiera]

Do we need this check here? I think that what we should do instead is that we should set mNeedUpdatePathForBorderRadius = true in both setRadius methods to be consistent with the way how we update that property.

[kmagiera]

Thanks @mattds and sorry for the delay in review. I have just last one comment inline. Will also let @mkonicek merge this as every time I "ship" stuff, something breaks :)

[facebook-github-bot]

@mattds updated the pull request.

[mattds]

@kmagiera, no worries. I moved "mNeedUpdatePathForBorderRadius = true" to the setRadius methods, this will indeed make the check in getOutline unnecessary, thanks. I've checked in the changes. @mkonicek is this version ready to ship?

[mpretty-cyro]

@mattds Just FYI, there is a way to get something similar working on iOS by setting a layer mask (although it's performance isn't great) - https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIBezierPath_class/#//apple_ref/occ/clm/UIBezierPath/bezierPathWithRoundedRect:cornerRadius:

A better write up can be found here - http://ronnqvi.st/thinking-like-a-bzier-path/

[nicklockwood]

@mpretty-homepass this already works on iOS (using pretty-much the technique you described).

[mpretty-cyro]

@nicklockwood oh really? Is this something I can do via React Native? (Couldn't seem to find it in the docs).

I mostly mentioned it because of the comment about iOS support here - #4252 (comment)

[nicklockwood]

@mpretty-homepass yes, it's supported on iOS for everything except <Image> components, which only support equal borders and corner radii. (But you can work around that by wrapping your <Image> in another <View> with overflow:hidden).

[mkonicek]

@kmagiera do you want to take a look try shipit again? The plan is we'll make it work reliably this half :) Not sure all your comments have been addressed.

[kmagiera]

Yeah, let me try landing this. Looks good and all comments have been address. Thanks @mattds for your patience.

@facebook-github-bot shipit

[facebook-github-bot]

Thanks for importing. If you are an FB employee go to https://our.intern.facebook.com/intern/opensource/github/pull_request/535947113226769/int_phab to review.

[mpretty-cyro]

@mattds Is this meant to be working on ImageView's as well?

[mattds]

@mpretty-homepass, so this pull request is just for regular views, #5197 is for images on Android, but since the same functionality is missing on iOS, it probably won't be merged in.

[mpretty-cyro]

@mattds that's fine in iOS since you can clip child views by adding a borderRadius to their parents; but that doesn't work in Android. Which means that without this, there is no way to replicate the effect on Android.

[mpretty-cyro]

Thanks for pointing to the other PR though, will merge with our fork and use that for the time being.

[nicklockwood]

I (wrongly) assumed at the time of review that subview clipping worked on Android. Given that it doesn't, I think it's probably worth revisiting #5197 - although ideally I'd like us to get this working the same on both platforms, instead of needing separate platform-specific solutions.

[mpretty-cyro]

@nicklockwood I completely agree that ideally Android and iOS would function in the same way, but for the time being at least that would allow us to render the same elements on both platforms.