Summary:
Following the PR https://github.com/facebook/react-native/pull/6195, this adds a `HEIGHT` constant on `StatusBar` for iOS.
Combined with `statusBarFrameDidChange` and `statusBarFrameWillChange` StatusBar native events, it solves various problems with In-Call cellar bar / Location bar / others 40pt status bars, and offers a correct `keyboardVerticalOffset` value for the KeyboardAvoidingView component.
Closes https://github.com/facebook/react-native/pull/12041
Differential Revision: D4450924
Pulled By: hramos
fbshipit-source-id: 664798260f4226140f3fa3f9222a415a305d0d78
Summary:
Add one more parameter which can specify the keyboard type of first text input(if exists) to AlertIOS.prompt().
Example usage:
`AlertIOS.prompt('Type a phone number', null, null, 'plain-text', undefined, 'phone-pad')`
Closes https://github.com/facebook/react-native/pull/8781
Differential Revision: D4437900
Pulled By: hramos
fbshipit-source-id: 8141cc0d7c70d13603cd5a1d5ea3f1ab1ce437a6
Summary: Switch to using IS_TESTING on the Platform module. While IS_TESTING has to be explicitly set in the test harness, this makes it more usable and stops people from relying on brittle variables in the (larger) environment.
Reviewed By: fkgozali
Differential Revision: D4423661
fbshipit-source-id: 27a80867778b9374bcba67b69f9c93d32c0a74b0
Summary:
In the context of an app an image exists in three resolutions on the server: `thumb` (30px) `feed` (300px) `full` (900px). When looking at an individual item a user can come either from the feed, via a permalink or from other parts of the app. This allows a situation where the `feed` image might or might not already be loaded somewhere in the app. In the detail view I want to render `thumb` with a blur (to quickly display something), then the `feed` image if it exists to have something decent to display until `full` loads. However it is quite a waste to load the `feed` image if it isn't already in cache, and will slow down the time until `full` is loaded. It is possible to track the navigation from feed->detail and that the `feed` image has actually completed loading by the feed component however as component hierarchies grow this turns into quite a lot of prop passing and bad separation of concerns.
NSURLRequests accepts a [Cache Policy](https://developer.apple.com/reference/fo
Closes https://github.com/facebook/react-native/pull/10844
Differential Revision: D4425959
Pulled By: lacker
fbshipit-source-id: 679835439c761a2fc894f56eb6d744c036cf0b49
Summary:
**Motivation**
This finishes the job of #11817, removing the previously deprecated method. See https://github.com/facebook/react-native/issues/11736 for more context.
**Test plan**
There were no tests for this method, and I searched the whole project to make sure we weren't relying on it anywhere.
Closes https://github.com/facebook/react-native/pull/11854
Differential Revision: D4421671
Pulled By: javache
fbshipit-source-id: 67e0db8d3c594ad3ccd6ccdae08f8ce49ddb8a34
Summary:
Right now from JS there's no way to see the environment variables or arguments that the application was started with.
The main use case for this is to help enable/disable features when being run in a testing environment (as environment variables are the easiest way to communicate).
javache is it okay to reference these constants from JS at startup time? I am planning to disable yellow boxes via an environment variable.
achen1 how easy is it expose these two things for Android as well?
Reviewed By: achen1
Differential Revision: D4395091
fbshipit-source-id: fc318e6a60b8829f7eb4491ea8f3258f68f59c8c
Summary:
Currently a build warning is thrown by `if (header.BCVersion != runtimeBCVersion) ...` because `runtimeBCVersion` is signed, apparently because `-1` is used to mean that the runtime has no support for bytecode bundles.
This PR splits out the error case of the runtime not supporting BC bundles from the case of a version mismatch.
Tested as much as I could by building and running `UIExplorer` - I haven't attempted to use real bytecode bundles.
Closes https://github.com/facebook/react-native/pull/11806
Differential Revision: D4408608
fbshipit-source-id: a1d868bb2064588e6a20827692629a46b6ba1e74
Summary:
As per janicduplessis recommendation, provide a new synchronous method to replace the necessary synchronous calls and use a warning in the comments (and method name).
**Motivation**
There are currently a number of XCode warnings that show up in a fresh 0.40 install of a react native project. While the project can still be run, this contributes negatively to the development experience -- valid warnings may be ignored and new ones may be added as per https://en.wikipedia.org/wiki/Broken_windows_theory
This addresses one of the warnings, by providing the functionality of a deprecated method in two specific cases where we can't avoid doing synchronous work on the main queue. See https://github.com/facebook/react-native/issues/11736 for more context.
**Test plan (required)**
I ran a project that relied on screen size and it didn't crash...happy to do more involved testing if someone can share better methodology.
Closes https://github.com/facebook/react-native/pull/11817
Differential Revision: D4402911
fbshipit-source-id: 9fd8b3f50d34984b765fe22b1f4512e103ba55a9
Summary:
Fixes the build warning:
```react-native/React/Modules/RCTRedBox.m:406:58: Conversion from value of type 'NSArray<RCTJSStackFrame *> *' to incompatible type 'NSArray<NSDictionary *> *```
This appears because the compiler is left to infer the type of `stack`, and it does so as `NSArray<RCTJSStackFrame *>` based on [RCTRedBox.m#L390](https://github.com/facebook/react-native/blob/master/React/Modules/RCTRedBox.m#L390). In reality `stack` may be either of two types and the function body deals with normalisation.
Mark the stack as explicitly `NSArray<id>` to prevent inference so we're free to make the decision to cast to more specific types.
Closes https://github.com/facebook/react-native/pull/11807
Differential Revision: D4402916
fbshipit-source-id: 356343f244af7638b9b9e91c2c5b7e68de0cbd33
Summary:
`UIActivityViewConroller.completionHandler` has been [deprecated](https://developer.apple.com/reference/uikit/uiactivityviewcontroller/1622010-completionhandler) since iOS 8, when it was replaced by `completionWithItemsHandler`.
Tested the build using `UIExplorer` and XCode 8.2 but I've never seen and can't work out how to activate the `UIActivityViewController` this method relates to, so I haven't tested a real run.
Closes https://github.com/facebook/react-native/pull/11798
Differential Revision: D4396618
fbshipit-source-id: 92a993c434637ede2d5779f4154feb00d2c78d06
Summary:
Motivation: reduce build noise that might worry new users or hide real problems.
This deals with four of the warnings currently in the iOS build. The `__unused` additions are standard and self-explanatory, following the style used elsewhere in RN. I've used `#pragma unused` to deal with parameters named by macros.
Tested by building and running the `UIExplorer` example app in XCode 8.2
Closes https://github.com/facebook/react-native/pull/11797
Differential Revision: D4396611
fbshipit-source-id: 728e9ebb94d147f7a2cbc674a25fe67e66e2e8b2
Summary:
Currently, < WebView > allows you to pass JS to execute within the view. This works great, but there currently is not a way to execute JS after the page is loaded. We needed this for our app.
We noticed that the WebView had messaging support added (see #9762) . Initially, this seemed like more than enough functionality for our use case - just write a function that's injected on initial load that accepts a message with JS, and `eval()` it. However, this broke once we realized that Content Security Policy can block the use of eval on pages. The native methods iOS provide to inject JS allow you to inject JS without CSP interfering. So, we just wrapped the native methods on iOS (and later Android) and it worked for our use case. The method injectJavaScript was born.
Now, after I wrote this code, I realized that #8798 exists and hadn't been merged because of a lack of tests. I commend what was done in #8798 as it sorely solves a problem (injecting JS after the initial load) and has more features than what I'
Closes https://github.com/facebook/react-native/pull/11358
Differential Revision: D4390425
fbshipit-source-id: 02813127f8cf60fd84229cb26eeea7f8922d03b3
Summary:
Strangely comparing a pointer with zero will only be a clang warning when compiling with `-Wpedantic`, so this incorrect comparison is silently allowed.
**Test plan**
Compiles with `-Wpedantic`.
Closes https://github.com/facebook/react-native/pull/11709
Differential Revision: D4377512
Pulled By: ericvicenti
fbshipit-source-id: 483cf1f41d3f539c452d542ad2155c4c4b41616d
Summary:
Adds the feature to use percentage as a value unit.
You can use the function ```YGPx(float)``` and ```YGPercent(float)``` for convenience.
I did some benchmarks:
```
Without Percentage Feature - Release x86:
Stack with flex: median: 0.000000 ms, stddev: 0.146683 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.490101 ms
Huge nested layout: median: 23.000000 ms, stddev: 0.928291 ms
Stack with flex: median: 0.000000 ms, stddev: 0.170587 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.143384 ms
Nested flex: median: 0.000000 ms, stddev: 0.477791 ms
Huge nested layout: median: 22.000000 ms, stddev: 2.129779 ms
With Percentage Feature - Release x86:
Stack with flex: median: 0.000000 ms, stddev: 0.132951 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.489570 ms
Huge nested layout: median: 21.000000 ms, stddev: 1.390476 ms
Closes https://github.com/facebook/yoga/pull/258
Reviewed By: dshahidehpour
Differential Revision: D4361945
Pulled By: emilsjolander
fbshipit-source-id: a8f5bc63ad352eb9410d792729e56664468cd76a
Summary:
**Motivation**
After reviewing changes between my PR https://github.com/facebook/react-native/pull/10427 and what was eventually manually imported to master, found two minor adjustments needed.
**Test plan**
Existing tests should still pass.
Closes https://github.com/facebook/react-native/pull/11548
Differential Revision: D4357216
Pulled By: javache
fbshipit-source-id: 571794cda104210bf5236462c0700e07a2a51d29
Summary:
On certain devices (in my case, any iPad Pro model), listening to `DeviceEventEmitter.didUpdateDimensions` would call back *before* the interface change takes places (i.e. calling `Dimensions.get()` in this callback would return wrong values). Turns out that we were listening for the wrong native event.
Edit to add: now using `[RCTSharedApplication() statusBarOrientation]` to get the current orientation. Not yet sure why, but the `userInfo` provided by the notification was returning the wrong orientation *only* on the first time you rotate the device.
This fixes the open issue: https://github.com/facebook/react-native/issues/7340
Closes https://github.com/facebook/react-native/pull/11350
Differential Revision: D4348186
Pulled By: javache
fbshipit-source-id: cb2cfb9cccfc459ad4b46a5af2bec4c973132ae8
Summary:
Follow up to fix some issues with 59407f3660. Headers needed to be in the `project` section instead of `private` in xcode so they don't get included in the archive.
cc javache
Closes https://github.com/facebook/react-native/pull/11395
Differential Revision: D4313048
Pulled By: javache
fbshipit-source-id: 805dbbe9f149acfe780be76e99c949c450272358
Summary: No need to have two files; merge it into one and give it an appropriate name.
Reviewed By: javache
Differential Revision: D4296716
fbshipit-source-id: 904d13c23bb8d403b8efcb60f9a4aa5df5b08972
Summary: This singleton was unnecessary and can be implemented with a single `static` in `RCTDevMenu`. In another diff, I will rename `RCTWebSocketManager.{h,m}` to reflect the only class that remains.
Reviewed By: javache
Differential Revision: D4296551
fbshipit-source-id: 653971dfb31de5b0a161b531eed82a067f536ce3
Summary: Introduces an API to register a weakly-held listener for the reload (Cmd+R) command. This allows external infrastructure to hook into the reload command before the `RCTBridge` object is even created.
Reviewed By: javache
Differential Revision: D4286980
fbshipit-source-id: 51012fb8cbeb433dc880d9d98d847b07fdbb4c4f