Summary:
Keep `WebView.android.js` and `WebView.ios.js`, there are
some small differences. Use the same example on both platforms.
public
Reviewed By: bestander
Differential Revision: D2769446
fb-gh-sync-id: be3d0afcbfd6ddcbaa49f70555063b3081ba03cb
Summary:
public
The `DialogModule` requires `android.support.v4.app.FragmentManager` which means
every app that wants to use Dialogs would need to have its Activity extend the legacy
`android.support.v4.app.FragmentActivity`.
This diff makes the `DialogModule` work with both the Support `FragmentManager`
(for AdsManager & potentially other fb apps) and the `android.app.FragmentManager`
(for new apps with no legacy dependencies).
Also wrap the native module in the same `Alert` API that we have on iOS and provide
a cross-platform example. In my opinion the iOS Alert API is quite nice and easy to use.
We still keep `AlertIOS` around because of its `prompt` function which is iOS-specific
and also for backwards compatibility.
Reviewed By: foghina
Differential Revision: D2647000
fb-gh-sync-id: e2280451890bff58bd9c933ab53cd99055403858
Summary:
public
This adds support for
onScrollBeginDrag/End
onMomentumScrolBegin/End
Reviewed By: astreet
Differential Revision: D2739035
fb-gh-sync-id: 2a49d1df54e5f5cd82008bdb0ffde0881ba39aff
Summary:
JS relies on the URL returned by SourceCodeModule to load packager assets. Because we currently return localhost when debugging (because that's the URL Chrome uses), assets don't load when debugging. This makes it so SourceCodeModule still returns the package URL relative to the emulator / device even when debugging.
public
Reviewed By: astreet
Differential Revision: D2759710
fb-gh-sync-id: bab6a88ef044b8b4d971381e3b23c59fa9aa2ed0
Summary:
Add a method to handle URLs registered to the app,
```js
IntentAndroid.getInitialURL(url => {
if (url) {
// do stuff
}
});
```
Refer - http://developer.android.com/training/app-indexing/deep-linking.html#adding-filters
The API cannot be same as the iOS API (i.e. as a constant), as the activity is not availble at the time of module initialization. Moreover, multiple activties can share the same bridge instance, and the activity itself is not a constant. Hence the initialURL can change.
Closes https://github.com/facebook/react-native/pull/4320
Reviewed By: svcscm
Differential Revision: D2759667
Pulled By: foghina
fb-gh-sync-id: b725231ae1401fa5565d444eee5a30d303e263ae
Summary:
public
Rename the `ConnectivityModule` to `NetInfoModule` (there's
no need to name things differently in two places). Add exception
handling to the module in case the network permission is missing.
When the permission is missing, throw an actionable error from
all calls to `NetInfo`: http://imgur.com/zVIMxOV
Without this change, the app immediately crashes on startup:
`getCurrentConnectionType` is called from `Activity.onResume`.
Reviewed By: andreicoman11, bestander
Differential Revision: D2749230
fb-gh-sync-id: 1b752d21a8f28ffeaf60a3322cb76f869dc70a14
Summary:
public
Rename the `BridgeProfiling` JS module to `Systrace`, since it's actually just
an API to Systrace markers.
This should make it clearer as we add more perf tooling.
Reviewed By: jspahrsummers
Differential Revision: D2734001
fb-gh-sync-id: 642848fa7340c545067f2a7cf5cef8af1c8a69a2
Summary:
If border radius is not set or is zero, then elevation will not
work properly. This bug seems to have been introduced when the
style in facebook/react-native#4180 was modified slightly to
produce commit b65f1f223488b52963f80a67bb41956103263d27.
Closes https://github.com/facebook/react-native/pull/4555
Reviewed By: svcscm
Differential Revision: D2741203
Pulled By: mkonicek
fb-gh-sync-id: f4ee9ccdfc64374d58824a6e988409ac2b7532a4
Summary:
The JavaScript ecosystem doesn't have the notion of a built-in native module loader. Even Node is decoupled from its module loader. The module loader system is just JS that runs on top of the global `process` object which has all the built-in goodies.
Additionally there is no such thing as a global require. That is something unique to our providesModule system. In other module systems such as node, every require is contextual. Even registered npm names are localized by version.
The only global namespace that is accessible to the host environment is the global object. Normally module systems attaches itself onto the hooks provided by the host environment on the global object.
Currently, we have two forms of dispatch that reaches directly into the module system. executeJSCall which reaches directly into require. Everything now calls through the BatchedBridge module (except one RCTLog edge case that I will fix). I propose that the executors calls directly onto `BatchedBridge` through an instance on the global so that everything is guaranteed to go through it. It becomes the main communication hub.
I also propose that we drop the dynamic requires inside of MessageQueue/BatchBridge and instead have the modules register themselves with the bridge.
executeJSCall was originally modeled after the XHP equivalent. The XHP equivalent was designed that way because the act of doing the call was the thing that defined a dependency on the module from the page. However, that is not how React Native works.
The JS side is driving the dependencies by virtue of requiring new modules and frameworks and the existence of dependencies is driven by the JS side, so this design doesn't make as much sense.
The main driver for this is to be able to introduce a new module system like Prepack's module system. However, it also unlocks the possibility to do dead module elimination even in our current module system. It is currently not possible because we don't know which module might be called from native.
Since the module system now becomes decoupled we could publish all our providesModule modules as npm/CommonJS modules using a rewrite script. That's what React Core does.
That way people could use any CommonJS bundler such as Webpack, Closure Compiler, Rollup or some new innovation to create a JS bundle.
This diff expands the executeJSCalls to the BatchedBridge's three individual pieces to make them first class instead of being dynamic. This removes one layer of abstraction. Hopefully we can also remove more of the things that register themselves with the BatchedBridge (various EventEmitters) and instead have everything go through the public protocol. ReactMethod/RCT_EXPORT_METHOD.
public
Reviewed By: vjeux
Differential Revision: D2717535
fb-gh-sync-id: 70114f05483124f5ac5c4570422bb91a60a727f6
Summary:
public
D2670028 updated the x/y positions of touch events to be relative to the window, but measure still uses the location on the screen. Therefore, in Touchable.js, we were seeing taps get inproperly invalidated because they were erroneously considered outside of the touch rect. This diff moves back to the old version of pageX/Y on touch events that's compatible with the current version of measure.
Reviewed By: nicklockwood
Differential Revision: D2724917
fb-gh-sync-id: 978ae26fcaa23c47a4f619e2b7ff2d078388ae95
Summary:
public
Fixes#4309
This adds the possibility to reject `Promise` instances with `Throwable`s in java, instead of strings.
For now, it only reads the message, but we can add more features on top of this, e.g. forwarding the error stack.
Reviewed By: andreicoman11
Differential Revision: D2708192
fb-gh-sync-id: ca5ff584eca29370a9f9b780fa9825b17863a7e9
Summary:
Refactor modules that take activities (or activities that implement some interface) as constructor args to not do that. Expose `getCurrentActivity()` in `ReactContext` and use that wherever the activity is needed.
public
Reviewed By: astreet
Differential Revision: D2680462
fb-gh-sync-id: f263b3fe5b422b7aab9fdadd051cef4e82797b0a
Summary: public This patch adds an alternative UIImplementation based on an idea of creating UI hierarchy off-the-main-thread (everything but Views), flattening ReactShadowNode hierarchy and displaying it within a single View when possible. While NativeViewHierarchyOptimizer allows removing layout-only RCTViews, this allows removing RCTView, RCTText and RCTImage.
This is an initial bare-bones implementation that doesn't really draw anything, only lays out the shadow nodes. Followup diffs will add missing features.
Reviewed By: astreet
Differential Revision: D2564309
fb-gh-sync-id: 2dda4c8cfc2bac3eb39c5c15e97bd23a57550a1d
Summary: It hasn't been resumed yet when first constructed.
public
Reviewed By: astreet
Differential Revision: D2705635
fb-gh-sync-id: fa90a89524d56fd5e349ebad2820b42deba7f26f
Summary: public
This fixes the ordering of methods in touch handling to take their arguments as X,Y instead of Y,X.
This is really just internal cleanup of native touch handling.
Reviewed By: andreicoman11
Differential Revision: D2703003
fb-gh-sync-id: d169436d21fd11c1a9cb251e7e0b57b2094699e4
Summary: public I need to construct this class outside of the uimanager package, and this requires the class (and its constructor) to be public.
Reviewed By: astreet
Differential Revision: D2554847
fb-gh-sync-id: a73c3236b91a1ed7074521e19b72e1994804cced
Summary: public This diff makes a few small changes to NativeViewHierarchyManager to allow extending it:
a) makes the class public so it can be constructed from outside of the package
b) adds resolveView and resolveViewManager to access mTagsToViews and mTagsToViewManagers
c) changes addRootView signature to make root view a ViewGroup instead of SizeMonitoringFrameLayout
The reason behind change c) is that in FlatUIImplementation I want to use a root view that does not extend SizeMonitoringFrameLayout. NativeViewHierarchyManager doesn't really use any of the root view properties, so it could be even a View, but ViewGroup seems more fitting.
This diff should contain no functional changes or other side-effects.
Reviewed By: astreet
Differential Revision: D2554841
fb-gh-sync-id: cce748707cf7485d456e4a057dae1db87aa17160
Summary: public NativeViewHierarchyManager.createView() takes int rootViewTag which is only used to resolve ThemedReactContext, but we already have it resolved before we enqueueCreateView, so we can just pass it directly. This makes mRootViewsContext tag -> to ThemedReactContext mapping unnecessary in NativeViewHierarchyManager. Makes the class simpler.
Reviewed By: kmagiera, astreet
Differential Revision: D2460280
fb-gh-sync-id: 68c503f4fb37ca0b1dcb2abc9e0c33a5225d1f6a
