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:
This implements #5073. It adds a static method `PixelRatio.pixel()` which returns the smallest drawable line width, primarily for use in styles.
It also updates the example apps to use the new function.
Closes https://github.com/facebook/react-native/pull/5076
Reviewed By: svcscm
Differential Revision: D2799849
Pulled By: nicklockwood
fb-gh-sync-id: b83a77790601fe882affbf65531114e7c5cf4bdf
Summary:
This allows consumers to subclass and extend `RCTWebSocketModule` and make use of the `RCTSRWebSocketDelegate` methods.
The use case here is to do some pre-processing of WebSocket data before handing it off to JS. Consumers could that in the following way:
```
interface MyWebSocketModule : RCTWebSocketModule
end
implementation MyWebSocketModule
// Don't use RCT_EXPORT_MODULE macro for this so we replace the existing RCTWebSocketModule.
+ (NSString *)moduleName { return @"RCTWebSocketModule"; }
RCT_EXTERN_METHOD(connect:(NSURL *)URL socketID:(nonnull NSNumber *)socketID)
RCT_EXTERN_METHOD(send:(NSString *)message socketID:(nonnull NSNumber *)socketID)
RCT_EXTERN_METHOD(close:(nonnull NSNumber *)socketID)
- (void)webSocket:(RCTSRWebSocket *)webSocket didReceiveMessage:(id)message
{
[super webSocket:webSocket didReceiveMessage:[DoSomethingWith message]];
}
end
```
... and then returning a `MyWebSocketModule` ins
Closes https://github.com/facebook/react-native/pull/5321
Reviewed By: svcscm
Differential Revision: D2832374
Pulled By: nicklockwood
fb-gh-sync-id: f208516b2b2f76276223ffc972871d96afe87e27
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 was caused by the change to background color propagation, but was actually due to having an unnecessary wrapper view around the headers, which was itself a workaround for a padding bug that was fixed some time ago :-)
Reviewed By: tadeuzagallo
Differential Revision: D2830890
fb-gh-sync-id: b64e701dedb90b357ed7c463b745de021f38637b
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:
Giving routeStack in second parameter of configureScene allows to do more advanced scene configuration.
I have use-case where I can only determine the scene config from the navigation context (not only from the route object but also from where it's located).
Closes https://github.com/facebook/react-native/pull/5254
Reviewed By: svcscm
Differential Revision: D2828415
Pulled By: androidtrunkagent
fb-gh-sync-id: 27b6c79b24cbc194e080541e9202ca84c55a0bc4
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:
Currently the RCTActionSheetManager attempts to present itself from the 'rootViewController' of the key window, presenting a modal from a view controller which is already presenting a modal is not allowed on iOS and this fails with the following error appearing in the XCode debugger (but not the chrome debugger):
```
Warning: Attempt to present <UIAlertController: 0x7fca85b14f40> on <UINavigationController: 0x7fca84812000> whose view is not in the window hierarchy!
```
This change recursively looks through modally presented view controllers until it finds the top one and then uses that to present the action sheet.
Closes https://github.com/facebook/react-native/pull/5263
Reviewed By: svcscm
Differential Revision: D2823201
Pulled By: nicklockwood
fb-gh-sync-id: aad1ad88115563f633fd9aaea8e27d1d155a6c27
Summary:
brentvatne this is the pull request you requested
See issue #4886
On iOS the plist key NSLocationAlwaysUsageDescription was ignored and the location could not be retreived when using this key. Now both keys NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription are supported. If NSLocationAlwaysUsageDescription is set, NSLocationWhenInUseUsageDescription will be simply ignored according to https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW18
I read the contribution guidelines regarding the Objective-C coding standards. Hopefully my line length breaks are okay - otherwise just give me a shout and I will fix that. Didn't write any line of Objective-C before so^^
Closes https://github.com/facebook/react-native/pull/5093
Reviewed By: svcscm
Differential Revision: D2823206
Pulled By: nicklockwood
fb-gh-sync-id: dd856a18416796749025e4b32d9c72895401916d
Summary:
public
Disabling background color propagation had the unexpected effect of turning ART views black. This diff re-enabled propagation for ART views.
Reviewed By: jingc
Differential Revision: D2816402
fb-gh-sync-id: f2a4c44f3b4a16e04cbf6051391bb8fb1c0a7ed2
Summary:
I'm working on deploying haste2 with jest. This updates all the files that require changes for this to work and they are backwards compatible with the current version of jest.
* package.json was just outdated. I think haste1's liberal handling with collisions made this a "non-issue"
* env.js didn't properly set up ErrorUtils, also unsure why that isn't a problem in jest right now already?
* some things were mocking things they shouldn't
* Because of the regex that matches against providesModule and System.import, it isn't possible to list module names more than once. We have multiple tests reusing the same providesModule ids and using System.import with modules that only exist virtually within that test. Splitting up the strings makes the regexes work (we do the same kind of splitting on www sometimes if we need to) and using different providesModule names in different test files fixes the problem. I think the BundlesLayoutIntegration-test is going to be deleted, so this doesn't even matter.
public
Reviewed By: voideanvalue
Differential Revision: D2809681
fb-gh-sync-id: 8fe6ed8b5a1be28ba141e9001de143e502693281
Summary:
public
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just `<Image/>` and `<Text/>` components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except `<Text/>` nodes. It might still be useful for `<Image/>` nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
Note that this diff does not prevent you from eliminating blending on image components by manually setting an opaque background color, nor does it stop you from disabling color propagation on text components by manually setting a transparent background.
Reviewed By: javache
Differential Revision: D2811031
fb-gh-sync-id: 2eb08918c9031c582a3dd2d40e04b27a663dac82
Summary:
public
We should further improve this on the future by showing the actual stacktrace instead of the `HMRClient` one. Also, we need to integrate this with the dev plugin that opens in the default editor the file/line the user clicks on.
Reviewed By: vjeux
Differential Revision: D2798889
fb-gh-sync-id: 2392966908c493e86e11b0d024e7b68156c9066c
Summary:
An HTTP request may be redirected to another URL, sometimes we need to know the URL where the response comes from.
If the server is in control, we can add an HTTP header X-Request-URL for the redirect URL. However there will be cases that 3rd party services are used.
This PR retrieves the response URL from native networking module and passes to it XMLHttpRequest. The fetch API built on XMLHttpRequest also benefits from this feature.
Closes https://github.com/facebook/react-native/pull/4981
Reviewed By: svcscm
Differential Revision: D2811392
Pulled By: lexs
fb-gh-sync-id: 3ec356fb92f8011b6a243d6879172877a3dc498a
Summary:
Adds support for tracking unhandled rejections with `console.warn` (= yellow box).
I will create a follow-up with proper error stack formatting.
related: #4971fixes: #4045, #4142
public
{F59857438}
{F59857439}
Reviewed By: bestander
Differential Revision: D2803126
fb-gh-sync-id: 376b33e42a967675a04338cbff3ec315a77d1037
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:
This fixes a regression introduced in df70005c12
If you set navigationBar props (on Navigator) and then later set it back to null, it will crashes.
(N.B. this should be possible as navigationBar is optional)
cc satya164
Closes https://github.com/facebook/react-native/pull/4941
Reviewed By: svcscm
Differential Revision: D2788889
Pulled By: bestander
fb-gh-sync-id: f8f1cd6cc2ce13b1b1b86fa76d3b22c26a8adb5b
Summary:
Current version wasn't triggering any sound when a local notification was fired. I added the possibility to provide a custom sound and fallback to the default iOS sound if not provided.
Closes https://github.com/facebook/react-native/pull/4836
Reviewed By: svcscm
Differential Revision: D2807381
Pulled By: bestander
fb-gh-sync-id: c25e8f3c30a0714a5d9558c0c1fe344d0e93321e
Summary:
public
Attempting to load an undefined URL via XMLHttpRequest produced a confusing error deep within the network layer. This diff improves the networking stack to catch such errors earlier, and also adds a helpful error in the JS layer.
Fixes https://github.com/facebook/react-native/issues/4558
Reviewed By: javache
Differential Revision: D2811080
fb-gh-sync-id: 1837427e1080a0308f2c4f9a8a42bce2e041fb48
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:
Closes#3870
Alternatively I could make this a bool `stickyheader` that just adds `0` to the `stickyHeaderIndices` passed down to the ScrollView.
Closes https://github.com/facebook/react-native/pull/4213
Reviewed By: svcscm
Differential Revision: D2807414
Pulled By: androidtrunkagent
fb-gh-sync-id: 091b6c6c91cebe175181f57b5c2785395b5db19b
Summary:
https://github.com/facebook/react-native/issues/3679 was only partially fixed as the behaviour only works on iOS. This implements the same behaviour for Android. If the JSBundle was loaded from the assets folder, this will load images from the built-in resources. Else, load the image from the same folder as the JS bundle.
EDIT: For added clarity:
On iOS,
Bundle Location: 'file:///Path/To/Sample.app/main.bundle'
httpServerLocation: '/assets/module/a/'
Name: 'logo'
type: 'png'
**Resolved Asset location: '/Path/To/Sample.app/assets/module/a/logo.png'**
On Android,
Bundle Location: 'file:///sdcard/Path/To/main.bundle'
httpServerLocation: '/assets/module/a/',
name: 'logo'
type: 'png'
**Resolved Asset location: 'file:///sdcard/Path/To/drawable_mdpi/module_a_logo.png'**
Closes https://github.com/facebook/react-native/pull/4527
Reviewed By: svcscm
Differential Revision: D2788005
Pulled By: mkonicek
fb-gh-sync-id: 3f6462a7ee6370a92dd6727ac422c5de346c3ff1
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
Janic Duplessis
Connor McEwen
Alex Roman
Horcrux
Konstantin Raev
Kyle Corbitt
Philipp von Weitershausen
Nick Lockwood
Andrei Coman
Martín Bigio
Gaëtan Renaudeau
Eric Raio
Aleksei Androsov
Morgan Pretty
Sebastian Gronewold
Ben
Olivier Notteghem
Oleg Lokhvitsky
Martin Konicek
Christoph Pojer
Lukas Benes
realaboo
David Aurelio
Dave Miller
Lauri Lehmijoki
pecheriere
Elliot Hesp
Quentin Valmori
Ognen Ivanovski
sunnylqm
Emilio Rodriguez
Noah Jorgenson
Alex Rothberg
Geoffrey Goh
Christopher Dro
Alex Kotliarskyi
