Summary:
Fixes an issue with installing third party on iOS when the project's path contains a space, no matter where the space is in the path.
__Error__
```
/Users/AwesomeUser/Library/Developer/Xcode/DerivedData/AwesomeProject-xxx/Build/Intermediates.noindex/React.build/Debug-iphoneos/double-conversion.build/Script-190EE32F1E6A43DE00A8543A.sh: line 3: /Users/AwesomeUser/path contain space/scripts/ios-install-third-party.sh: No such file or directory
/Users/AwesomeUser/Library/Developer/Xcode/DerivedData/AwesomeProject-xxx/Build/Intermediates.noindex/React.build/Debug-iphoneos/double-conversion.build/Script-190EE32F1E6A43DE00A8543A.sh: line 3: exec: /Users/AwesomeUser/path contain space/scripts/ios-install-third-party.sh: cannot execute: No such file or directory
```
Closes https://github.com/facebook/react-native/pull/15377
Differential Revision: D5572671
Pulled By: shergin
fbshipit-source-id: 102727fc1b820e399e170c9c0cb73fd5d1e018d5
Summary:
Hi React Native folks! Love your work!
To make contributing easier, this sets the indentation settings of all the Xcode projects to 2 spaces to match their contents.
Closes https://github.com/facebook/react-native/pull/15275
Differential Revision: D5526462
Pulled By: javache
fbshipit-source-id: cbf0a8a87a1dbe31fceed2f0fffc53839cc06e59
Summary:
This is the first PR from a series of PRs grabbou and me will make to add blob support to React Native. The next PR will include blob support for XMLHttpRequest.
I'd like to get this merged with minimal changes to preserve the attribution. My next PR can contain bigger changes.
Blobs are used to transfer binary data between server and client. Currently React Native lacks a way to deal with binary data. The only thing that comes close is uploading files through a URI.
Current workarounds to transfer binary data includes encoding and decoding them to base64 and and transferring them as string, which is not ideal, since it increases the payload size and the whole payload needs to be sent via the bridge every time changes are made.
The PR adds a way to deal with blobs via a new native module. The blob is constructed on the native side and the data never needs to pass through the bridge. Currently the only way to create a blob is to receive a blob from the server via websocket.
The PR is largely a direct port of https://github.com/silklabs/silk/tree/master/react-native-blobs by philikon into RN (with changes to integrate with RN), and attributed as such.
> **Note:** This is a breaking change for all people running iOS without CocoaPods. You will have to manually add `RCTBlob.xcodeproj` to your `Libraries` and then, add it to Build Phases. Just follow the process of manual linking. We'll also need to document this process in the release notes.
Related discussion - https://github.com/facebook/react-native/issues/11103
- `Image` can't show image when `URL.createObjectURL` is used with large images on Android
The websocket integration can be tested via a simple server,
```js
const fs = require('fs');
const http = require('http');
const WebSocketServer = require('ws').Server;
const wss = new WebSocketServer({
server: http.createServer().listen(7232),
});
wss.on('connection', (ws) => {
ws.on('message', (d) => {
console.log(d);
});
ws.send(fs.readFileSync('./some-file'));
});
```
Then on the client,
```js
var ws = new WebSocket('ws://localhost:7232');
ws.binaryType = 'blob';
ws.onerror = (error) => {
console.error(error);
};
ws.onmessage = (e) => {
console.log(e.data);
ws.send(e.data);
};
```
cc brentvatne ide
Closes https://github.com/facebook/react-native/pull/11417
Reviewed By: sahrens
Differential Revision: D5188484
Pulled By: javache
fbshipit-source-id: 6afcbc4d19aa7a27b0dc9d52701ba400e7d7e98f
Summary:
5701ae2145 didn't add the new files to xcodeproj, the project is still building fine but is getting rejected by apple app analysis tools because it thinks we are trying to use a private api `rootView`. Just adding the files that define the selector makes it get accepted now.
**Test plan**
Tested that I'm now able to submit a build on testflight using this change.
Closes https://github.com/facebook/react-native/pull/15072
Differential Revision: D5444838
Pulled By: hramos
fbshipit-source-id: a290ebd23c2510e103934a550d1b37899ce9c093
Summary:
It's very important in complex UIs to be able to apply alpha channel-based masks to arbitrary content. Common use cases include adding gradient masks at the top or bottom of scroll views, creating masked text effects, feathering images, and generally just masking views while still allowing transparency of those views.
The original motivation for creating this component stemmed from work on `react-navigation`. As I tried to mimic behavior in the native iOS header, I needed to be able to achieve the effect pictured here (this is a screenshot from a native iOS application):
In this image, there are two masks:
- A mask on the back button chevron
- A gradient mask on the right button
In addition, the underlying view in the navigation bar is intended to be a UIBlurView. Thus, alpha masking is the only way to achieve this effect.
Behind the scenes, the `maskView` property on `UIView` is used. This is a shortcut to setting the mask on the CALayer directly.
This gives us the ability to mask any view with any other view. While building this component (and testing in the context of an Expo app), I was able to use a `GLView` (a view that renders an OpenGL context) to mask a `Video` component!
I chose to implement this only on iOS right now, as the Android implementation is a) significantly more complicated and b) will most likely not be as performant (especially when trying to mask more complex views).
Review the `<MaskedViewIOS>` section in the RNTester app, observe that views are masked appropriately.
Closes https://github.com/facebook/react-native/pull/14898
Differential Revision: D5398721
Pulled By: javache
fbshipit-source-id: 343af874e2d664541aca1fefe922cf7d82aea701
Summary:
* Cleanup some header files so we use more forward declarations
* Rename Executor to JSExecutor.h
* Move some typedefs to more appropriate locations
Reviewed By: mhorowitz
Differential Revision: D5301913
fbshipit-source-id: e75154797eb3f531d2f42a5e95409f4062b85f91
Summary: in order to prepare open sourcing React Native Packager, we have to move scripts specific to React Native to a directory that will continue to exist.
Reviewed By: javache
Differential Revision: D5112193
fbshipit-source-id: eac77d0d981aecef7ee52365a6856340420a5638
Summary:
Issue Fix: #13485
Yet another race condition that was found by XCode's Thread Sanitizer.
Happens because wasBatchActive is read/write from multiple threads at the same time
- opened UIExplorer and see it works
- npm run test pass
- tested on own project as well
Signed CLA
Closes https://github.com/facebook/react-native/pull/13505
Differential Revision: D4906096
Pulled By: javache
fbshipit-source-id: 5d4329aafcfe9491ce0188fa1e2dd71e09b31031
Summary:
**Motivation**
Without this change, unit tests and integration tests won't build and run for Apple TV.
**Test plan**
Run `scripts/objc-test-tvos.sh` after uncommenting the TEST line.
Closes https://github.com/facebook/react-native/pull/13456
Differential Revision: D4875309
Pulled By: javache
fbshipit-source-id: 9b6fa3b7107924ba0346bf8be63bba5fe45acb53
Summary:
**Motivation** Fix the Apple TV build, which is broken after a recent commit.
**Test plan** Travis tvOS test script should succeed.
Closes https://github.com/facebook/react-native/pull/13284
Differential Revision: D4827053
Pulled By: ericvicenti
fbshipit-source-id: 380e8f1b32adfeea844bedc11326e5a6a755066a
Summary:
This is enforced for all of our internal iOS code and a common cause of import failures.
cc janicduplessis
Closes https://github.com/facebook/react-native/pull/13124
Differential Revision: D4765016
fbshipit-source-id: 7c8248c98bca0fa6bad24d5a52b666243375e0db
Summary:
Various fixes of xcode projects and cleaning up some warnings
Closes https://github.com/facebook/react-native/pull/13109
Differential Revision: D4762652
Pulled By: lacker
fbshipit-source-id: b452976a58962439de4adecc8e703264af40cb38
Summary:
The `UIManager` already has a lot of responsibilities and is deeply
tied with React Native's view architecture. This diff separates out a
`DeviceInfo` native module to provide information about screen dimensions and
font scale, etc.
Reviewed By: fkgozali
Differential Revision: D4713834
fbshipit-source-id: f2ee93acf876a4221c29a8c731f5abeffbb97974
Summary:
**Motivation**: Fix Apple TV build breakage
**Test plan**: This fixes Travis test that builds tvOS targets.
Closes https://github.com/facebook/react-native/pull/12869
Differential Revision: D4692883
fbshipit-source-id: 3babfe4ab6d80143e15410bff7cae41ada3bf09f
Summary:
MapView has been deprecated in open source for a while: http://facebook.github.io/react-native/docs/mapview.html
We still want to use it internally. Moving it away from the GitHub folder.
Reviewed By: mmmulani
Differential Revision: D4646199
fbshipit-source-id: f469971e448dbca12afe141b43fa8a2518c7d467
Summary:
Fix Apple TV breakage. This should allow scripts/objc-test-tvos.sh to run normally.
Closes https://github.com/facebook/react-native/pull/12565
Differential Revision: D4612182
Pulled By: hramos
fbshipit-source-id: 77fd3eeabc6757b23e4f5efbd46e9948b61b1ab6
Summary:
This decouples non-UI logic from RCTDevMenu into a new module RCTDevSettings.
**Motivation**: This allows developers to change dev settings without depending on the built-in dev menu, e.g. if they want to introduce their own UI, or have other devtools logic that doesn't depend on an action sheet.
It also introduces the RCTDevSettingsDataSource protocol for storing dev tools preferences. This could allow a developer to implement alternative behaviors, e.g. loading the settings from some other config, changing settings based on the user, deciding not to persist some settings, or something else.
The included data source implementation, RCTDevSettingsUserDefaultsDataSource, uses NSUserDefaults and is backwards compatible with the older implementation, so **no workflows or dependent code will break, and old saved settings will persist.**
The RCTDevMenu interface has not changed and is therefore also backwards-compatible, though
some methods are now deprecated.
In order to ensure that RCTDevSettings
Closes https://github.com/facebook/react-native/pull/11613
Reviewed By: mmmulani
Differential Revision: D4571773
Pulled By: javache
fbshipit-source-id: 25555d0a6eaa81f694343e079ed02439e5845fbc
Summary:
In theory, we should be able to animate any non-layout property, including custom ones. While there is still work to be done on the native side to fully enable this, we should start by dropping the prop whitelist.
Closes https://github.com/facebook/react-native/pull/10658
Differential Revision: D4379031
Pulled By: ericvicenti
fbshipit-source-id: fe9c30ea101e93a8b260d7d09a909fafbb82fee6
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: 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
Summary:
Xcode really sucks, per some discussion on e1577df1fd and https://developer.apple.com/library/content/technotes/tn2215/_index.html, if you use the headers phase, and mark headers in your static library as public, they will actually end up in the final package that's built and you can't submit to the app store! This changes our xcode setup to use a copy files phase instead.
I've also changed the header include path to be $(BUILT_PRODUCTS_DIR)/include, which is added to the include path by Xcode by default, so 3rd party libraries should not be impacted by these changes anymore.
Reviewed By: mkonicek
Differential Revision: D4291607
fbshipit-source-id: 969b9ebcbeb8161f85427f8c429e198d9d0fae30
Summary: The target config inside React.xcodeproj was messed up, with source files being included in multiple or wrong targets. I went over the files in React.xcodeproj and verified that each .m file was included only once and was in the right target and .h were in the right projects.
Reviewed By: majak
Differential Revision: D4284673
fbshipit-source-id: 99af61083c6ca81311e30f0ea0045d4e7bffc20c
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary: Correct header import paths, update podspec so we point at the copy in ReactCommon (and can eventually remove the copy under React)
Reviewed By: astreet
Differential Revision: D4204501
fbshipit-source-id: e979a010092f025b2cdc289e1e5f22fc7b65a8d1
Summary: Updates objc version to use the same CSSLayout files as the android version
Reviewed By: emilsjolander
Differential Revision: D4182821
fbshipit-source-id: 81f18184b539fe0ef76ea868bc067b8283c2cccb
Summary:
- Consolidate common code in iOS and tvOS test scripts
- Start the packager before starting tests, to improve reliability
- Increase timeout value in RCTTestRunner.m
Closes https://github.com/facebook/react-native/pull/10378
Differential Revision: D4028364
Pulled By: bestander
fbshipit-source-id: 24c2124a1c62643a02f0668b60a67b971e08d1a3
Summary:
* Motivation *
Second PR for Apple TV support.
* Test plan *
Apple TV tests have been added to scripts/objc-test.sh
Closes https://github.com/facebook/react-native/pull/10227
Differential Revision: D3974064
Pulled By: javache
fbshipit-source-id: 36dffb4517efa489e40fa713a30655d1d76ef646
Summary:
Packager can take a long time to load and the progress is usually displayed in another window (Terminal). I'm adding support for showing a UI inside React Native app for packager's progress when loading a bundle.
This is how it will work:
1. React Native sends request to packager with `Accept: multipart/mixed` header.
2. Packager will detect that header to detect that client supports progress events and will reply with `Content-Type: multipart/mixed`.
3. While building the bundle it will emit chunks with small metadata (like `{progress: 0.3}`). In the end it will send the last chunk with the content of the bundle.
4. RN runtime will be receiving the events, for each progress event it will update the UI. The last chunk will be the actual bundle which will end the download process.
This workflow is totally backwards-compatible -- normally RN doesn't set the `Accept` header.
Reviewed By: mmmulani
Differential Revision: D3845684
fbshipit-source-id: 5b3d2c5a4c6f4718d7e5de060d98f17491e82aba
Summary:
Change & motivation:
Added an environment variable, RCT_NO_LAUNCH_PACKAGER, that when set
Xcode not the launch the packager when building. This switch is needed
for CI builds, where launching the packager, which stays running, causes
the build to hang; port conflicts can be an issue as well. Really the
packager is only appropriate for interactive developer builds. This
is a problem for Visual Studio Team Services where we just added
React Native CI build support with a React Native build extension and
surely a problem for all CI systems. This fix is simple, and now if
the build machine sets RCT_NO_LAUNCH_PACKAGER globally or passes
it as an arg to xcodebuild, the packager won't launch and all is well.
Testing:
I tested by building both with & without the environment variable defined, ensuring
things work probably in both cases. I also added support to our VSTS build ask to use
this and verified it works as expected too, when setting the variable..
Closes https://github.com/facebook/react-native/pull/6180
Differential Revision: D3764648
Pulled By: sahrens
fbshipit-source-id: b41cc06152aec271bbfdb2bd52d4b83a5f9c09a7
Summary:
Currently React Native codebase treats JS stack traces as array of dictionaries.
This diff switches the Red Box to use new `RCTJSStackFrame` for internal data representation, while keeping the exposed API unchanged. The next step would be to replace the rest of manual parsing and usage of dictionaries.
The new class has ability to parse the stack from raw strings or dictionaries.
Depends on D3429031
Reviewed By: javache
Differential Revision: D3473199
fbshipit-source-id: 90d2a4f5e8e054b75c99905f35c2ee54927bb311
Summary:
Delete the bridge functions(isRTL, allowRTL()) in internal module and move to OSS.
Create bridge for RCTI18nUtil
Reviewed By: fkgozali
Differential Revision: D3519224
fbshipit-source-id: 3853edcfcc78777d957874448117de72ae0700b5
Summary:
I used the reproducible steps as described in origin bug ticket #7987 as test plan.
This has the same contents as PR #8130 but then against master per janicduplessis request.
Closes https://github.com/facebook/react-native/pull/8134
Differential Revision: D3491126
fbshipit-source-id: a22669dc998f82b36fbe31d882d0a29f0912e2ee
Summary:
88c6e7a22b / D3446871 broke the OSS version of React where React.xcodeproj isn't autogenerated.
**Test plan:** UIExplorer example works again.
Closes https://github.com/facebook/react-native/pull/8288
Differential Revision: D3466246
Pulled By: javache
fbshipit-source-id: 1240b755b0df54ddfde016d0122640293e50caeb
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Reviewed By: javache
Differential Revision: D3365373
Pulled By: nicklockwood
fbshipit-source-id: 66d149eb80c5c6725311e1e46d7323eec086ce64
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
You'd now write:
const Keyboard = require('Keyboard');
Keyboard.addListener('keyboardWillShow', (event) => { ... });
Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
Write:
this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
Reviewed By: javache
Differential Revision: D3269966
fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary:
I forgot to add new files manually to `React.xcodeproj` (it's not managed by buck).
public
Reviewed By: javache
Differential Revision: D2895546
fb-gh-sync-id: ed58e3505c269f5ed9433e94994471485adb2378
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
Alex Dvornikov
Gabriel Bull
Adlai Holler
Philipp von Weitershausen
Pieter De Baets
Marc Horowitz
Janic Duplessis
Adam Miskiewicz
Valentin Shergin
Theo Yaung
David Aurelio
Pieter De Baets
Andrew Tokarev
Douglas Lowder
Emil Sjolander
Ashwin Bharambe
Martin Konicek
Lukas Piatkowski
Ben Roth
Ryan Gomba
Dan Caspi
Adam Ernst
Andy Street
Alex Kotliarskyi
Ovidiu Viorel Iepure
Bret Johnson
David Goldman
Mengjue Wang
Redmar Kerkhoff
Philipp von Weitershausen
Alexey Lang
Adam Comella
Nathan Azaria
Nick Lockwood
Martin Kralik
