Summary: Move all requires of UIManager to UIManager.js, so we can load the view manager configuration lazily when UIManager is required.
Reviewed By: majak
Differential Revision: D3270147
fb-gh-sync-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
fbshipit-source-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
Summary: Fixed a crash where making a network request with unrecognized/unsupported scheme would crash by attempting to insert a nil RCTNetworkTask into an array.
Reviewed By: javache
Differential Revision: D3275810
fb-gh-sync-id: be208c6bf87d882209901b850dcc25da4ba79a08
fbshipit-source-id: be208c6bf87d882209901b850dcc25da4ba79a08
Summary:
Currently the Modal component on Android is rendered below the Status Bar, which changes it's color to grey, and in the UIExplorer example the backdrop is just formatted to look the same color. In some scenarios users may want to preserve the color of their status bar and make it look as though the modal is appearing on top. This PR allows for that.
This GIF shows current behavior and new behavior with the translucentStatusBar prop set to true.
I've updated the UIExplorer app to demonstrate and the docs as shown below
Thanks!
Closes https://github.com/facebook/react-native/pull/7157
Differential Revision: D3264497
Pulled By: dmmiller
fb-gh-sync-id: 61346d99414d331d3420f44a4c5f6341b0973be6
fbshipit-source-id: 61346d99414d331d3420f44a4c5f6341b0973be6
Summary:
We previously were unmounting the react application unconditionally when the ReactRootView#onDetachedFromWindow. This is nice in that it automatically allows us to reclaim memory, but there are many scenarios where a ReactRootView can be embedded in another piece of UI that detaches its children as part of its normal function (e.g. ListView, RecyclerView, ViewPager, etc).
As such, we will now enforce that the hosting Activity/Fragment/??? explicitly calls unmountReactApplication in the same way it calls startReactApplication. For Applications extending ReactActivity/AbstractReactActivity, this will happen automatically in onDestroy.
Reviewed By: foghina
Differential Revision: D3265161
fb-gh-sync-id: 4d49b0c41256213f00874f57e784aa8741dbf394
fbshipit-source-id: 4d49b0c41256213f00874f57e784aa8741dbf394
Summary:
Add the possibility to define a progress view top offset to RefreshControl on android. As i comment in #6740, contentInset does the trick on IOS.
Looking android documentation seems that exists a possible solution:
http://developer.android.com/reference/android/support/v4/widget/SwipeRefreshLayout.html#setProgressViewOffset(boolean, int, int)
This pull request implement that but keeping it simple, only a top offset.
For example, now we could put navigation bar over the scrollview (or listview) and define a progressViewOffset on RefreshView in order to start behind the navigation. At this point we could make some kind of coordinator layout to hide/show navigation on scroll.
To maintain the default behavior, start point is equal to start point minus progress circle diameter in order to create that progress circle before the start point.
Closes https://github.com/facebook/react-native/pull/6759
Differential Revision: D3240664
Pulled By: mkonicek
fb-gh-sync-id: ccf866272e871811c1c6dcc2a34f5c217967feee
fbshipit-source-id: ccf866272e871811c1c6dcc2a34f5c217967feee
Summary:
There was an issue with the way we made `RefreshControl` a controlled component when react doesn't render synchronously. This fixes the issue by using the same technique used in the commit 0cd2904b23 for`PickerAndroid`
**Test plan (required)**
Tested normal behaviour and tested that if not setting the `refreshing` prop to `true` during the `onRefresh` callback that the `RefreshControl` stops refreshing immediately. Also made sure that `setNativeProps` is only called if needed when the native refreshing state is not in sync with JS.
Fix#7414
Closes https://github.com/facebook/react-native/pull/7445
Differential Revision: D3274981
fb-gh-sync-id: a1b9d46329f552984e33d11fa0e29ad6da689511
fbshipit-source-id: a1b9d46329f552984e33d11fa0e29ad6da689511
Summary:
When throttling scroll events with `scrollEventThrottle`, `onScroll`
is not guaranteed to be fired for the final scroll position
of the `ScrollView`. This can cause a component to render UI that
is consistent with the resting scroll position of the `ScrollView`.
This commit guarantees that an `onScroll` event will be fired for
the resting scroll position of the `ScrollView`.
**Test plan (required)**
Verified commit fixes a reduced repro. Also tested fix in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7366
Differential Revision: D3269303
Pulled By: javache
fb-gh-sync-id: f68ecb7e9c18d1ac255c6f872fb7eb4aadd07799
fbshipit-source-id: f68ecb7e9c18d1ac255c6f872fb7eb4aadd07799
Summary:
Previously, the back swipe navigation gesture would be enabled when the navigation bar is shown and disabled when the navigation bar is hidden.
This change enables developers to control the back swipe gesture independently of the visibility of the navigation bar. An example use case would be that an app wants to render a custom navigation bar so it sets `navigationBarHidden` to true and it wants to enable the back swipe gesture so it sets `interactivePopGestureEnabled` to true.
**Test plan (required)**
- Created a test app to verify setting `interactivePopGestureEnabled` to `true` and `false` with the navigation bar both hidden and shown.
- Verified prop works in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7369
Differential Revision: D3269304
Pulled By: javache
fb-gh-sync-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
fbshipit-source-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
Summary:
This simplifies the Quick Start section of the React Native documentation into
two pages. A Getting Started and a Tutorial.
The Getting Started page uses some CSS and Javascript magic (thanks vjeux for
the initial infra for this!!) to allow selection between platforms and have
instructions for Getting Started with React Native be shown according to the
selection -- all within the same page, realtime. A much cleaner interface.
I have made a pretty large presentation and information overhaul for each
platform as well. For example, requiring Android Studio for Android
development to make the Android SDK and build tools installation easier.
I added more screenshots to the Android sections since they are more complicated
than the more straightforward iOS. Screenshots for Android for Windows, Linux and
iOS are available now.
Some of the other pages such as `GettingStartedOnLinux` are now obsolete and deleted.
** Test Plan **
Tested locally and navigation works.
Closes https://github.com/facebook/react-native/pull/7418
Differential Revision: D3268621
Pulled By: vjeux
fb-gh-sync-id: 65f9181c9f959fadeffd254efddc5b64816eb1f4
fbshipit-source-id: 65f9181c9f959fadeffd254efddc5b64816eb1f4
Summary:
This simplifies the Quick Start section of the React Native documentation into
two pages. A Getting Started and a Tutorial.
The Getting Started page uses some CSS and Javascript magic (thanks @vjeux for
the initial infra for this!!) to allow selection between platforms and have
instructions for Getting Started with React Native be shown according to the
selection -- all within the same page, realtime. A much cleaner interface.
I have made a pretty large presentation and information overhaul for each
platform as well. For example, requiring Android Studio for Android
development to make the Android SDK and build tools installation easier.
I added more screenshots to the Android sections since they are more complicated
than the more straightforward iOS. Screenshots for Android for Windows, Linux and
iOS are available now.
Some of the other pages such as `GettingStartedOnLinux` are now obsolete and deleted.
Test Plan:
Video demo (it's a 1m20s or so, peruse at your pace): https://www.facebook.com/pxlcld/nKW3
Inspection
Reviewers: lacker, bestander, mkonicek, vjeux
Reviewed By: vjeux
Subscribers: cdykes, vjeux, mjohnston, sema, balpert, tomocchino, hramos, caabernathy, jpearce
Differential Revision: https://phabricator.intern.facebook.com/D3265822
Signature: t1:3265822:1462479878:5453ec81808b59fd71c288b6cc79268fccd921bc
Summary:
Debugging tools won't work if you're using a custom configuration and Cocoapods and didn't specify the configuration to be a `debug` configuration using the `xcodeproj` setting in your Podfile. When integrating React Native into an existing Xcode project, this is a common situation to encounter.
See https://github.com/facebook/react-native/issues/2246#issuecomment-217187621
Closes https://github.com/facebook/react-native/pull/7407
Differential Revision: D3268032
fb-gh-sync-id: f46c4a1f927128fd34c2f8ce4be4c275468f2355
fbshipit-source-id: f46c4a1f927128fd34c2f8ce4be4c275468f2355
Summary:
The containers in NavigationExperimental are not appropraite because the state should be held by the app's architecture, be it redux, flux, or simple component state.
This diff moves the examples over to simple component state, but there are several other examples of how to use NavigationAnimatedView and the navigation reducers with redux:
- https://github.com/jlyman/RN-NavigationExperimental-Redux-Example
- Switching the f8 app with redux to navigation experimental: https://github.com/fbsamples/f8app/pull/14
Reviewed By: hedgerwang
Differential Revision: D3219911
fb-gh-sync-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
fbshipit-source-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
Summary:
This code change allows changing the transition velocity of the navigator
when switching views.
Whats the use case? If you have different types of
animations your animations might also need different transition velocities.
Closes https://github.com/facebook/react-native/pull/5439
Differential Revision: D3264719
Pulled By: ericvicenti
fb-gh-sync-id: 1bc0a1191ed3bd51b624acd161c3ee77fd748d72
fbshipit-source-id: 1bc0a1191ed3bd51b624acd161c3ee77fd748d72
Summary:
Fixed regex that looks for OK sign
**Test plan (required)**
- circle CI results
Closes https://github.com/facebook/react-native/pull/7410
Differential Revision: D3265016
fb-gh-sync-id: 1eba7297116d31f8bf3393733141058cf6a7454a
fbshipit-source-id: 1eba7297116d31f8bf3393733141058cf6a7454a
Summary:
This should simplify the renderScene usage a bit because the react key is required and this will make sure they are rendered with the right key automatically.
It changes the string to make sure people do not rely on this API for anything else.
Reviewed By: javache
Differential Revision: D3033933
fb-gh-sync-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
fbshipit-source-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
Summary:
the prop type check for NavigationCard -> SceneView -> sceneRendererProps is wrong.
Fix it.
Reviewed By: ericvicenti
Differential Revision: D3265049
fb-gh-sync-id: 16e89c932f0f962db4b6a647d62d255ba98f6156
fbshipit-source-id: 16e89c932f0f962db4b6a647d62d255ba98f6156
Summary:
NavigationLegacyNavigator was originally created to help people to migrate to the new
navigation library without API changes. Therefore we'd have to port all the old APIs that
don't necessarily seem align well with the new navigation library.
Consider the production usage of NavigationLegacyNavigator does not exist, it's better
to kill it and we'd just rename the `Navigator` to `NavigatorDeprecated` later instead.
Reviewed By: ericvicenti
Differential Revision: D3263704
fb-gh-sync-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
fbshipit-source-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
Summary: Fixes a race condition where JS module functions could be called in between ##initializeWithInstance(catalystInstance);## and ##CatalystInstance#runJSBundle##, before the BatchedBridge in JS was set up. We now guarantee that all JS module methods that are called after `ReactContext#hasActiveCatalystInstance()` returns true will have the batched bridge created and ready to use.
Reviewed By: lexs
Differential Revision: D3258651
fb-gh-sync-id: 66e66533cc86d185e7c865376d6a5cdc6520d2d4
fbshipit-source-id: 66e66533cc86d185e7c865376d6a5cdc6520d2d4
Summary:
I need to do some refactoring of what happens when a ReactRootView is attached/detached from the window. In doing so, I found ReactRootView is way more complicated than it needs to be and very hard to understand. This simplifies it while maintaining functionality.
Basically:
- When you start a react application, if the root view is measured, we attach it to the instance.
- If it wasn't measured, we do nothing
- In onMeasure, if we have a ReactInstanceManager, but are not attached to it, attach to it.
None of this needs to depend on whether we're attached to the window or whether an attach is scheduled afaict.
Reviewed By: dmmiller
Differential Revision: D3260056
fb-gh-sync-id: 974c19ed75a07f83299472f75346bd6be7414128
fbshipit-source-id: 974c19ed75a07f83299472f75346bd6be7414128
Summary:
This adds support for pagingEnabled to the HorizontalScrollView.
This is an initial implementation.
Because Android doesn't provide great details about what is happening with a scroll view after you are done touching it, we have some post touch handling. This is kicked off either by touch up or a fling call.
Once we are doing that handling, we start a runnable that basically checks if we are still scrolling. If we are, we just schedule that runnable again and check a frame later. If we are done scrolling (no onScrollChanged since we last fired), we could be in one of two states, the fling is done or we are done snapping to the page boundary. If we are in the fling done case, we then check if we need to scroll to a page boundary. If so, we call smoothScrollTo and schedule ourself to check onScroll events again until done with that scroll. If we are done with both (either we only did momentum scroll or we did that and then snapped to page), we can then fire the final event and stop checking. This logic is all in handlePostTouchScrolling.
Because of the decision to only do page scrolling after momentum ends, we do allow you to scroll through with momentum a number of pages and the transition can be a little strange where it stops a sec and then slides to be page aligned. As a follow up, we can probably smooth that up by changing the value we pass to super.fling() that would adjust it to be let momentum carry it to the page boundary.
Reviewed By: weicool
Differential Revision: D3207608
fb-gh-sync-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
fbshipit-source-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
> From the existing documentation, it's not clear how one would make use of the highlightRow attribute of ListView.renderRow. Special thanks to halilb for his assistance.
Example: When "Adding a function to do X", explain why it is necessary to have a way to do X.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
> Here's a screenshot of the UIExplorer with a row highlighted (using the FB Blue Color)
> <img width="466" alt="2016-03-16_1944" src="https://cloud.githubusercontent.com/assets/1640318/13835020/49b5b38c-ebb1-11e5-98fa-17201fd3db92.png">
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTIN
Closes https://github.com/facebook/react-native/pull/6495
Differential Revision: D3264092
Pulled By: nicklockwood
fb-gh-sync-id: 9608e8a66387f527b872928a3595ca4d17736b82
fbshipit-source-id: 9608e8a66387f527b872928a3595ca4d17736b82
Pieter De Baets
Nick Lockwood
Jesse Sessler
Alexander Blom
Will Fong
Andy Street
UnoDeTantos
MIYOKAWA, Nobuyoshi
Janic Duplessis
Alessandro Nadalin
wusuopu
Ben Alpert
Milan Pavlik
Sokovikov
prabakarviji
David Aurelio
Adam Comella
Fred Liu
Joel Marcey
Jeff Bowen
Eric Vicenti
Russell Porter
Sebastian Gronewold
Konstantin Raev
Hedger Wang
Jimmy Mayoukou
Christine Abernathy
Damien Varron
Dave Miller
Chris Geirman
Adam Ernst
