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
When forwarding the unbundle code to the bridge, we’re passing the code by value.
This changes the affected method to take it by reference.
Reviewed By: astreet
Differential Revision: D2759569
fb-gh-sync-id: 508d4f4d56bcbdd5a7df5610cf9040121f8878ef
Summary:
public
New version of gradle has a better support for zipTree copy task. Since we have a few of those including one for boost library which used to take very long, after upgrading we no longer need 6a656a1.
Also seems like many improvements made to gradle since 2.2 made it perform better on incremental builds (around 10% improvement on my laptop).
Command used to upgrade gradle version:
gradle wrapper --gradle-version 2.9
Some of the plugins require updating as well since the previous versions were incompatible with gradle 2.9.
Closes https://github.com/facebook/react-native/pull/4462
Reviewed By: mkonicek
Differential Revision: D2754786
Pulled By: mkonicek
fb-gh-sync-id: 92c07d29aec6d5b4b2c55205b42b135c4d9479a9
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 b65f1f2234.
Closes https://github.com/facebook/react-native/pull/4555
Reviewed By: svcscm
Differential Revision: D2741203
Pulled By: mkonicek
fb-gh-sync-id: f4ee9ccdfc64374d58824a6e988409ac2b7532a4
Summary:
public
- Open source the unit test for `ClipboardModule`, start using the `ReactTestHelper` in two unit tests
- Fixes a few references to "pasteboard" in strings
Reviewed By: bestander
Differential Revision: D2739614
fb-gh-sync-id: e076940a3ae5c22314e181a37fe2c3f77a18cf85
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
Summary: public I need to extend NativeViewHierarchyManager to support a richer set of operations on Views, and those operations needs to be ran in UI thread.
Existing UIViewOperationQueue doesn't know about those operations, so I need to extend it too to allow them. This patch is making the class constructor protected to allow subclassing it from another package. Should not have any functional changes.
Reviewed By: astreet
Differential Revision: D2554826
fb-gh-sync-id: ad2d44a61beb216d940e20cd1489d3b5da1b398b
Summary: public Right now there is no centralized place to initialize CallerContext for Fresco. It should probably go through FrescoModule, but currently it's going through ReactImageManager, and thus unavailable to FlatUIImplementation, that doesn't use ReactImageManager. So this diff provides public getters for CallerContext (and DraweeControllerBuilder) in ReactViewManager. This is hacky and generally should not be needed, but without it groups don't have correct CallerContext set.
Reviewed By: kmagiera, astreet
Differential Revision: D2569372
fb-gh-sync-id: 2622e69c64bfebfc575deb330ee77e0139efb7ec
Summary: public
Our view handling for determining if a touch was in a view was not transform aware. This updates it to be
transform aware (by borrowing the code from ViewGroup).
Now, touches will be correctly translated to the view if the view is transformed. They will also have the correct
local touch point.
This fixes https://github.com/facebook/react-native/issues/3557
Reviewed By: andreicoman11
Differential Revision: D2696063
fb-gh-sync-id: 291f6b9884c610c29f8f8b9992c98d59863ab481
Summary: public UIImplementationProvider allows plugging in an alternative UIImplementation. A follow up diff adds a toggle under FB Dev Settings and uses this class to control an implementation. This allows us experimenting with other ways of generating UI hierarchy from JavaScript components.
Reviewed By: astreet
Differential Revision: D2554774
fb-gh-sync-id: 6574a893020e3519bd2ab00b9620a6dbdfaed595
Summary: This allows an app to configure much more options in Fresco. public
Reviewed By: astreet
Differential Revision: D2700598
fb-gh-sync-id: e1ffff18bff270e14ef82c14f7bfeef984605738
Summary: public UIManagerModule should not be creating UIImplementation. Instead, UIImplementation instance should be supplied to it to allow plugging in different implementations. No functional changes.
Reviewed By: astreet
Differential Revision: D2464632
fb-gh-sync-id: e7372977c93ceb7ef5e8658e5ee7e8e87f52d851
Summary: public
We're seeing related crashes. The diff has no tests, the perf tests weren't conclusive, and the person who'd be supporting it no longer is available to work on it. We can try this again later in a less rushed manner with proper perf testing.
Reviewed By: davidaurelio
Differential Revision: D2696615
fb-gh-sync-id: 3b6814ac12af19516146d5c42d2add8321b10db5
Summary: public This diff extracts all shadow hierarchy-specific logic from UIManagerModule into a UIImplementation class. This will later allow using in alternative UIImplementations in future.
Reviewed By: astreet
Differential Revision: D2457849
fb-gh-sync-id: 532128ce1d67b525cdf03794a5a29d7e9ed0ab90
Summary: public There is really no reason NativeViewHierarchyManager.addRootView() should be performed synchroniously when called from background thread, as long as it is executed before every other command in UIViewOperationQueue, and we can ensure that by putting add view command at the front of the queue. When that happpens, the queue should always be empty anyway, but it's best to be safe.
This eliminates an unnecessary blocking call and should overall make the code simpler and safer (Semaphores can timeout).
Reviewed By: astreet
Differential Revision: D2462680
fb-gh-sync-id: 784ac6573a455019b93628c70992f3830b9d6f1f
Summary: public UIManageModule creates AnimationRegistry but never uses it, this diff moves it to NativeViewHierarchyManager who owns it. UIViewOperationQueue depends on AnimationRegistry to perform some of the enqueued operations, so it accessed it through a getting in NativeViewHierarchyManager. This will also make sure NativeViewHierarchyManager. and UIViewOperationQueue operate on the same AnimationManager (previously, that wasn't really enforced). This is needed so I can move away UIViewOperationQueue creation off the UIManagerModule. This diff should have no functional changes whatsoever.
Reviewed By: astreet
Differential Revision: D2462605
fb-gh-sync-id: 1e3cd64908f51126362f2b5fb39b1efa6521854e
Summary: ~~This is a WIP, just finished the first bit and wanted to get some feedback to see if this approach seems appropriate, as I haven't done a lot of Android development.~~
Looks ready for review now.
Closes https://github.com/facebook/react-native/pull/3791
Reviewed By: svcscm
Differential Revision: D2672262
Pulled By: mkonicek
fb-gh-sync-id: 1e8f1cc6658fb719a68f7da455f30a7c9b1db730
Summary: This PR includes a working interface to Android's `elevation` property implemented as an RN style. Elevation is the only (easy) [platform-supported way to create shadows](http://developer.android.com/training/material/shadows-clipping.html). For it to work note that you must be running on Android 5.0+, and add `elevation` to a view with a `backgroundColor` set. These are platform limitations.
This PR is not intended to be merged in its current state, but rather to inform the discussion from #2768. At a minimum, before merging we would need to add the elevation style to the docs and rebase this to master (**EDIT** I have now rebased on master because from v0.14.2 too many commits were being pulled in -- haven't tested it since the rebase though). Additionally, it might be good to add tests, although I couldn't find any for the Android code. I'm happy to get that done if this feature gets signed off by the React Native team.
Finally, as I argued in #2768 I think that `elevation` is a useful abstraction ov
Closes https://github.com/facebook/react-native/pull/4180
Reviewed By: svcscm
Differential Revision: D2684746
Pulled By: mkonicek
fb-gh-sync-id: 825f3ccd20c4b0eea9d11b5f0e3a6b018b7e4378
Summary: The anonymous class had an implicit reference back to FrescoModule that would in turn retain the context.
public
Reviewed By: astreet
Differential Revision: D2690747
fb-gh-sync-id: 8a97c102e461b903c6adf7c65956baf364fa5faf
Summary: public
We pass in a `ReactContext` but we really only need a context. Make sure we're using the application one.
Reviewed By: astreet
Differential Revision: D2690692
fb-gh-sync-id: 857d6571c9c01d35e12f09be4c8733cca007306f
Summary: public
The common case is to hit an error when the server isn't running. We shouldn't spew a stack trace for it.
Reviewed By: foghina
Differential Revision: D2685706
fb-gh-sync-id: d230af170b92a05452f04a90f23172f15e62dce6
Summary: public
This moves Android touch events to parity with iOS. The locationX,Y value passed to js now is view relative to the view that is handling the touch.
The pageX,Y is now relative to the root view.
Reviewed By: andreicoman11
Differential Revision: D2670028
fb-gh-sync-id: 5438640d6c78633629b9a308a59cc306bb07815e
Summary: This adds a persistent cookie store that shares cookies with WebView.
Add a `ForwardingCookieHandler` to OkHttp that uses the underlying Android webkit `CookieManager`.
Use a `LazyCookieHandler` to defer initialization of `CookieManager` as this will in turn trigger initialization of the Chromium stack in KitKat+ which takes some time. This was we will incur this cost on a background network thread instead of during startup.
Also add a `clearCookies()` method to the network module.
Add a cookies example to the XHR example. This example should also work for iOS (except for the clear cookies part). They are for now just scoped to Android.
Closes#2792.
public
Reviewed By: andreicoman11
Differential Revision: D2615550
fb-gh-sync-id: ff726a35f0fc3c7124d2f755448fe24c9d1caf21
Summary: Change the following classes into interfaces, with a separate
Impl file: CatalystInstance, ReactInstanceManager,
CatalystQueueConfiguration, MessageQueueThread. This is done to help
isolate the interface between React Native and applications which use it.
This will also help some intrusive development work on a branch
such as porting parts of the bridge to common C++ code, without affecting
app reliability while this work is ongoing.
public
Reviewed By: astreet
Differential Revision: D2651277
fb-gh-sync-id: f04dc04a6e68df7acbc2bbf8b2529287d7b5b2ae
Summary: make DevSupportManager PUBLIC visibility, instead of adding
to it more; put private parts of OnLoad into an anonymous namespace,
and move NativeRunnable into it; don't make NativeArray depend on
MethodCall which it does not use.
public
Reviewed By: astreet
Differential Revision: D2651270
fb-gh-sync-id: d5262da79cbd60c4eb490d43d13cc625fa163cdf