Summary:
Works the same way as `react-native run-android`, but targets iOS simulator instead. Under the hood, it uses `xcodebuild` to compile the app and store it in `ios/build` folder, then triggers `instruments` and `simctl` to install and launch the app on simulator.
Since Facebook relies on BUCK to build and run iOS app, we probably won't use `run-ios` internally. That's why I'm putting this as public PR instead of internal diff.
To test this, I hacked global `react-native` script to install react native from my local checkout instead of from npm, cd into the folder and ran `react-native run-ios`.
Closes https://github.com/facebook/react-native/pull/5119
Reviewed By: svcscm
Differential Revision: D2805199
Pulled By: frantic
fb-gh-sync-id: 423a45ba885cb5e48a16ac22095d757d8cca7e37
Summary:
When used in automation, `wrong-react-native` can cause problems because it does not
report the issue via exit code.
Closes https://github.com/facebook/react-native/pull/5114
Reviewed By: svcscm
Differential Revision: D2799995
Pulled By: frantic
fb-gh-sync-id: 23c32dac9b0fcdbeaf48b94e9cb220c6c1b344aa
Summary:
public
Unfortunately, it turns out that NSURLComponents.queryItems only works on iOS 8 and above. This diff re-implements the RCTGetURLQueryParam and RCTURLByReplacingQueryParam functions using functionality available in iOS 7.
Reviewed By: javache
Differential Revision: D2803679
fb-gh-sync-id: 56f10bef4894d16197975b6023b7aa5ab106d8cb
Summary:
2 things that I want to clarify / ask for feedback:
* do we really need to make sure we're running on the UI thread? I guess `onPageStarted` maybe already runs there? Couldnt find anything [here](http://developer.android.com/reference/android/webkit/WebView.html) though
* everytime a page starts we re-enable debugging -- it's a bit useless but I also don't think it's a huge problem, as debugging should only be enabled in dev
Relates to issue #4857, where we switched debugging off as, in some circumstances, it would crash the application as debugging was invoked outside the UI thread.
Closes https://github.com/facebook/react-native/pull/5071
Reviewed By: svcscm
Differential Revision: D2803649
Pulled By: astreet
fb-gh-sync-id: 523d3b442b196d6c54b14ba0c2b29601095c3363
Summary:
When you reload code while using the Chrome debugger we used to create a new websocket connection before closing
the old one. This sometimes would cause a in-flight call to not get a response. This in turn would deadlock the JS thread
because we try to shut it down before killing the websocket connection.
This change instead makes sure to close the old connection before creating a new one. This is done by using a factory for
creating the JavascriptExecutor so we can defer the creation until after the old Bridge has been torn down.
public
Reviewed By: astreet
Differential Revision: D2735011
fb-gh-sync-id: 0ce0f35abaeef5457bad8d6b8d10122281192af4
Summary:
public
The logic inside RCTBatchedBridge contained some race conditions that would occasionally cause an error if modules were loaded in the wrong order. This improves that logic and makes it safer by adding a lock to prevent concurrency.
Reviewed By: jspahrsummers
Differential Revision: D2802930
fb-gh-sync-id: d1ad25fa578649363dcaac029cb24dc3a453ae67
`npm install` prints a lot of junk like gyp warnings
and the rest of the output is not super useful for
tracking progress.
Supress the output by default, show the output with
--debug, and show verbose output with --verbose.
Summary:
public
This exposes a proper API for adding synchronous callbacks to JS, as an optional feature of the executor.
This is based on nicklockwood's work in D2764492, but avoids refactoring bridge/executor interactions for the time being, since we agree on this API and can move the actual callsites around later.
Reviewed By: nicklockwood
Differential Revision: D2799506
fb-gh-sync-id: af209d9a0be927f3404205feb16e59745cc37aec
Summary:
Including RCTPushNotificationManager is required for local notifications, which don't require a Push Notifications entitlement on your provisioning profile. However, if you don't have the entitlement, the app store warns you when you push an app build that contains `application:didRegisterForRemoteNotificationsWithDeviceToken:`, even if it isn't being called. This renames the methods so they have different names from the ones on UIApplication so the app store doesn't warn about them.
Closes https://github.com/facebook/react-native/pull/4897
Reviewed By: spicyj
Differential Revision: D2780533
Pulled By: nicklockwood
fb-gh-sync-id: 1a688f1ebd3cc9f86ba340ce453fdbfb46949839
Summary:
This is already open-source on iOS, albeit badly documented. Now Android too!
Tested in open source by adding a `import com.facebook.react.ARTPackage;` and `.addPackage(new ARTPackage())` to UIExplorerActivity.java, running
```
./gradlew :Examples:UIExplorer:android:app:installDebug
```
and copying VectorWidget into the UIExplorer JS code as described in http://browniefed.com/blog/2015/05/03/getting-react-art-running-on-react-native/.
public
Reviewed By: foghina
Differential Revision: D2700481
fb-gh-sync-id: 2a5308b022869ecc1868a46dbecf397581ddbe04
Summary:
It is required from the RN app JS, so it needs to be in prod dependencies.
cc martinbigio
Closes https://github.com/facebook/react-native/pull/5091
Reviewed By: svcscm
Differential Revision: D2798891
Pulled By: martinbigio
fb-gh-sync-id: 976ccf4d96338c8e3d7e457710559be51c4f7405
Summary:
This fixes the examples that are out of date.
Closes https://github.com/facebook/react-native/pull/5116
Reviewed By: svcscm
Differential Revision: D2800319
Pulled By: androidtrunkagent
fb-gh-sync-id: da1810c6146950be4be670fc69b9da32fb266303
Summary:
public
Before this diff we were only accepting the module that was modified but the user. This works fine as long as the user doesn't modify the dependencies a module has but once he starts doing so the HMR runtime may fail when updating modules' code because they might might a few dependencies. For instance, if the user changes the `src` a `Image` has to reference an image (using the new asset system) that wasn't on the original bundle the user will get a red box. This diff addresses this by diffing the modules the app currently has with the new ones it should have and including all of them on the HMR update. Note this diffing is only done when the we realize the module that was modified changed it's dependencies so there's no additional overhead on this change.
Reviewed By: vjeux
Differential Revision: D2796325
fb-gh-sync-id: cac95f2e995310634c221bbbb09d9f3e7bc03e8d
Summary:
public
Adds the ability to load files from assets without threading through an AssetManager. After the bridge is unforked, we should move to passing through an Environment object instead.
Reviewed By: lexs
Differential Revision: D2779079
fb-gh-sync-id: 82b47ecdf48b724076d87f4879ec40601e21e6bc
Summary:
public
It is helpful to be able to access the current MessageQueueThread like you would the current Looper. I would do this exactly as Looper does it, but we have forked implementations of MQT for the native bridge and MQT is an interface that can't hold private members.
Reviewed By: lexs
Differential Revision: D2779072
fb-gh-sync-id: 0ff841d8c490b971697c8e5d45f9c0a57668376b
Summary:
public
This diff introduces an internal transforms pipeline that integrates with the external one. This has been a feature we've been looking to implement for a long time to use babel instead of `replace` with regexps on many parts of the packager.
Also, to split the bundle we'll need to run one transform. Internally for Facebook we can run the system-import transform altogether withe the other ones. For OSS we offer `transformer.js` which people can use out of the box if they're writing ES6 code. For those people, `transformer.js` will also run the internal transforms`. However they might want to tune the transforms, or even write the code on another language that compiles to Javascript and use a complete different transformer. On those cases we'll need to run the external transforms first and pipe the output through the internal transforms. Note that the order it's important as the internal transforms assume the code is written in JS, though the original code could be on other scripting languages (CoffeeScript, TypeScript, etc).
Reviewed By: davidaurelio
Differential Revision: D2725109
fb-gh-sync-id: d764e209c78743419c4cb97068495c771372ab90
Summary:
public
Expose JS hooks to create flow events in systrace (the nice arrows to show async work flow) +
add support to the showing all the work enqueued from the JS thread as added in D2743733
Depends on D2743733
Reviewed By: jspahrsummers
Differential Revision: D2773664
fb-gh-sync-id: 4a8854b17b4741b882f5f2cc425e4237a5e4b3eb
Summary:
public
If Hot Loading is enabled bu the packager server is not running, as the user updates files he'll see red boxes caused by the HMR runtime. The error those red boxes show is pretty weird for the end user. Lets improve the feedback we give!.
Reviewed By: vjeux
Differential Revision: D2795534
fb-gh-sync-id: dcc39e6682e0603bf10d0f5e623433262b745660
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:
public
The implementation of the `methodQueue` lazy initializer in `RCTModuleData` could result in the queue being set twice, because calling `methodQueue` for a module that hasn't been instantiated would call `RCTModuleData.instance` to create the module, which itself calls `methodQueue`.
It's not clear if this was causing a bug, but it may be related to an occasional bug where the `RCTViewManager.methodQueue` returns nil.
Reviewed By: majak
Differential Revision: D2783320
fb-gh-sync-id: 9194da0fd7392f63825da1f5c450363dd300b635
Alex Kotliarskyi
Pieter De Baets
Nick Lockwood
odino
Konstantin Raev
Martin Konicek
Christoph Pojer
Satyajit Sahoo
Alexander Blom
Justin Spahr-Summers
Andy Street
Michelle Todd
Fada Chen
Ben Alpert
James Ide
James Ide
James Zhang
Felix Oghina
Martín Bigio
Tadeu Zagallo
Janic Duplessis
Katrina Nova
Jason Brown
Adam Miskiewicz
Alexey Vasiliev
Mike Armstrong
Jed Lau
lvwang2002
Jay Salvat
Qiao Liang
