Summary:
In Android, Fresco's default rounding corners support mode is BITMAP_ONLY which doesn't work in all cases (such as animated GIF's, some scale types, etc.).
Specifying the new "overlayColor" property on an Image will cause Fresco to switch to the other rounding corners mode, OVERLAY_COLOR, and will draw rounded corners by overlaying the solid color specified.
Fresco's behaviour is explained here: http://frescolib.org/docs/rounded-corners-and-circles.html
Closes https://github.com/facebook/react-native/pull/5366
Reviewed By: svcscm
Differential Revision: D2854696
Pulled By: mkonicek
fb-gh-sync-id: 251701ee8a64acbfc22694e9d4661c40eef75725
Summary:
public
Fix https://github.com/facebook/react-native/issues/5465
Instead of returning null when we fail to parse the Uri, just return an empty Uri which somewhat hides the problem but does prevent the crash
Reviewed By: mkonicek
Differential Revision: D2854902
fb-gh-sync-id: 71265d5e52302e174b898af5be25ac698abcf9ab
Summary:
Instead of using `UINT32_MAX` in C++ code, use `std::numeric_limits<uint32_t>::max()`. The `UINT32_MAX` macro is not available in all compilation setups
Closes https://github.com/facebook/react-native/pull/5481
Reviewed By: svcscm
Differential Revision: D2854545
Pulled By: androidtrunkagent
fb-gh-sync-id: 00a70b429c78bcf120866bb59fae2ffe6330a910
Summary:
This NPEs because the layout is null if the TextView has recently
changed. However, this also means that the TextView hasn't been laid out yet, so
the default TextView tag is correct.
public
Reviewed By: oli
Differential Revision: D2848412
fb-gh-sync-id: 5faf793d17f50283c153dc0d43fb717e8764cb7d
Summary:
public
This adds the ability to load “unbundles” in RN android apps. Unbundles are created by invoking the packager with the `unbundle` command rather than `bundle`.
The code detects usage of an “unbundle” by checking for the existence of a specific asset.
Reviewed By: astreet
Differential Revision: D2739596
fb-gh-sync-id: d0813c003fe0fa7b47798b970f56707079bfa5d7
Summary:
change `setTextAlign` and `setTextAlignVertical` to receive argument of type `String` (the same as in `StyleSheet`), so that native props and stylesheet props are calling the same ReactMethod
- add demo (may not be necessary)
Closes https://github.com/facebook/react-native/pull/4481
Reviewed By: svcscm
Differential Revision: D2823456
Pulled By: mkonicek
fb-gh-sync-id: 349d17549f419b5bdc001d70b583423ade06bfe8
Summary:
public
This is the first module moving to the new model of working with Promises.
We now warn on uses of callback version. At some point we will remove that.
Reviewed By: davidaurelio
Differential Revision: D2849811
fb-gh-sync-id: 8a31924cc2b438efc58f3ad22d5f27c273563472
Summary:
this helps with cleaning up some tests
public
Reviewed By: astreet
Differential Revision: D2816285
fb-gh-sync-id: 37c4da7bdb3c8b5439184316bb5a8939160b40a3
Summary:
Adds back support for initial props in ReactAndroid while maintaining the abstraction benefits of having the details of ReactActivity abstracted from the end user's MainActivity. This does remove the need for ReactRootView's two paramater version of the overloaded startReactApplication as far as I can tell but I wasn't sure if anyone might be using that method internally.
Closes https://github.com/facebook/react-native/pull/5384
Reviewed By: svcscm
Differential Revision: D2841602
Pulled By: androidtrunkagent
fb-gh-sync-id: 07e0937bbbdb3ac1585aa252e2fd0f3736690898
Summary:
public
Promises are coming. And as part of it, we are standardizing the error objects that will be returned. This puts the code in place on the Android side to always send the proper error format.
It will be an error object like this
`{
code : "E_SOME_ERROR_CODE_DEFINED_BY_MODULE", // Meant to be machine parseable
message : "Human readable message",
nativeError : {} // Some representation of the underlying error (Exception or NSError) , still figuring out exactly, but hopefully something with stack info
}`
Reviewed By: davidaurelio
Differential Revision: D2839927
fb-gh-sync-id: 08f1ce79af24d70357b9957f14471a12627dcffa
Summary:
In Android, when displaying an image with local uri, react-native seems to fail to rotate it according to Exif.
Images on iOS seem like they are being rotated, so this does not seem like a consistent behaviour.
For instance, when taking a picture on a Samsung Galaxy S6, and displaying it with code like below, image does not have a correct orientation.
```javascript
<Image source={{uri: "file:/storage/emulated/0/DCIM/Camera/20160106_171628.jpg"}} />
```
<img src="https://cloud.githubusercontent.com/assets/4534323/12403776/aa5075cc-be36-11e5-885a-7be8236a7fdd.jpg" width=200 />
As seen [here](http://frescolib.org/docs/resizing-rotating.html#auto-rotation), Fresco can do all the work for us (hence this very simple PR).
I tested it on Samsung Galaxy S6 (lollipop), Galaxy S4 (kitkat) and Moto X Style (marshmallow).
I have written an example that fetches images uri from the Java side and then display them in a list view.
[Here](https://github.com/Almouro/rn-camera-roll/tree/use-react-native-master
Closes https://github.com/facebook/react-native/pull/5386
Reviewed By: svcscm
Differential Revision: D2839551
Pulled By: androidtrunkagent
fb-gh-sync-id: 6f0f2f301f263fd142dfbeba6a53f8c482fb5cb0
Summary:
Opening this in a separate PR but the discussion can be viewed on #4832.
Basically, this is a native implementation and is a bit more elegant. The consensus on my previous PR was that it should be done natively rather than in JS.
There's now no maximum valid timeout value and a timeout of 0 will never time out.
ontimeout isn't implemented (yet) in this PR.
cc nicklockwood ide philikon
Closes https://github.com/facebook/react-native/pull/5038
Reviewed By: svcscm
Differential Revision: D2838743
Pulled By: nicklockwood
fb-gh-sync-id: 774f864ac35082bf522f7665f4311bd3affbe82c
Summary:
Moved setElevation from ReactViewManager to BaseViewManager. This allows
setting elevation on any type of view such as Toolbar for exemple.
Closes https://github.com/facebook/react-native/pull/5292
Reviewed By: svcscm
Differential Revision: D2837415
Pulled By: androidtrunkagent
fb-gh-sync-id: a5aa7abd95b99303d312cd9c2414539335540925
Summary:
With the numeric keyboard now being an actual numeric keyboard (before
it was actually phone-pad), we need a proper phone-pad keyboard as well.
public
Reviewed By: dmmiller
Differential Revision: D2830707
fb-gh-sync-id: 80a1d314eac730e691de73a31342c014a2fa5ba6
Summary:
The offset is cached so it doesn't need to calculate the entire height on each scroll, but the cached value was being thrown away when you scroll up -- this fixes that. Found this because it was breaking an infinite scroll view that depended on the contentOffset.y value reported from onScroll.
Closes https://github.com/facebook/react-native/pull/5278
Reviewed By: svcscm
Differential Revision: D2827556
Pulled By: dmmiller
fb-gh-sync-id: 0897b89de427cada7389113991444f57c970f980
Summary:
When class A declares a ReactProp method foo() and class B that extends from A overrides foo(), it loses the annotation so it has to be duplicated. To allow "inheriting" annotation on Override, we need to scan parent class methods for annotation as well. This diff implements the required logic.
public
Reviewed By: dkoroskin
Differential Revision: D2818278
fb-gh-sync-id: 7e9ae728cc70ce2345db7bc48b3857a0e91c4ca3
Summary: public Switch over a String is essentially a switch(string.hashCode()) and it is faster than a HashMap lookup. It also doesn't use extra memory, and doesn't require static initialization (startup penalty). Plus I believe this way the generated code looks more readable.
Reviewed By: lexs
Differential Revision: D2818223
fb-gh-sync-id: d9100ec0f8ad556c347681cbe1433d066076d3e5
Summary:
public
Since we don't use BUCK in OSS, we also have to update the Android.mk files :(
Reviewed By: bestander
Differential Revision: D2823434
fb-gh-sync-id: 4feef307f8f158653ef8e76d72447d79f47c329a
Summary:
public
Adds a simple integration test that verifies that a message can be posted to/from the worker andthat it's torn down properly.
Reviewed By: lexs
Differential Revision: D2815244
fb-gh-sync-id: 00c0d8933d785b2913d378c0589b2fbabf0d0edb
Summary:
public
Previously we did no cleanup when the executor was torn down and didn't expose a way to tear down the worker from JS. Now we do.
Termination happens synchronously and waits the the worker's MessageQueueThread to finish and join.
Reviewed By: mhorowitz
Differential Revision: D2815240
fb-gh-sync-id: 786beb30d4d64556586b91727f32e379c667a965
Summary:
public
I wasn't obeying the web workers API correctly: I had missed that the message isn't sent directly but is attached to a message object in a data field.
Reviewed By: lexs
Differential Revision: D2811247
fb-gh-sync-id: 8e51414766e0cfe382ee9bdde8f0d66e269cb83a
Summary:
public
Implements a basic WebWorkers API that allows posting messages between the main JS thread and a worker background thread. It follows the existing webworkers API from JS. Currently passed memory needs to be JSON serializable and is copied (unfortunately, this is what webkit does as well, but with a more advanced serialization/deserialization process).
There are a lot of TODO's: I'll add tasks for them once this is accepted.
Reviewed By: lexs
Differential Revision: D2779349
fb-gh-sync-id: 8ed04c115d36acf0264ef1f6a12a65dd0c14ff18
Summary:
public
Adds a fbjni API similar to JNativeRunnable so that you can post ##std::function<void()>## to MessageQueueThreads.
Reviewed By: lexs
Differential Revision: D2779094
fb-gh-sync-id: 8f873fc93fb6b817268e9422c0b6f85c3e453676