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
Summary: getBridge() is annotated VisibleForTesting, but still used
in DevSupportManager. Instead, add the necessary methods to the
CatalystInstance interface.
public
Reviewed By: astreet
Differential Revision: D2651265
fb-gh-sync-id: 395893a961c32843871de4451eeccb33135b7ede
Summary: This makes the exception a nested class of the interface,
which eliminates the dependency of DevSupportManager on
ProxyJavaScriptExecutor.
public
Reviewed By: astreet
Differential Revision: D2651252
fb-gh-sync-id: 99de1c308b9bce717ab749c4e239d2773a920e1f
Summary: registering with systrace checks if the bridge is
initialized, which it's not yet in the ctor. Defer registration until
after the bridge is created, and only unregister in that case.
public
Reviewed By: astreet, dreiss
Differential Revision: D2651244
fb-gh-sync-id: 8da1108e9d15fddde48d06f4ed61ee0f787016ad
Summary: public
Native view recycling implementation based on limited pools of views.
In this diff I introduced new UIManager method: dropViews. Instead of removing views from tag->view maps when they are detached we keep them there until we get a call to dropViews with the appropriate tag. JS may keep a pool of object and selectively decide not to enqueue drop for certain views. Then instead of removing those views it may decide to reuse tag that has been previously allocated for a view that is no longer in use.
Special handling is required for layout-only nodes as they only can transition from layout-only to non-layout-only (reverse transition hasn't been implemented). Because of that we'd loose benefits of view flattening if we decide to recycle existing non-layout-only view as a layout-only one.
This diff provides only a simple and manual method for configuring pools by calling `ReactNativeViewPool.configure` with a dict from native view name to the view count. Note that we may not want recycle all the views (e.g. when we render mapview we don't want to keep it in memory after it's detached)
Reviewed By: davidaurelio
Differential Revision: D2677289
fb-gh-sync-id: 29f44ce5b01db3ec353522af051b6a50924614a2
Summary: public
Changed ListView to use onLayout and onContentSizeChange (new) events instead of measure. Updated ScrollView implementation to support contentSizeChange event with an implementation based on onLayout attached to the content view. For RecyclerViewBackedScrollView we need to generate that event directly as it doesn't have a concept of content view.
This greatly improves performance of ListView that uses RecyclerViewBackedScrollView
Reviewed By: mkonicek
Differential Revision: D2679460
fb-gh-sync-id: ba26462d9d3b071965cbe46314f89f0dcfd9db9f
Denis Koroskin
Dave Miller
mkonicek pr tester
Der-Nien Lee
olivier notteghem
Alexander Blom
Felix Oghină
Oleksandr Stashuk
Konstantin Raev
Mike Armstrong
Andy Street
SungHyun Park
Brent Vatne
Kyle Corbitt
Pieter De Baets
Peter Lai
Marc Horowitz
Saurabh Aggarwal
Krzysztof Magiera