Summary:
`setAnimatedNodeValue` currently does not update views if there is no animation currently running. This simply updates the view immediately instead of relying on the animation loop. Extracted it out in a function to be able to use it for native `Animated.event` too.
**Test plan**
Tested this in an app using native driven animations with `NavigationCardStackPanResponder` that makes use of `setValue` to update `Animated.Values` during the back gesture.
Closes https://github.com/facebook/react-native/pull/10643
Differential Revision: D4106346
fbshipit-source-id: 7c639e03ded87058354340f1179f8b75be423e84
Summary:
This is **a critical issue**.
The issue arises when incremental networking is enabled from JS by setting `onprogress` or `onload` on an `XMLHttpRequest` object.
The results:
![example1](https://cloud.githubusercontent.com/assets/2270433/18829964/5a54ff30-83e7-11e6-9806-97857dce0430.png)
![example2](https://cloud.githubusercontent.com/assets/2270433/18829966/5bf40a66-83e7-11e6-84e6-9e4d76ba4f8b.png)
Unicode characters get corrupted seemingly in random. The issue is from the way Unicode character parsing is handled in `RCTNetworking.mm`. When incremental networking is enabled, each chunk of data is decoded and passed to JS:
```objective-c
incrementalDataBlock = ^(NSData *data, int64_t progress, int64_t total) {
NSString *responseString = [RCTNetworking decodeTextData:data fromResponse:task.response];
if (!responseString) {
RCTLogWarn(@"Received data was not a string, or was not a recognised encoding.");
return;
}
NSArray<id> *responseJSON = @[task.requestID, responseString, @(prog
Closes https://github.com/facebook/react-native/pull/10110
Reviewed By: yungsters
Differential Revision: D4101533
Pulled By: fkgozali
fbshipit-source-id: 2674eaf0dd4568889070c6cde5cdf12edc5be521
Summary:
Now that native animations for opacity and springs have landed in both iOS and Android, we can enable native animations both for TouchableBounce and TouchableOpacity.
Closes https://github.com/facebook/react-native/pull/10583
Differential Revision: D4099819
Pulled By: jingc
fbshipit-source-id: de70f8732b84d4caf0e4adfb2ad0e95b3de5da0f
Summary:
Now that native animations for opacity and springs have landed in both iOS and Android, we can enable native animations both for TouchableBounce and TouchableOpacity.
Closes https://github.com/facebook/react-native/pull/10583
Differential Revision: D4099819
Pulled By: lacker
fbshipit-source-id: 247d7bff9a778e520af764f571caf6286b4a5749
Summary:
In the `NetworkingModule.java`, `header.getString(1)` was
called, so the value must be String type.
FIX#10198
Closes https://github.com/facebook/react-native/pull/10222
Differential Revision: D4080319
Pulled By: lacker
fbshipit-source-id: 85234a2bbf90e5b9e0e65ceadbfabb330b2d1322
Summary:
Fixes#7996.
Test included.
Not sure this is the best way to go, just a simple solution since the TouchableNativeFeedback is trying to clone the component with a Native component, then seems like it should wrap it with Animated.Component if the incoming child was.
Closes https://github.com/facebook/react-native/pull/10081
Differential Revision: D4073603
fbshipit-source-id: 7827198a3e4697c14e37762cdca93f46a5a1d716
Summary:
This diff adds support for native spring animations on iOS. This overlaps some spring work done by kmagiera on the Android side of things.
**Test plan (required)**
Run UIExplorer NativeAnimated examples before and after - compare the results. Pay special attention to the spring examples.
Closes https://github.com/facebook/react-native/pull/9048
Differential Revision: D4056088
Pulled By: foghina
fbshipit-source-id: a593408cb61cb850572bab4a0884f7157cece656
Summary:
This diff adds support for clamping on iOS. It separates out code originally submitted in #9048.
Test plan (required)
Run UIExplorer NativeAnimated examples before and after - compare the results. Pay special attention to the new clamped spring example.
Closes https://github.com/facebook/react-native/pull/9625
Differential Revision: D4053231
fbshipit-source-id: 29048de444ff5f6d7fe7dce7897399b483ee6d2d
Summary:
The `position` animated value is used for scale, translateX, and tranlateY
animations, which are all supported by NativeAnimatedHelper. Unfortunately,
native animations are incompatible with JS driven animations, which the
`enableGestures` flag enables.
This diff therefore conditionally enables native animations based on the native
module's precense, and the state of `enableGestures`.
Ideally the animations would be refactored so that they could fully leverage
native animations, as they are far superior for navigational components.
Reviewed By: oyvindkinsey
Differential Revision: D4020977
fbshipit-source-id: 8e1d015c4d41fee103469f6f9ffa02ff4f1f5517
Summary:
This brings RN Navigator to add HorizontalSwipeJumpFromLeft animation.
HorizontalSwipeJumpFromRight has been implemented but FromLeft version of SwipeJumpAnimation hasn't been there.
Closes https://github.com/facebook/react-native/pull/10406
Differential Revision: D4035212
fbshipit-source-id: edcbae18148e533b02a7d056de03154fb86280d0
Summary:
We had a classic integer underflow problem here. Before we would let you type endlessly when the text already exceeded the TextInput maxLength, now we only let you erase characters.
There is still a small problem with the TextInput: how do you handle when the value (set from JS) exceeds the maxLength? This could happen pragmatically, just by passing in a very large value or when changing maxLength (e.g. when changing from 4 to 3 digits in the case of a AMEX security code -> VISA security code).
Me and achen1 discussed firing onChange in these cases and truncating the number manually (to ensure JS's data model) was aware of the change but it seemed fraught with bugs and general weirdness in what the caller would expect to happen.
Reviewed By: javache
Differential Revision: D3991210
fbshipit-source-id: dc401c4a7aefe09fa749cd1168d36343d39dc196
Summary:
With nested NavigatorIOS components:
```
<NavigatorIOS initialRoute={{
component: ComponentWithAnotherNavigatorIOSInSubtree
title: 'xyz'
}}>
```
Navigating (via push etc.) in ComponentWithAnotherNavigatorIOSInSubtree's `navigator` caused an invariant error, making apps with this structure unusable. The reason was that the `navigationComplete` nativeEvent was being propagated to the outer Navigator due to React's automatic event bubbling, making the outer NavigatorIOS incorrectly think it was holding navigation stack state inconsistent with its native UINavigationController.
Concretely, if the outer navigation stack is empty except for its initial state and something is pushed onto the inner stack, the outer NavigatorIOS suddenly complains that it has 2 items on its stack rather than 1. In reality, the outer Navigator still only has 1 item on its stack but the inner Navigator's event (containing information about the inner Navigator) incorrectly bubbles up and reaches the outer Navigator too.
Closes https://github.com/facebook/react-native/pull/9828
Differential Revision: D4030167
Pulled By: ericvicenti
fbshipit-source-id: d04de3d5b70b4862a78610c92701ebdab2b047dd
Summary:
- Consolidate common code in iOS and tvOS test scripts
- Start the packager before starting tests, to improve reliability
- Increase timeout value in RCTTestRunner.m
Closes https://github.com/facebook/react-native/pull/10378
Differential Revision: D4028364
Pulled By: bestander
fbshipit-source-id: 24c2124a1c62643a02f0668b60a67b971e08d1a3
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**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.
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/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10413
Differential Revision: D4028108
fbshipit-source-id: 99a864dfda578d640f582b296583591415ba26cd
Summary:
JS API very similar to web workers and node's child process.
Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.
I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.
![screen shot 2016-09-06 at 10 28 23](https://cloud.githubusercontent.com/assets/7275322/18268669/b1a12348-741c-11e6-91a1-ad39d5a8bc03.png)
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary: Fixes remaining references to `ReactElement` that did not already have `React` in scope.
Reviewed By: bestander, vjeux
Differential Revision: D4022022
fbshipit-source-id: 4aeacee0cdbb2c825feba10282208316d064c578
Summary:
after adding new parameter options in alert method, parameter type is the 5th.
Closes https://github.com/facebook/react-native/pull/10370
Differential Revision: D4021511
Pulled By: javache
fbshipit-source-id: 09476162b879d2081f0c0ac95260e673327871b8
Summary:
on iOS, if you pull photo from one of user's custom album, the app crashes on the assertion `RCTAssert(resolvedPromise == NO, @"Resolved the promise before we finished processing the results.");` . assertion that was assumed to never been reached.
According to iOS doc, the enumerateGroupsWithTypes `usingBlock` block is called with `group=nil` when the iteration is over, but in current react-native implementation, it is stopping in other circumstance (because the `else` case) which is probably a mistake.
You have probably never seen the bug because you didn't tried to use getPhotos with something else than the pre-defined groups, but it should be possible to do so *(and it seems to work fine as soon as I included my fix. Later I should provide a PR that includes a way to list user groups :) but at least I need this to gets in, otherwise it crashes)*.
For instance, User have a Photo Folder (or "album", whatever you call it) called "Instagram", when I call `CameraRoll.getPhotos({ groupName: "Instagram",
Closes https://github.com/facebook/react-native/pull/10272
Differential Revision: D4009342
Pulled By: javache
fbshipit-source-id: a73ca828133b4f0d880c229f9b675538854020de
Summary:
Grabbing the port from Bundle URL allows concurrent Remote JS Debugging using the same machine with running multiple instances of packager on different ports.
This improves the developer experience when developing and debugging cross-platform components.
Closes https://github.com/facebook/react-native/pull/10007
Differential Revision: D4008630
Pulled By: javache
fbshipit-source-id: fcf8495e564fd9ac7baf26a87ed3904898132aa0
Summary:
Warning: bind(): You are binding a component method to the component.
React does this for you automatically in a high-performance way, so you can safely remove this call. See TouchableOpacity
Closes https://github.com/facebook/react-native/pull/10349
Differential Revision: D4008552
Pulled By: javache
fbshipit-source-id: d98fe9a0d694dee74ea872e51b02fbd75a133e43
Summary:
Replace `<br />` with `{'\n'}` in order to provide an example of working line breaks in React Native.
Closes https://github.com/facebook/react-native/pull/10323
Differential Revision: D3995544
Pulled By: JoelMarcey
fbshipit-source-id: 8404db8f23eeb606a5a5ed98ca1b7f9b20917e46
Summary:
> What existing problem does the pull request solve?
Purely a documentation/example error. Was misled/wasted time debugging because of this issue.
Description:
`dx`/`dy` are zero in onPanResponderGrant, not `x0`/`y0`. `x0`/`y0` will be the coordinates relative to the granted element, which are rarely zero.
Closes https://github.com/facebook/react-native/pull/9984
Differential Revision: D4001603
Pulled By: hramos
fbshipit-source-id: 32580795f62394585ccfb8f9a2ae65b0b72add69
Summary:
This just cleans up the work done in #7219 by adamterlson based on grabbou's feedback
Closes https://github.com/facebook/react-native/pull/10337
Differential Revision: D4001540
Pulled By: javache
fbshipit-source-id: c73b5fef912fa71d1d988dae41094c9c46dc610b
Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary: Instead of sending a list of modules over to JS on startup (and actually blocking script execution) instead provide a proxy object that constructs each of these lazily.
Reviewed By: lexs
Differential Revision: D3936979
fbshipit-source-id: 71bde822f01eb17a29f56c5e60e95e98e207d74d
Summary:
We got a report that onContentSizeChange function was being called with an object instead of a number for width, sometimes. Upon debugging, it looked like the param being passed in was a native event wrapper. Tim eventually figured out that this is because there's a TextInput child, and the event bubbles: diffusion/FBS/browse/master/fbobjc/Libraries/FBReactKit/js/react-native-github/Libraries/Text/RCTTextViewManager.m;afbdef32df50$39
Because ScrollView just passes all its props down to the component it eventually renders (RCTScrollView on iOS), the TextInput event bubbles up and triggers the onContentSizeChange prop that was passed in directly, instead of going through the layer in ScrollView that normally unpacks width/height from the native event: diffusion/FBS/browse/master/fbobjc/Libraries/FBReactKit/js/react-native-github/Libraries/Components/ScrollView/ScrollView.js;247ddb2022151b68dd9f83a888b6e0ec9923737a$413-416
Overriding the prop before passing down to RCTScrollView will break that chain, so that the event will continue to bubble but it won't find the incorrect prop from ScrollView.
Reviewed By: yungsters
Differential Revision: D3999689
fbshipit-source-id: d6c3bf711969b3e1c6fc1e51fd44c6894910bc3d
Summary:
In the `Additional Scenes` section, the `TouchableHighlight` component is used, but is not present in the import statement.
This is confusing and results in a `Can't find variable: TouchableHighlight` error.
This PR attempts to correct this confusion.
Closes https://github.com/facebook/react-native/pull/10276
Differential Revision: D3997058
Pulled By: hramos
fbshipit-source-id: 22ebf39cd39d8a76427c89cecc774ff9aef2c3c8
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**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.
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/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10299
Differential Revision: D3997827
Pulled By: ericvicenti
fbshipit-source-id: a98e112d95015842936a9d2bdc89553772ba49c2
Summary:
Button is an important component to help the community get onboarded with RN quickly, so the first few minutes of a developer's experience is not spent formatting a simple button component.
In my opinion, `<Button />` should be seen as a "lowest common demoniator" component, rather than "the one button to rule them all". In other words, we should only support features in Button that will work on any platform. We should encourage people to fork Button if they need to add specific features to it, rather than trying to twist and bloat this component until it supports everything.
These platform imitations may not have the perfect constants just yet, but they are good enough to make a user feel at home in the app, without any modification. The community can help tweak the final formatting to make them look just right- PRs are welcome!
Reviewed By: frantic
Differential Revision: D3929041
fbshipit-source-id: 3785fb67472a7614eeee0a9aef504c0bdf62ede7
Summary:
This is a critical change and should be pushed to stabel asap
The reason for the pull request is to prevent crashes that can occure if the function relativeKeyboardHeight(keyboardFrame: ScreenRect) got null as an input variable which sometimes does happen.
Closes https://github.com/facebook/react-native/pull/10287
Differential Revision: D3988359
Pulled By: bestander
fbshipit-source-id: 0d1052b590b2684907ea6f7d6b4fe9b89989d4dd
Summary:
Not much to add. My OCD spotted this 😄
Closes https://github.com/facebook/react-native/pull/10275
Differential Revision: D3984542
Pulled By: hramos
fbshipit-source-id: 2de8c8f7f5c2c518e0ec5277087095e0553c72d6
Summary:
* Motivation *
Second PR for Apple TV support.
* Test plan *
Apple TV tests have been added to scripts/objc-test.sh
Closes https://github.com/facebook/react-native/pull/10227
Differential Revision: D3974064
Pulled By: javache
fbshipit-source-id: 36dffb4517efa489e40fa713a30655d1d76ef646
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**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.
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/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10157
Differential Revision: D3974091
Pulled By: javache
fbshipit-source-id: c756fb82422253bb9098c37fbcb5637e58e53340
Summary:
These are caused by new [syntax checking](1285131e3e/CHANGELOG.md (v6113-2016-10-01)) introduced by babylon.
"The single rest at the end only applies to binding `let { x, ...y } = obj;` and assignment `({ x, ...y } = obj).`"
I'd say this really should be cherry picked into the stable branch.
**Test plan**
1. install babylon@6.11.3
2. see that things break
3. apply patch
4. things work
5. make sure all instances were fixed (I used `\.\.\..*,.*\n.*=` in IntelliJ regex format—find all ... followed by newline followed by =)
Issue #10199
Closes https://github.com/facebook/react-native/pull/10200
Differential Revision: D3974066
Pulled By: javache
fbshipit-source-id: 3f3c1e9df01a3b3bdd61dd3863416c638d3ed98d
Summary:
There is no "window" in react native. And by the way fix the indent.
Closes https://github.com/facebook/react-native/pull/10182
Differential Revision: D3974090
Pulled By: javache
fbshipit-source-id: e0e47e15364abff5bcb136d988e234fc8e1f0a8b
Summary:
Update to docs to indicate that TouchableHighlight must have exactly one child (i.e. not zero or more than one). Previously it was only indicated that it cannot have more than one.
Closes https://github.com/facebook/react-native/pull/10244
Differential Revision: D3970841
fbshipit-source-id: f1c4c223cfaf150fec9bbae1041567d0c81eb63b
Summary: Currently, for short touches (under 130ms by default), we don't trigger the highlight effect. This diff makes it so that if we're not highlighted when we invoke onPress, we highlight.
Reviewed By: astreet
Differential Revision: D3932019
fbshipit-source-id: c0ff7d4c646890507ce510f51c279c88aeba66ae
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
Is okay to remove this link? It seems that we don't have the Navigator Comparison anymore.
Closes https://github.com/facebook/react-native/pull/10186
Differential Revision: D3951863
Pulled By: mmmulani
fbshipit-source-id: 170f4cc9288f84d88c3b607e3a1a85619d9776c8
Summary:
Very similar to https://github.com/facebook/react-native/pull/9600.
Does not trigger on DEV, but there are two inspectors: one underneath and one
above the modal. This looks like something we should fix, but the only solution
I've come up with so far was to mangle the event that AppContainer listens to, so that
only the AppContainer in the modal responds to it. This seems pretty ugly, I'd
rather look for something else. Wdyt?
Reviewed By: frantic
Differential Revision: D3937096
fbshipit-source-id: a6e648b6d583088514d6ba8df7851f9a8ef48f74
Summary: Provide a base `HeadlessJsTaskService` class that can be extended to run JS in headless mode in response to some event. Added `HeadlessJsTaskEventListener` for modules that are interested in background lifecycle events, and `HeadlessJsTaskContext` that basically extends `ReactContext` without touching it. The react instance is shared with the rest of the app (e.g. activities) through the `ReactNativeHost`.
Reviewed By: astreet
Differential Revision: D3225753
fbshipit-source-id: 2c5e7679636f31e0e7842d8a67aeb95baf47c563
Summary:
Simple and elegant. Now someone can dismiss a keyboard in a way that makes sense.
```js
import { Keyboard } from 'react-native'
// Hide that keyboard!
Keyboard.dismiss()
```
+ docs
Closes https://github.com/facebook/react-native/pull/9925
Differential Revision: D3935357
fbshipit-source-id: ecd2fb5c72c4dd769951d308e9bb6ee5d888052a
Summary:
This PR is related to the multitude of crashes (#10016, #9751, #9882).
From my understanding, we should be using a strong reference when calling `decodeImageData` or we could be calling the method on a deallocated instance.
PR #9751 have mitigated this by adding a fail-safe, but I think the culprint is the weak reference, which this PR fixes.
Tested on iOS only, since it doesn't touch Android.
Closes https://github.com/facebook/react-native/pull/10147
Differential Revision: D3938763
fbshipit-source-id: 7389d4ae7a98926014401a1fe0cbbdcdd5ee6a01
Summary: Changing from flex -> flexGrow on Scrollview caused some layouts to break due to having views below the scrollview. Adding flexShrink allows for the behavior again.
Reviewed By: blairvanderhoof
Differential Revision: D3936963
fbshipit-source-id: 0f43e6f5148918d3d431b98d26d185bbcc1548d0
Summary:
This changes modal behavior to resize when the keyboard appears/disappears.
Previously, the modal would not react in any way, or it would pan above to bring the
TextInput into view. Resizing is the correct behavior for android.
This is not trivial, as in, setting the flag, because of the combination of
react native laying out all views and the system reacting to the keyboard
appearance in a weird way. Namely:
- if `windowTranslucentStatus` is not set, the system will just call
`onSizeChanged` on the dialog's content view, and everything works nicely
- with `windowTranslucentStatus` set, the system will consider the dialog as a
full screen view that doesn't resize. In order for it to resize, the base
view of the layout needs to have
`setFitsSystemWindows(true)` called on it. This is needed, so that the system
can call layout on that base view with the new value of `paddingBottom` that
coincides with the height of the keyboard. Neat.
We fix this by wrapping our existing content view (mHostView) in a simple
FrameLayout that has `setFitsSystemWindows` set. That way, `mHostView` will have
`onSizeChanged` called on itself with the correct new size of the dialog.
This has the fortunate consequence of our layout now also getting `paddingTop` as the size of the
status bar, which means that we can remove the JS `top` hack in Modal, which
was necessary for no view getting drawn under the status bar.
This behavior is set as default, since that is the default correct Android behavior.
Reviewed By: astreet
Differential Revision: D3913784
fbshipit-source-id: 4378ada21f466dc7ac6e357abeca10b88009ca3f
Summary:
The Navigator component inconsistently emits the `willfocus` event.
While it is emitted in `Navigator#resetTo`, `Navigator#push`, `Navigator#pop` and event `Navigator#replaceAtIndex` it is not emitted from `Navigator#immediatelyResetRouteStack`. This leads to surprising inconsistencies when working with these events.
With the PR I suggest to emit the `willfocus` event before resetting the route stack.
Closes https://github.com/facebook/react-native/pull/10125
Differential Revision: D3931284
fbshipit-source-id: 6e4f45c6d38426bcd0acc8f8c39478524032a03a
Summary:
First commit for Apple TV support: changes to existing Objective-C code so that it will compile correctly for tvOS.
Closes https://github.com/facebook/react-native/pull/9649
Differential Revision: D3916021
Pulled By: javache
fbshipit-source-id: 34acc9daf3efff835ffe38c43ba5d4098a02c830
Summary:
Combining 2 animated values via addition, multiplication, and modulo are already supported, and this adds another one: division.
There are some cases where an animated value needs to invert (1 / x) another animated value for calculation. An example is inverting a scale (2x --> 0.5x), e.g.:
```
const a = Animated.Value(1);
const b = Animated.divide(1, a);
Animated.spring(a, {
toValue: 2,
}).start();
```
`b` will then follow `a`'s spring animation and produce the value of `1 / a`.
The basic usage is like this:
```
<Animated.View style={{transform: [{scale: a}]}}>
<Animated.Image style={{transform: [{scale: b}]}} />
<Animated.View>
```
In this example, the inner image won't get stretched at all because the parent's scaling gets cancelled out.
Also added this to native animated implementation.
Reviewed By: foghina, mmmulani
Differential Revision: D3922891
fbshipit-source-id: 32508956c4b65b2deb7574d50a10c85b4809b961
Summary:
This diff adds support for value offsets on iOS. It separates out code originally submitted in #9048.
Test plan (required)
Set up an animation with an offset, and `useNativeModule: true`. Compare results with `useNativeModule: false`.
Closes https://github.com/facebook/react-native/pull/9627
Differential Revision: D3924410
fbshipit-source-id: 8177a25a5f6b9e33f00ea66143c782aeea24507d
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
_renderScene would unnecessary test if `this.state.transitionFromIndex != null` twice.
The left side and right side of the 'or' statement would always be the same.
For cleaner code I suggest to remove it.
Closes https://github.com/facebook/react-native/pull/10042
Differential Revision: D3923058
fbshipit-source-id: 7466c1f0f24eac3f9f296debd9a5e9f5320aea28
Summary:
The suppression comment was not formatted correctly and thus not
used.
Closes https://github.com/facebook/react-native/pull/10076
Differential Revision: D3917036
fbshipit-source-id: 92927993fb7223dc131d82096ca92017aea5f1aa
Summary:
Hi there,
when using the ScrollView component with `onScroll` and `scrollEventThrottle = 0` as it is documented in [react-native/docs/scrollview](https://facebook.github.io/react-native/docs/scrollview.html#scrolleventthrottle) this message will appear unnecessary.
This happens because `!this.props.scrollEventThrottle` is `true` when the value is `0`.
So I changed it to `this.props.scrollEventThrottle == null`. Now it is `false` when the value is `0`.
Closes https://github.com/facebook/react-native/pull/10038
Differential Revision: D3909323
fbshipit-source-id: 3c701f23708b64576a8c9f47e140d87159087894
Summary: If a user scrolls the `SwipeableListView`, any open row(s) will close.
Reviewed By: furdei
Differential Revision: D3903787
fbshipit-source-id: efd9ae896ba50ad6e83e72d52bc1f5c0c35efd61
Summary:
Fixes an issue where location request timeout errors always reported "Unable to fetch location within **0s**".
Previously we had `@"Unable to fetch location within %zds.", (NSInteger)(timer.timeInterval * 1000.0)` but from the [NSTimer.timeInterval docs](https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/#//apple_ref/occ/instp/NSTimer/timeInterval) "If the receiver is a non-repeating timer, returns 0 even if a time interval was set.".
Change to use `request.options.timeout` instead, which is a `Double` defaulting to `INFINITY`. Tested on an iOS simulator.
Closes https://github.com/facebook/react-native/pull/9888
Differential Revision: D3902788
Pulled By: javache
fbshipit-source-id: aef717d6c39f3177cb7056a17adc35c1bfd94132
Summary:
This fixes https://github.com/facebook/react-native/issues/9751
We were seeing the same issues as the original reporter.
I'm not an expert on this code, so apologies if it's naive, but we haven't seen the crash since making this change.
From my understanding of it, it seems like the `cancelLoad` block was being released before the block returned by `_loadImageOrDataWithURLRequest:` was called.
This PR checks the `cancelled` flag before calling `cancelLoad()`.
Closes https://github.com/facebook/react-native/pull/10016
Differential Revision: D3902723
Pulled By: javache
fbshipit-source-id: 75cd115e28694105c6fc29469986998ca0d4cd09
Summary:
While working on a feature in realized the buttons I built using `TouchableHighlight` were too dark when pressed.
When used white white views, `TouchableHighlight` produces the color `d4d5d5`. This is different from `dedede` which iOS uses.
Let's use opacity 0.85 instead of 0.8 to make the color match iOS. See a React Native view compared to iOS settings screen (same color for pressed items now): http://imgur.com/a/6CyL3
On Android, people should be using `TouchableNativeFeedback` everywhere.
Reviewed By: sahrens
Differential Revision: D3896168
fbshipit-source-id: a7dd12b4bde079b120faaffc36d25292533a2c6d
Summary:
In certain cases, if a navigation title is present in place of an empty nav stack, the first breadcrumb may steal part of the title's touch events since it's hardcoded to sit 1/4 from the left of the screen (for animation reasons). This diff fixes it, allowing titles on an empty nav stack to be entirely touchable while retaining all other breadcrumb functionality.
Also, applied some suggested lint changes.
Reviewed By: hedgerwang
Differential Revision: D3891909
fbshipit-source-id: 97d1fb3bba4e4118401d84cec2d8836b94bfde75
Summary:
Since API 18, Android locations have had the `isFromMockProvider()` function, to verify the validity of a provided location. This was one of many methods one could verify location data, but as of Marshmallow, the other ways of detecting if "Mock Locations" is on in developer settings has been deprecated or defunct.
This means some devices can only detect location mocking by exposing the method on the location object.
This change provides that exposure.
Closes https://github.com/facebook/react-native/pull/9390
Differential Revision: D3858205
Pulled By: bestander
fbshipit-source-id: 3bae429cc0596ea01926c5be204f4403e4a2414f
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Copy&paste from the example in the documentation will cause exception because there is no `AndroidPermissions` object. To avoid confusion we should refer to `PermissionsAndroid` instead since this is how this module is named in the API.
Closes https://github.com/facebook/react-native/pull/9956
Differential Revision: D3889080
Pulled By: hramos
fbshipit-source-id: 8f30d8f51ffee1321088a16a1b454ab163a746a2
Summary:
When debugging in VScode or nucleide using a nodejs environment rather than chrome, the JS sources are made to appear as if they exist on disk, rather than coming from a `http://` url. Prior to this change the packager would see these file paths and not know how to handle them.
Since all the application JS will be part of a bundle file, we can switch out the path to the bundle on the filesystem with paths to the bundle served by the packager, and things will work just as though it was debugging in chrome. We stop the replacement once we reach an internal module (`vm.js` in the case of both nucleide and VSCode) since that is the point when the execution switches from inside the app to the surrounding debugging environment.
I've verified that this fixes redbox stack trace symbolication in VSCode, and from my understanding of nucleide's debugging environment it should also work there without requiring any changes.
Closes https://github.com/facebook/react-native/pull/9906
Differential Revision: D3887166
Pulled By: davidaurelio
fbshipit-source-id: e3a6704f30e0fd045ad836bba51f6e20d9854c30
Summary:
Currently, it's hard to find out that it's very easy to use android toasts. The example is very complex and hard to grasp for a beginner. So, I propose to add an easy to understand example.
I'm sure the syntax of this PR is not really correct, it's just a start to show the kind of thing I propose.
Closes https://github.com/facebook/react-native/pull/9859
Differential Revision: D3886274
Pulled By: donyu
fbshipit-source-id: 15e693f5ddb1efea0fc6b7accfa688fd5f99a100
Summary:
This adds support for `Animated.event` driven natively. This is WIP and would like feedback on how this is implemented.
At the moment, it works by providing a mapping between a view tag, an event name, an event path and an animated value when a view has a prop with a `AnimatedEvent` object. Then we can hook into `EventDispatcher`, check for events that target our view + event name and update the animated value using the event path.
For now it works with the onScroll event but it should be generic enough to work with anything.
Closes https://github.com/facebook/react-native/pull/9253
Differential Revision: D3759844
Pulled By: foghina
fbshipit-source-id: 86989c705847955bd65e6cf5a7d572ec7ccd3eb4
Summary:
see also: eb3360b02a (commitcomment-19042340)
commit eb3360b02a recently break some third libraries that was (weakly) relying on traversing `animatedNode.refs.node` to get the original node of the decorated (animated) component (at least 2 libs: gl-react-native and react-native-material-kit).
Instead of now doing `animatedNode._component` (that might later break again), getNode() is a more 'public' solution for these third party.
as you expose a way to create an animated component (`createAnimatedComponent`) you sometimes still want a way to get the reference.
That way, third party components can continue providing some extra native methods to the animated version.
Closes https://github.com/facebook/react-native/pull/9944
Differential Revision: D3885973
Pulled By: foghina
fbshipit-source-id: 43ffdbfe7f9c52f5a1689e6a9a4052d4973f5c5f
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
Pulled By: fred2028
fbshipit-source-id: d346068734c5b987518794ab23e13914ed13b5c4
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
fbshipit-source-id: cab044cfdbe2ccb98e1ecd3e02ed3ceaa253eb78
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 3c365f9e6ef612fd9d9caaaa8c650e9702176e77
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 6077b0bcb68fe5ddd4aa22926acab40ff4d83949
Summary:
We've enabled getters in .flowconfig, so Flow will now understand react-native.js. We no longer need to maintain a separate file for Flow.
cc bestander
Closes https://github.com/facebook/react-native/pull/9892
Differential Revision: D3862560
Pulled By: bestander
fbshipit-source-id: 9efb66bc885dbac80c18b4b5e3cf5362495928a9
Summary:
Fixes https://github.com/facebook/react-native/issues/9216.
As nickzuber describes in #9216, conditional `Picker.Item` elements will lead to exceptions downstream when the `Picker` attempts to construct the collection of items.
[In the picker source](a2fb703bbb/Libraries/Components/Picker/PickerIOS.ios.js (L48-L53)) we can see that `child.props` is accessed when `child` has the potential to be an invalid `React` element.
```js
ReactChildren.forEach(props.children, function (child, index) {
if (child.props.value === props.selectedValue) {
selectedIndex = index;
}
items.push({value: child.props.value, label: child.props.label});
});
```
This change ensures the incoming element is valid
```diff
ReactChildren.forEach(props.children, function (child, index) {
+ if (!React.isValidElement(child)) {
+ return;
+ }
if (child.props.value === props.selectedValue) {
selectedIndex = index;
}
items.
Closes https://github.com/facebook/react-native/pull/9243
Differential Revision: D3847514
Pulled By: spicyj
fbshipit-source-id: f46fbd4b0f81de7a92e1ca3e60b5ed15a9cbbf78
Summary:
Explain that, unlike other APIs, geolocation follows the browser spec and is exposed through `navigator.geolocation` rather than as an `react-native` export.
This can be inferred from the example code but isn't otherwise stated in the docs. See also https://github.com/facebook/react-native/pull/9793
Closes https://github.com/facebook/react-native/pull/9810
Differential Revision: D3841341
Pulled By: javache
fbshipit-source-id: b1423e8bf7fb78c788f5cdc5630a4a948b8178c6
Summary:
Here's a little background. Resizing is inferior to scaling. See http://frescolib.org/docs/resizing-rotating.html#_
Currently, React Native has a heuristic to use resize when the image is likely to be from the device's camera. However, there may be other cases where a developer wants to use resize. For example, when the developer knows they'll be downloading a large image from a service but the image will be rendered at a small size on the device.
This change adds a `resizeMethod` prop to the `Image` component so developers can choose how Fresco resizes the image. The options are 'auto', 'resize', or 'scale'. When 'auto' is specified, a heuristic is used to choose between 'resize' and 'scale'. The default value is 'auto'.
**Test plan (required)**
In a small test app, verified that the `resizeMethod` prop properly influences the mechanism that is used to resize the image (e.g. resize or scale).
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9652
Differential Revision: D3841322
Pulled By: foghina
fbshipit-source-id: 6c78b5c75ea73053aa10386afd4cbff45f5b8ffe
Summary:
`Navigator` throws an error if using a custom `NavigationBar` component that does not have a `immediatelyRefresh` method present.
Closes https://github.com/facebook/react-native/pull/9438
Differential Revision: D3838928
Pulled By: mkonicek
fbshipit-source-id: 74d62ef09e179f457a4b14f8537dfaf0d4697322
Summary:
Fix for https://github.com/facebook/react-native/issues/9465
We are building a react-native based application which extensively uses WebSockets. The Android app crashes right after waking up being in suspended mode for a coupe of days and throws an exception:
"Cannot send a message. Unknown WebSocket id 1"
Before calling WebSocket.send(...) method from WebSocket.js we always check its readyState. I believe the problem is caused by not updating readyState if case of 'websocketFailed' event. this.close() cause the current used websocket ID to be removed from mWebSocketConnections HashMap (WebSocketModule.java), but readyState stays the same.
Closes https://github.com/facebook/react-native/pull/9487
Differential Revision: D3838675
Pulled By: mkonicek
fbshipit-source-id: e833cef9f1b94c6f7236077241cacf5a56f5824b
Summary:
Resolves#7081 by allowing iCloud to download photos not stored on the device.
**Test plan (required)**
1. Verified existing photos stored on the device still display.
2. Deleted my iCloud photo library from my phone and verified the image downloads and displays.
Closes https://github.com/facebook/react-native/pull/9530
Differential Revision: D3838470
Pulled By: mkonicek
fbshipit-source-id: 810830a4246714b6e166e4411f3fa848b1f1b71c
Summary:
JSC on iOS 8 and above includes TypedArrays so there's no need for the guard statement anymore since React Native officially does not support iOS 7 moving forward.
Closes https://github.com/facebook/react-native/pull/9780
Differential Revision: D3834979
Pulled By: mkonicek
fbshipit-source-id: 6e28a47702d6e3d604fedb9d2d00fe1c539a6926
Summary: Get rid of the old behaviour of JSON encoding in `nativeRequireModuleConfig` and consistently use the same names for function types "async/promise/sync"
Reviewed By: lexs
Differential Revision: D3819348
fbshipit-source-id: fc798a5abcaf6a3ef9d95bd8654afa7825c83967
Summary:
Hi!
I found problem with accessibilityLabel on PickerAndroid.
There's no value in content-desc attribute while accessibilityLabel is correct.
I found that accessibilityLabel is not propagated into native components via
native props.
This PR brings accessibilityLabel for PickerAndroid.
Without this solution my appium tests fails, for example:
My code:
```jsx
<Picker
style={this.props.style}
selectedValue={this.props.value}
onValueChange={this.onChange}
disabled={this.props.disabled}
accessibilityLabel="select_wineType">
// Chilren
</Picker>
```
```sh
✖ Error: element (~select_wineType) still not visible after 5000ms
```
Because xml of this view is (look into content-desc of Spinner):
```xml
<android.widget.Spinner index="0" text="" class="android.widget.Spinner" package="com.hello_github" content-desc="" checkable="false" checked="false" clickable="true" enabled="true" focusable="true" focused="false" scrollable="true" long-clickable="false" password=
Closes https://github.com/facebook/react-native/pull/8873
Differential Revision: D3831691
Pulled By: spicyj
fbshipit-source-id: a494f22cb8be8cd6964981fe7ef7d9ff3773bcce
Summary: Cleans things up and also defers rendering rows if there is an interaction happening.
Reviewed By: achen1
Differential Revision: D3817231
fbshipit-source-id: fd08d0ca7cb6c203178f27bfc5a0f55469135c3a
Summary:
Add native support on iOS and Android for `Animated.diffClamp` that was added in #9419.
**Test plan**
Tested that it works properly using the native animations UIExplorer example.
Closes https://github.com/facebook/react-native/pull/9691
Differential Revision: D3813440
fbshipit-source-id: 48a3ecddf3708fa44b408954d3d8133ec8537f21
Summary:
Adds support for the `extrapolate` parameter on the native interpolation node. This is pretty much a 1 to 1 port of the JS implementation.
**Test plan**
Tested by adding the `extrapolate` parameter in the native animated UIExplorer example.
Closes https://github.com/facebook/react-native/pull/9366
Differential Revision: D3824154
fbshipit-source-id: 2ef593af827a8bd3d7b8ab2d53abbdc9516c6022