Summary:
public
- Intro new back action
- Add support in the two main reducers
- Use it in examples to support Android back button
- Disable NavigationCard gestures on Android
Reviewed By: hedgerwang
Differential Revision: D2914154
fb-gh-sync-id: d4dce6538e19613a2ffca21e2e3b2ecaded3d5dc
shipit-source-id: d4dce6538e19613a2ffca21e2e3b2ecaded3d5dc
Summary:
I started working on improving the `StatusBar` API and make it work on Android. I added support for `setColor`, `setTranslucent` (the status bar is still visible but the app can draw under) and `setHidden` on Android. Looking for feedback on how to improve the API before I put more time on this :).
Right now I went for a cross platform API and functions that don't exist on a platform are just a no-op but I'm not sure it is the best choice since at the moment what is supported is very different between both platforms. I was wondering what you guys think and if it would be better off as 2 different modules.
It is also possible to port some of the features I added for Android to iOS even if there is no 'standard' way to do it. Like `setColor` could be implemented by drawing a colored view under the status bar and translucent by adding/removing some padding.
Closes https://github.com/facebook/react-native/pull/5360
Reviewed By: svcscm
Differential Revision: D2840417
Pulled By: nicklockwood
fb-gh-sync-id: 5c8d988bccf8035341f0efe27e54dd8402c18d24
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:
Allows you to do:
```
var { RecyclerViewBackedScrollView } = require('react-native')
```
Rather than:
```
var RecyclerViewBackedScrollView = require('react-native/Libraries/Components/ScrollView/RecyclerViewBackedScrollView')
```
Also...
- Export `ScrollView` by default rather than `UnimplementedView` for `RecyclerViewBackedScrollView` on iOS -- this makes it easier on the user, so you don't have to always do a conditional for: `if IOS then use ScrollView else use RecyclerViewBackedScrollView`. I can't think of a case where this would lead to undesirable behaviour.
- Add `RecyclerViewBackedScrollView` to `MainReactPackage`
- Fix an issue with `MapView` that threw a red-screen when trying to access constants on Android because there is no `MapView` in open source and MapView.js doesn't have a platform extension.
Closes https://github.com/facebook/react-native/pull/4514
Reviewed By: svcscm
Differential Revision: D2753466
Pulled By: mkonicek
fb-gh-sync-id: 0b6e2133975c911d5117e7531cb9093faf314c52
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:
The naming "Layout" is an Android-specific thing and not useful in JS. Let's stay consistent with naming like "ScrollView", "MapView" etc.
public
Reviewed By: bestander
Differential Revision: D2723163
fb-gh-sync-id: 6b86e5a649254c41e9d6b0ef6f1fe2ff4b9f3e9a
Summary: Move the code to the github folder, add more docs and improve the example.
We might want to merge this with `LinkingIOS` later (it has the same functionality
plus support for deep links) but want to see how people use the `IntentAndroid`
API first (and what other methods we should add) to have more data points.
public
Reviewed By: lexs
Differential Revision: D2646936
fb-gh-sync-id: 751f35784d387efcd031f9b458821cdfde048a54
This is an early release and there are several things that are known
not to work if you're porting your iOS app to Android.
See the Known Issues guide on the website.
We will work with the community to reach platform parity with iOS.
Brent Vatne
Eric Vicenti
Janic Duplessis
Konstantin Raev
Martin Konicek
Sokovikov
Andreas Drivenes
tantan