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:
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:
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:
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:
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
Summary:
Allow changing distanceFilter after _locationManager has been initialized.
There is 2 reasons for this PR:
- When calling `getCurrentPosition`, `_observerOptions` is possibly not set properly ( as it is set only in `startObserving`), in this case it would have default values so `distanceFilter` will be 0 in this case ( which can be the right value but we should be more explicit about it, `kCLDistanceFilterNone` or `RCT_DEFAULT_LOCATION_ACCURACY`):
<img width="961" alt="screen shot 2016-04-14 at 8 44 09 pm" src="https://cloud.githubusercontent.com/assets/159813/14551465/6aa8791a-0288-11e6-9c98-1687357f8c2a.png">
- Another issue is that `distanceFilter` is cached so it can't be changed afterwards:
```javascript
let options;
options = {
enableHighAccuracy: true,
distanceFilter: 20,
};
this.watchId = this.geolocation.watchPosition(
() => { },
() => { },
options,
);
// => sets distanceFilter to 20
this.geolocation.clearWatch(this.watchId);
options = {
enableHighAccuracy:
Closes https://github.com/facebook/react-native/pull/6987
Differential Revision: D3258956
fb-gh-sync-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
fbshipit-source-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
Summary:
Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
Reviewed By: javache
Differential Revision: D3258232
fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
Summary:
This change fixes an issue with calling `setValue` for natively driven nodes. As of now an attempt to call this method from JS would trigger an error "Attempting to run JS driven animation on animated". That is because for natively animated nodes we don't allow for `setNativeProps` to be executed and method `_flush` is now responsible for triggering that call. To fix the issue we add extra flag to `_updateValue` method that indicates if we should be "flushing" updated values using `setNativeProps` and we pass an appropriate value depending on the status of the node (native/non-native). Note that in animation callback we always pass `true` - that is because natively driven animations will never call into that callback.
**Test Plan**
Run JS tests: `npm test Libraries/Animated/src/__tests__/AnimatedNative-test.js`
Closes https://github.com/facebook/react-native/pull/7138
Differential Revision: D3257696
fb-gh-sync-id: 13ec26bc36b56b3208f4279a95532bbe60551087
fbshipit-source-id: 13ec26bc36b56b3208f4279a95532bbe60551087
Summary:
NSMutableURLRequest appears to be running `[headerValue count]` on every value of the NSDictionary that `allHTTPHeaderFields` is set to, meaning that any `null` values passed to headers in an XHR throw an exception. This differs from the implementation of XHR in browsers, which just ignore any `null` values for headers.
PR doesn't currently include tests, happy to add those if this is something you'd consider merging
Closes https://github.com/facebook/react-native/pull/6903
Differential Revision: D3256727
fb-gh-sync-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
fbshipit-source-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
Summary: This adds a new SceneView with a shouldComponentUpdate policy of only re-rendering when the scene's state changes. This allows avoidance of extra re-renders. Results in a much smoother back-swipe gesture because we no longer re-render scenes as we transition from gesture to animation.
Reviewed By: hedgerwang
Differential Revision: D3219545
fb-gh-sync-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
fbshipit-source-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
Summary:
This pull request corrects a bug found in `RCTAssetsLibraryRequestHandler` which used the asset UTI as the mimeType.
The code for finding the mimeType is based on the implementation used in `RCTImageLoader` and `RCTImageUtils`.
Closes https://github.com/facebook/react-native/pull/7349
Differential Revision: D3252796
Pulled By: nicklockwood
fb-gh-sync-id: b9303a99333e4744dfe23045f4a2755307305772
fbshipit-source-id: b9303a99333e4744dfe23045f4a2755307305772
Summary:
Hi,
This PR Solves this issue #3083.
This PR solves the problem of default color on TabBar being always grey. Which looks great if the barTintColor is unchanged. However if we set the barTintColor to something else (like blue in example) text and icons become quite unreadable.
Commit (c206417) - Enable setting color of unselected tabs
Solves this issue with a prop (unselectedTintColor) on TabBarIOS to which you just pass a color like you can for barTintColor and tintColor.
This leaves us with a result that is on second picture. Notice the color of text on tabs.
Or change it to yellow for demonstrating purposes
.
Run the Movies example (UIExplorer is broken atm) and make sure there are no errors.
Closes https://github.com/facebook/react-native/pull/6255
Differential Revision: D3037227
Pulled By: mkonicek
fb-gh-sync-id: bcf1350ae7a6e92c77d3a87fc9d6e42eb93cb9b9
fbshipit-source-id: bcf1350ae7a6e92c77d3a87fc9d6e42eb93cb9b9
Summary:
transformMatrix only worked on iOS and there is an equivalent API that (mostly)
works cross platform.
decomposedMatrix could technically be passed on Android but it wasn't document and explicitly flagged as not working.
My goal is to deprecate both uses and then the only supported API is the `transform: [{ matrix: ... }]` form.
The only difference is that on Android the matrix gets decomposed.
Currently there is some special cased magic that renames transform -> transformMatrix or decomposedMatrix depending on platform.
https://github.com/facebook/react/blob/master/src/renderers/native/ReactNative/ReactNativeAttributePayload.js#L50
Therefore I'm adding an alias for both native platforms called just "transform".
Next I'll swap over the JS to always target the name "transform". The only difference is how the value is marshalled over the bridge in processTransform.
To do this, I have to clean up a few callers. Mostly that's just swapping to the new API.
For buildInterpolator this is a bit trickier but this fixes it for all our use cases (which is only the Navigator in AdsManager).
Reviewed By: vjeux
Differential Revision: D3239960
fb-gh-sync-id: 838edb6644c6cdd0716834f712042f226ff3136f
fbshipit-source-id: 838edb6644c6cdd0716834f712042f226ff3136f
Summary:
Reduce re-renders by only looking at `props.data` that we're actually going to render and tracking if `this._rowFrames`
is dirty.
Differential Revision: D3195163
fb-gh-sync-id: 1e17ab410a312a37d4a93b84ea51ca32c3ede839
fbshipit-source-id: 1e17ab410a312a37d4a93b84ea51ca32c3ede839
Summary:
Added support for setting an optional badge icon number and alert action when using local notifications.
Closes https://github.com/facebook/react-native/pull/2931
Differential Revision: D3212448
Pulled By: mkonicek
fb-gh-sync-id: 063efcdd259b2a43f39812f57a71e8489ab33653
fbshipit-source-id: 063efcdd259b2a43f39812f57a71e8489ab33653
Summary: This adds support for UIManager.setChildren on Android like D2757388 added for iOS.
Reviewed By: andreicoman11
Differential Revision: D3235369
fb-gh-sync-id: b538556ec4abdb606f9be26d1b74734046bca0cd
fbshipit-source-id: b538556ec4abdb606f9be26d1b74734046bca0cd
Summary:
Useful to know what the default value without having to dig into the library code.
Closes https://github.com/facebook/react-native/pull/7247
Differential Revision: D3228728
Pulled By: mkonicek
fb-gh-sync-id: 433ca41d5395bbfb0c4887641a9e8b99c87b5e2b
fbshipit-source-id: 433ca41d5395bbfb0c4887641a9e8b99c87b5e2b
Summary:
So far, XHR only supports a few `onfoo` event handlers, not the entier `EventTarget` interface (`addEventListener`, `removeEventListener`). It also doesn't support the `upload` object on Android -- for no good reason. Even if we don't send any events there yet, there's no reason we have to break consuming code that wants to register an event handler there. This PR rectifies all that.
Fortunately, adding proper `EventTarget` support is very easy thanks to `event-target-shim`. We already use it in our WebSocket implementation. It transparently handles the `addEventListener('foo', ...)` as well as `onfoo` APIs, so when you dispatch an event on the event target, the right handlers will be invoked. The event object is wrapped so that `event.target` is set properly. Basically, it's a super easy way to make us conform to the spec.
Also added a bit of polish here and there, using ES2015 class property goodness to consolidate a lot of Flow property definitions with the corresponding property initializers.
**T
Closes https://github.com/facebook/react-native/pull/7017
Reviewed By: fkgozali
Differential Revision: D3202021
Pulled By: martinbigio
fb-gh-sync-id: 2b007682074356c75c774fab337672918b6c4355
fbshipit-source-id: 2b007682074356c75c774fab337672918b6c4355
Alexander Blom
Pieter De Baets
UnoDeTantos
Janic Duplessis
Alessandro Nadalin
wusuopu
Ben Alpert
Adam Comella
Fred Liu
Eric Vicenti
Sebastian Gronewold
Hedger Wang
Jimmy Mayoukou
Dave Miller
Chris Geirman
Jean-Richard Lai
Nick Lockwood
Konstantin Raev
David Aurelio
Krzysztof Magiera
Griffin Smith
Spencer Ahrens
Yedidya Kennard
Urban Cvek
Jason Prado
Joshua Pinter
Sebastian Markbage
Charles Dick
alvaromb
Jesse Sessler
Philipp von Weitershausen
