Summary:
Related to [issue #5418](https://github.com/facebook/react-native/issues/5418)
This is a follow-up to [this previous pull request.](https://github.com/facebook/react-native/pull/5419)
~~Adds a new ReactProp 'urlWithHeaders' to Android WebViews that takes an object with a 'url' string and a 'headers' map.~~
[Update] Adds a new prop 'source' to Android WebViews
```
{
html: string,
url: string,
headers: map<string, string>,
}
```
Update: resolves TODO 8495359
Closes https://github.com/facebook/react-native/pull/5494
Reviewed By: svcscm
Differential Revision: D2881313
Pulled By: nicklockwood
fb-gh-sync-id: 7cad8490d4932d0a7ef559165f3ec279d873c537
Summary:
public
We recently updated the `ScrollResponder.scrollResponderScrollTo` method to accept an `animated` argument, and deprecated the `scrollResponderScrollWithoutAnimationTo` method. This change was reflected in the native iOS implementation, but not on Android.
This diff updates the Android ScrollViewManager implementation to match the JS API, and removes the platform-specific fork in the JS code.
Reviewed By: dmmiller
Differential Revision: D2883515
fb-gh-sync-id: e5a0e1cf470e21af837b2311cf1048162ac3aff5
Summary:
public
Due to the cross-platform polyfills we have added (and will add in future) to `UIManager.js`, accessing UIManager directly via NativeModules instead of importing the wrapper is discouraged.
This diff fixes a few places where we were doing this inside our own modules.
Note: As a general policy, we should avoid accessing modules via NativeModules anyway. Using wrapper classes allows us to provide static declarations for all the native methods and properties, which can be checked at build time by flow. If we access the modules directly, those interfaces are only known at runtime.
Reviewed By: vjeux
Differential Revision: D2881300
fb-gh-sync-id: 6737358ea8ea6d722cc1941a4b9fa0123a87fc29
Summary:
For my project it was required to receive a notification when the MapView annotation was deselected.
So I renamed `onAnnotationPress` to `onAnnotationSelected` and added a new method `onAnnotationDeselected`, this names was "inspired" by the underlaying iOS API. The old API was still called and marked as deprecated.
But maybe you have an idea for a better naming (onAnnotationFocus/-Blur?) -- or should a deselected call the press method again without an annotation (undefined)?
Closes https://github.com/facebook/react-native/pull/5167
Reviewed By: svcscm
Differential Revision: D2869695
Pulled By: nicklockwood
fb-gh-sync-id: 91795ac3f1e4533b250af8901534d8870729d9db
Summary:
The basic API is consistent with iOS; there are several platform-specific props.
Also fixed the flickering when a value is selected.
public
Reviewed By: bestander
Differential Revision: D2871092
fb-gh-sync-id: f5cdf6858cb7344b28ee46954cb6b0a3b144b646
Summary:
To allow smoother API changes for users we often deprecate props and keep them around for a while before removing them. Right now it is all done manually, this adds a consistent way to show a warning when using a deprecated prop.
This also adds a deprecation warning of the website generated from the deprecatedPropType.
<img width="643" alt="screen shot 2016-01-26 at 7 43 08 pm" src="https://cloud.githubusercontent.com/assets/2677334/12600172/7af28fb0-c465-11e5-85e5-3786852bf522.png">
It also changes places where we added the warnings manually to use deprecatedPropType instead.
Closes https://github.com/facebook/react-native/pull/5566
Reviewed By: svcscm
Differential Revision: D2874629
Pulled By: nicklockwood
fb-gh-sync-id: c3c63bae7bbec26cc146029abd9aa5efbe73f795
Summary:
I have an issue when combining `PullToRefreshViewAndroid` and `ViewPagerAndroid`.
`ViewPagerAndroid` will not able to scroll that gesture handler is being taken by `PullToRefreshViewAndroid`
One solution is to disable `PullToRefreshViewAndroid` if `ViewPagerAndroid` is scrolling (i.e. not idle).
[Reference solution here](http://stackoverflow.com/a/29946734/2590265)
So here need to expose the `onPageScrollStateChanged` event.
Some code referenced from DrawerLayoutAndroid, especially the `VIEWPAGER_PAGE_SCROLL_STATES` array.
Please feel free give me comments.
Thanks.
Closes https://github.com/facebook/react-native/pull/5026
Reviewed By: svcscm
Differential Revision: D2830623
Pulled By: andreicoman11
fb-gh-sync-id: c2a6920c6f4c7daab0115f13864db83b93b31abf
Summary:
Expose a `decelerationNormalEnabled` flag on WebView, which, when enabled, will WebView's ScrollView's `decelerationRate` to `UIScrollViewDecelerationRateNormal`. This gives the WebView the same "momentum" style scrolling as other iOS views.
This was discussed with ide in #5447. Please let me know if there's anything I'm missing, or anything else you'd like to see in this pull request.
Closes https://github.com/facebook/react-native/pull/5527
Reviewed By: svcscm
Differential Revision: D2870312
Pulled By: nicklockwood
fb-gh-sync-id: 7dbfd06a349e3365a5df40c3bacf25a4fdb306cf
Summary:
public
This diff improves the implementation of 3D touch by adding a `forceTouchAvailable` constant to View that can be used to check if the feature is supported.
I've also added an example of how you can use the `force` property of the touch event to measure touch pressure in React Native.
Reviewed By: vjeux
Differential Revision: D2864926
fb-gh-sync-id: 754c54989212ce4e4863716ceaba59673f0bb29d
Summary:
A promise based API for handling Link for Android and iOS. Refer #4971
The iOS part doesn't handle errors. Will need someone with iOS knowledge to do that.
cc skevy ide brentvatne mkonicek vjeux nicklockwood
Closes https://github.com/facebook/react-native/pull/5336
Reviewed By: svcscm
Differential Revision: D2866664
Pulled By: androidtrunkagent
fb-gh-sync-id: 67e68a827e6b85886bfa84e79b897f079e78b1b5
Summary:
I *think* this is causing a crash for me in a release build (curiously, not a debug build):
```
ReferenceError: Can't find variable: self
```
I saw this in 0.18.1, which I assume was renamed to v0.19.0-rc.
Closes https://github.com/facebook/react-native/pull/5562
Reviewed By: svcscm
Differential Revision: D2866491
Pulled By: androidtrunkagent
fb-gh-sync-id: 196f718bf807c5eef676f66f1e15d7bde9475d5b
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:
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:
Making the default people see when they look at the module the Promise based version
public
Reviewed By: davidaurelio
Differential Revision: D2850048
fb-gh-sync-id: e0815983ed798c202047cb071e65ce63a52fd1af
Summary:
It needs the touch coordinates for with-in the element, not for on the page.
Closes https://github.com/facebook/react-native/pull/5400
Reviewed By: svcscm
Differential Revision: D2848834
Pulled By: androidtrunkagent
fb-gh-sync-id: 88cf0fd7bd2332eb3db835b26438064412c8358c
Summary:
public
React Native currently exposes the iOS layer shadow properties more-or-less directly, however there are a number of problems with this:
1) Performance when using these properties is poor by default. That's because iOS calculates the shadow by getting the exact pixel mask of the view, including any tranlucent content, and all of its subviews, which is very CPU and GPU-intensive.
2) The iOS shadow properties do not match the syntax or semantics of the CSS box-shadow standard, and are unlikely to be possible to implement on Android.
3) We don't expose the `layer.shadowPath` property, which is crucial to getting good performance out of layer shadows.
This diff solves problem number 1) by implementing a default `shadowPath` that matches the view border for views with an opaque background. This improves the performance of shadows by optimizing for the common usage case. I've also reinstated background color propagation for views which have shadow props - this should help ensure that this best-case scenario occurs more often.
For views with an explicit transparent background, the shadow will continue to work as it did before ( `shadowPath` will be left unset, and the shadow will be derived exactly from the pixels of the view and its subviews). This is the worst-case path for performance, however, so you should avoid it unless absolutely necessary. **Support for this may be disabled by default in future, or dropped altogether.**
For translucent images, it is suggested that you bake the shadow into the image itself, or use another mechanism to pre-generate the shadow. For text shadows, you should use the textShadow properties, which work cross-platform and have much better performance.
Problem number 2) will be solved in a future diff, possibly by renaming the iOS shadowXXX properties to boxShadowXXX, and changing the syntax and semantics to match the CSS standards.
Problem number 3) is now mostly moot, since we generate the shadowPath automatically. In future, we may provide an iOS-specific prop to set the path explicitly if there's a demand for more precise control of the shadow.
Reviewed By: weicool
Differential Revision: D2827581
fb-gh-sync-id: 853aa018e1d61d5f88304c6fc1b78f9d7e739804
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:
public
This diff deprecates `scrollResponderScrollWithoutAnimationTo` and replaces it with an optional `animated` param in `scrollResponderScrollTo`. This is more consistent with our other APIs.
Using the old `ScrollResponder.scrollResponderScrollWithoutAnimationTo` or `ScrollView.scrollWithoutAnimationTo` functions will still work, but will trigger a warning.
Reviewed By: javache
Differential Revision: D2823479
fb-gh-sync-id: 259966512104ca7b3995c9586144812a91b8d3e9
Summary:
Exposes the doc for RefreshControl and add a link to the component page in ScrollView.
Closes https://github.com/facebook/react-native/pull/5209
Reviewed By: svcscm
Differential Revision: D2818217
Pulled By: mkonicek
fb-gh-sync-id: eb1ae70103e6a02af3a12866509f68eacc413dfd
Summary:
Current default value of ProgressBarAndroid's styleAttr is "Large" which sets the ProgressBar's style to [Widget_ProgressBar_Large](http://developer.android.com/reference/android/R.style.html#Widget_ProgressBar_Large) at native side. But large is not the default style for the native side ProgressBar.
For example, the size of the ProgressBar is 48dip for default style, but 76dip for large and 16dip for small as in the Material themes. Although the size of ProgressBarAndroid could be set in JS, it'll be better to have the same default style as in native side themes.
My PR adds a "Normal" value for styleAttr prop and makes it the default value.
Closes https://github.com/facebook/react-native/pull/4974
Reviewed By: svcscm
Differential Revision: D2811229
Pulled By: bestander
fb-gh-sync-id: 087f68d1919fe933d86e5194112bf7a5f5b3f3c6
Summary:
public
Add an onSelectionChange method to TextInput that works on Android same as iOS
Reviewed By: andreicoman11
Differential Revision: D2780131
fb-gh-sync-id: 9b3b8fbd9ea653d43e3107a338e4bc08bde2e8c6
Summary:
Calling navigator.replace(0, scene) has no effect.
This is because 0 is false in Javascript so when
this.state.updatingAllIndicesAtOrBeyond == 0
(meaning update all indices starting with 0)
The whole expression evaluates to 0, i.e. false -> therefore no update
happens.
Explicitly checking for not-equal to null (!= will convert undefined to null automatically) fixes the issue.
Closes https://github.com/facebook/react-native/pull/5155
Reviewed By: svcscm
Differential Revision: D2807397
Pulled By: nicklockwood
fb-gh-sync-id: 519a4ab35c86b0b608808b36593f5f8c2ecd1561
Summary:
public
Android implement ViewManager methods via a dispatch method on UIManager, whereas iOS implements them by exposing the methods on the view manager modules directly.
This diff polyfills Android's implementation on top of the iOS implementation, allowing the same JS API to be used for both.
Reviewed By: javache
Differential Revision: D2803020
fb-gh-sync-id: 0da0544e593dc936467d16ce957a77f7ca41355b
Summary:
Both iOS and Android currently support some sort of native pull to refresh control but the API was very different. I tried implementing a component based on PullToRefreshViewAndroid but that works on both platforms.
I liked the idea of wrapping the ListView or ScrollView with the PullToRefreshView component and allow styling the refresh view with platform specific props if needed. I also like the fact that 'refreshing' is a controlled prop so there is no need to keep a ref to the component or to the stopRefreshing function.
It is a pretty rough start so I'm looking for feedback and ideas to improve on the API before cleaning up everything.
On iOS we could probably deprecate the onRefreshStart property of the ScrollView and implement the native stuff in a PullToRefreshViewManager. We could then add props to customize the look of the UIRefreshControl (tintColor). We could also deprecate the Android only component and remove it later.
Closes https://github.com/facebook/react-native/pull/4915
Reviewed By: svcscm
Differential Revision: D2799246
Pulled By: nicklockwood
fb-gh-sync-id: 75872c12143ddbc05cc91900ab4612e477ca5765
Summary:
Was developing on a WebView and couldnt get it to run. Turns out its JS code mostly depends on `localStorage` and I realized it wasnt turned on in RN. This PR adds a prop, similar to `javascriptEnabledAndroid` to be able to turn DOM storage on / off.
TBH I dont really know how it works on IOS, so I created an android specific thingy. I assume DOM storage is enabled by default on IOS.
Closes https://github.com/facebook/react-native/pull/5065
Reviewed By: svcscm
Differential Revision: D2797735
Pulled By: androidtrunkagent
fb-gh-sync-id: cd60cfa4d24d80fb82e4f54f387a4517a99e75ab
Summary:
Problem: https://github.com/facebook/react-native/issues/4708
Solution: Added a ColorPropType that validates the color used by the dev
Notes:
1) I'm working a Win8.1 machine and couldn't build the react-native using the github repo. As soon as I figure that out, I'll probably figure how to run the tests and how to add some for this feature.
2) It's my first pull request. Be gentle :)
Closes https://github.com/facebook/react-native/pull/4866
Reviewed By: bestander, svcscm
Differential Revision: D2783672
Pulled By: nicklockwood
fb-gh-sync-id: ca22aa3c0999188075681b5d20fff0631496e238
Summary:
This PR adds a contentInsetStart and a contentInsetEnd property to ToolbarAndroid, allowing offsetting Toolbar contents to different keylines
Closes https://github.com/facebook/react-native/pull/4699
Reviewed By: svcscm
Differential Revision: D2759294
Pulled By: mkonicek
fb-gh-sync-id: f22aa255f07929ad7a99ac7568981d35e848065b