Summary:
**Motivation**: Arc drawing has been broken on Android for some time. dgladkov submitted a PR, which ended up having a bug and was never merged. This PR should fix that bug as well as provide screenshots to prove it works.
**Reproducing the Bug:** dgladkov made a simple test app which helps to illustrate the bug. The repo can be found [here](https://github.com/dgladkov/RNArtArcDrawingBug). The demo app illustrates that on iOS, wedges are drawn correctly, but Android only draws full circles. [Direct Link to iOS Before](https://github.com/dgladkov/RNArtArcDrawingBug/blob/master/images/ios.png). [Direct Link to Android Before](https://github.com/dgladkov/RNArtArcDrawingBug/blob/master/images/android.png).
**Proof The Bug is Fixed:** [Here is a direct link to Android After pic.](http://i.imgur.com/9dTU2Xn.png) You can see the wedges match the iOS Before screenshot.
**What went wrong:** dgladkov's solution relied on Java's modulus, which in fact, implements modulus in a non-standard way. Modulus should a
Closes https://github.com/facebook/react-native/pull/7049
Differential Revision: D3234404
Pulled By: spicyj
fb-gh-sync-id: 4974b818dc49d9d16f2483c49b462c459a8bb479
fbshipit-source-id: 4974b818dc49d9d16f2483c49b462c459a8bb479
Summary:
event-target-shim versions before 1.1.0 do not support taking an array for `EventTarget`. react-native requires `^1.0.5`, so this fixes compatibility with those earlier versions.
**Test Plan:** ran WebSocket UIExplorer example with earlier version of event-target-shim.
Closes https://github.com/facebook/react-native/pull/7261
Differential Revision: D3230881
Pulled By: martinbigio
fb-gh-sync-id: 6a22d58841a4b401a200fece64d13a70043fb09a
fbshipit-source-id: 6a22d58841a4b401a200fece64d13a70043fb09a
Summary: When the ModalHostView is added as a child of whatever view holds it, if accessibility is turned on, Android will walk up to the root and then walk all children of the child and verify that they are indeed children of the root. Since ModalHostView actually adds its children to a new ReactDialogViewGroup which has the Dialog as a parent, there is a disagreement about the tree deep in the bowels of View when it performs that walk. The trick is to stop from adding the children of the ModalHostView when walking for accessibility. The accessibility of those children views are properly handled by the hosting Dialog.
Reviewed By: andreicoman11
Differential Revision: D3230033
fb-gh-sync-id: 1e5ac334c996b1d5f50c75ded60805d8b871477a
fbshipit-source-id: 1e5ac334c996b1d5f50c75ded60805d8b871477a
Summary:
This avoids requiring things that may never be used at all by the application such as WebSocket or Geolocation. It also stops us from asking for native modules
before we actually start the application enabling us to potentially be more lazy in the future.
Reviewed By: davidaurelio
Differential Revision: D3212802
fb-gh-sync-id: 70cf0d1a85f39fedc47758e5eb5df789a511bc9b
fbshipit-source-id: 70cf0d1a85f39fedc47758e5eb5df789a511bc9b
Summary:
Now that we support initializing the bridge off the main thread, some of the assumptions in the bridge setup process are no longer safe.
In particular we were assuming that the JS executor and injected modules could always be synchronously initialized within bridge init, but that is only safe if those modules don't need to be set up on the main thread.
The setup for those modules was sync-dispatching to the main thread if bridge init happened on a background thread, and this lead to a deadlock under certain circumstances.
Reviewed By: javache
Differential Revision: D3224162
fb-gh-sync-id: 7319b70f541a46ef932cfe4f776e7e192f3ce1e8
fbshipit-source-id: 7319b70f541a46ef932cfe4f776e7e192f3ce1e8
Summary:
This only works for the new cxx bridge (hopefully open sourcing soon!).
This diff allows Java native modules to expose synchronous hooks to JS via the ReactSyncHook annotation. The methods will appear in JS on the native module object (e.g. you would do `require('UIManager').mySyncHook('foo');`) which allows us to enforce that required native modules are installed at build time. In order to support remote debugging, both the args and return type must be JSON serializable (so that we can go back across to the device to resolve synchronous hooks).
Follow ups will be integration tests, adding support for return types besides void, and adding support for remote debugging.
Reviewed By: mhorowitz
Differential Revision: D3218794
fb-gh-sync-id: 7e3366a8254276f5a55eb806287419287ca9182b
fbshipit-source-id: 7e3366a8254276f5a55eb806287419287ca9182b
Summary:
IIRC we made `wrong-react-native` to warn people in case they installed `react-native` globally (instead of `react-native-cli` what the guide suggests). To do that we added `bin` entry to React Native's `package.json` that points to `local-cli/wrong-react-native.js`
However, this means that if we have a project that uses `react-native` package and has call to `react-native` CLI inside its package.json, npm will execute *local* override (which just prints a confusing in this context error message).
In fact, the template we generate with `react-native init` has `react-native start` as `start` script, which makes it useless. Let's fix it by making `wrong-react-native` script smarter – it can detect that it has been executed from local `node_modules` and run the actual CLI.
cc vjeux ide
Closes https://github.com/facebook/react-native/pull/7243
Differential Revision: D3226645
Pulled By: frantic
fb-gh-sync-id: be094eb0e70e491da4ebefc2abf11cff56c4c5b7
fbshipit-source-id: be094eb0e70e491da4ebefc2abf11cff56c4c5b7
Summary: Creating a view instance just to get the default view size is quite expensive, and affects startup time for the bridge as it must be done on the main thread. I've removed these cases and simply hard-coded the sizes in the JS file. This will need to be updated if the view sizes ever change, but in practice that's very unlikely.
Reviewed By: javache
Differential Revision: D3218917
fb-gh-sync-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
fbshipit-source-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
Summary:
This is a documentation-only change: currently the docs imply that nested text formatting only works on iOS (via `NSAttributedString`). But the code (and my tests!) indicate it also works fine on Android via `SpannableString`, so clarify this in the documentation for the `Text` component.
Closes https://github.com/facebook/react-native/pull/7215
Differential Revision: D3223732
fb-gh-sync-id: 4e796e493ba6c48f05b812a12761ddb3851e06e1
fbshipit-source-id: 4e796e493ba6c48f05b812a12761ddb3851e06e1
Summary:
Previously, `InteractionManager` was baked in at the lowest level to all touches via `ResponderEventPlugin`,
which meant that any time a finger was touching the screen, `InteractionManager` would be locked. This included while
doing 100% native scrolls, and thus would block progress from Relay, Incremental, or anything else scheduling events
through `InteractionManager`.
This diff switches to only bake it into `PanResponder` (and it remains hooked into `Animated` as before) which are the
main two cases where we need 60fps JS execution and want to queue up slower tasks.
This is done with a reusable higher-order-responder `InteractionManager.createResponderClass`.
Depends on FYI https://github.com/facebook/react/pull/6587, https://github.com/facebook/react/pull/6584
Reviewed By: sebmarkbage
Differential Revision: D3210951
fb-gh-sync-id: 682d21ac5cff704673b63d5942a903a3d8912835
fbshipit-source-id: 682d21ac5cff704673b63d5942a903a3d8912835
Summary:
Kudos to frantic for this amazing idea! Works really well (yet so simple!)
Basically we had a discussion with vjeux and frantic and others in the PR #7033 how to handle platform-specific stylesheets in a similar to F8 app way.
There were quite a few nice ideas there, however that one seems to be the smallest yet the most powerful.
Basically there's a `Platform.select` method that given an object, will select a `obj[Platform.OS]` value.
It works with styles:
`Platform.select({ ios: {}, android: {} })`
with messages:
`<Text>{Platform.select({ ios: 'Check the App Store', android: 'Check Google Play' })}</Text>`
and also works well with components (similar to Wallmart idea of <PlatformSwitch />) - relevant example included in diff.
Closes https://github.com/facebook/react-native/pull/7220
Differential Revision: D3221709
Pulled By: vjeux
fb-gh-sync-id: 0a50071f2dcf2273198bc6e2c36e19bca97d7be9
fbshipit-source-id: 0a50071f2dcf2273198bc6e2c36e19bca97d7be9
Summary:
The initial layout used to render scenes does not contain the actual
width and height measured and causes the issue as described at
https://github.com/ericvicenti/navigation-rfc/issues/61
The fix is to update the layout and re-render scenes once layout
is modified. Also scenes renderer should also consider the case that
when the layout is not measured yet.
Reviewed By: ericvicenti
Differential Revision: D3203245
fb-gh-sync-id: 4de89b9b43bc993d7c970c831458bd31c094073e
fbshipit-source-id: 4de89b9b43bc993d7c970c831458bd31c094073e
Summary:HMR e2e test red-screened because of the wrong path to react.
**Test plan (required)**
Make sure e2e tests pass
Closes https://github.com/facebook/react-native/pull/7209
Reviewed By: mkonicek
Differential Revision: D3218896
Pulled By: bestander
fb-gh-sync-id: 8c5c4ceda34bd2d273e9de16ed670592d1fde3b9
fbshipit-source-id: 8c5c4ceda34bd2d273e9de16ed670592d1fde3b9
Summary:Implemented smarter retries for e2e tests
E2e tests consist of two expensive and flaky steps: npm installation and tests execution.
Our CI is configured to retry a command 3 times before terminating the test.
In current setup if one of the steps fail the whole test is restarted.
This change adds ad-hoc ability to retry flaky bits of e2e script independently.
This will make tests fail faster when code gets broken while increasing the chances to succeed in case of random false errors.
Closes https://github.com/facebook/react-native/pull/7184
Differential Revision: D3218927
fb-gh-sync-id: 9be8343484bb28aa3601b651db70fc55aa840e61
fbshipit-source-id: 9be8343484bb28aa3601b651db70fc55aa840e61
Summary:Needs to be published to npm and version be updated in RN
Closes https://github.com/facebook/react-native/pull/7208
Differential Revision: D3218870
Pulled By: davidaurelio
fb-gh-sync-id: 1caac6eb79be16f2e3ed230f413835341c7291dc
fbshipit-source-id: 1caac6eb79be16f2e3ed230f413835341c7291dc
Summary: To prevent layout popping, when inserting images inside text we would render a blank placeholder image while the real image was loading. It turns out that this isn't necessary, as we can just specify the size of the image without having an actual image to display.
Reviewed By: javache
Differential Revision: D3212766
fb-gh-sync-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
fbshipit-source-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
Summary:This adds support for delete view animations in LayoutAnimation for iOS. It supports the same properties as the create animation (alpha, scale).
This allows making simple animations when removing a view which is normally hard to do in React since we need to not remove the view node immediately.
**Test plan**
Tested add/removing views in the UIExample explorer with and without setting a LayoutAnimation. Also tested that the completion callback still works properly. Tested that user interation during the animation is properly disabled.
![layout-anim2](https://cloud.githubusercontent.com/assets/2677334/14595471/86fb1654-050d-11e6-8b38-fe45cc2dcd71.gif)
I also plan to work on improving the doc for LayoutAnimation as well as making this PR for android too.
Closes https://github.com/facebook/react-native/pull/6779
Differential Revision: D3215525
Pulled By: sahrens
fb-gh-sync-id: 526120acd371c8d1af433e8f199cfed336183775
fbshipit-source-id: 526120acd371c8d1af433e8f199cfed336183775
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: AaaChiuuu
fb-gh-sync-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
fbshipit-source-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
Summary:Fixes #5408 as per ide and vjeux suggestions here https://github.com/facebook/react-native/issues/529#issuecomment-107328799
Could've been probably done in a single `if` clause, but this is more explicit and leaves potential place for future implementation (if we ever decide to do so)
Closes https://github.com/facebook/react-native/pull/7197
Differential Revision: D3217740
Pulled By: vjeux
fb-gh-sync-id: aa08a5c42e43c1abe17b72a424ee96146f2667f6
fbshipit-source-id: aa08a5c42e43c1abe17b72a424ee96146f2667f6
Summary:Add Kiwiship app to showcase page.
Kiwiship app is powered purely by RN and currently available on iOS platform.
Closes https://github.com/facebook/react-native/pull/7169
Differential Revision: D3217526
fb-gh-sync-id: beeaa8453cfcb53bd6c4ffab02b7d827798f42e4
fbshipit-source-id: beeaa8453cfcb53bd6c4ffab02b7d827798f42e4
Summary:Fixes #6735
On font sizes smaller than 20, iOS will swap SystemFont to SF version optimised for smaller sizes which does not have ultralight and thin. That results in ultralight and light example to be rendered with the same weight.
Bumping to `20` makes it render differently as per below screenshot https://cloud.githubusercontent.com/assets/2464966/14622260/0789e500-05c9-11e6-920a-8c948a5b79b4.png
Closes https://github.com/facebook/react-native/pull/7044
Differential Revision: D3212565
Pulled By: mkonicek
fb-gh-sync-id: 5ffad136c7f4126c271366640c89673f30a99218
fbshipit-source-id: 5ffad136c7f4126c271366640c89673f30a99218
Summary:Fixes #5855
Tested with `UIExplorer`, first <Text> is the `onPress`, second is the `onLongPress`.
Closes https://github.com/facebook/react-native/pull/7099
Differential Revision: D3212436
Pulled By: mkonicek
fb-gh-sync-id: 0a1cbcd4eaf39ad4fe67d861c3be2e042e1acb27
fbshipit-source-id: 0a1cbcd4eaf39ad4fe67d861c3be2e042e1acb27
Summary:vjeux spicyj this fixes website generation because these API are now in React.
I would refer React file but it seems fragile because it is a thirdparty dependency now.
How do we document thirdparty API?
Closes https://github.com/facebook/react-native/pull/7163
Differential Revision: D3216771
fb-gh-sync-id: b0653a0bbe0f84dc509f74d185f494ac343405a8
fbshipit-source-id: b0653a0bbe0f84dc509f74d185f494ac343405a8