Summary:
<details>
Thanks for submitting a PR! Please read these instructions carefully:
- [X] Explain the **motivation** for making this change.
- [] Provide a **test plan** demonstrating that the code is solid.
- [X] Match the **code formatting** of the rest of the codebase.
- [X] Target the `master` branch, NOT a "stable" branch.
Please read the [Contribution Guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md) to learn more about contributing to React Native.
</details>
My app crashed when I call navigator.geolocation.stopObserving(). I found it is caused by the reason that one argument short. So I added false to the first argument. Then bug is fixed.
1. call both navigator.geolocation.watchPosition and navigator.geolocation.getCurrentPosition
2. then call navigator.geolocation.stopObserving()
3. error happened before I fixed, and correct Warning "Called stopObserving with existing subscriptions." shown after I fixed.
Closes https://github.com/facebook/react-native/pull/14673
Differential Revision: D5301503
Pulled By: javache
fbshipit-source-id: 9e85064beb1052bb89bf42355ffd308fe9eaec53
Summary:
In `TextInputState`'s `blurTextInput()` documentation, the parameter description`id of the text field to focus` should be `id of the text field to unfocus`, since this is `blurTextInput` and not `focusTextInput`.
N/A (just documentation fix).
Closes https://github.com/facebook/react-native/pull/14367
Differential Revision: D5200263
Pulled By: shergin
fbshipit-source-id: b3e9ab60e555ad9050474b59a728761180618190
Summary:
Returning an object that doesn't have all the required properties from `getItemLayout` doesn't cause a flow error (maybe because we are using `createAnimatedComponent`) and caused ALL items to be rendered which caused perf issues that were hard to debug (typo lenght -> length -_-). This adds a simple warning in DEV mode using checkPropTypes.
**Test plan**
Tested in RNTester by passing a bad `getItemLayout` function.
![image](https://cloud.githubusercontent.com/assets/2677334/26329030/5b32ba90-3f13-11e7-9190-08f05a5c0682.png)
Closes https://github.com/facebook/react-native/pull/14111
Differential Revision: D5283942
Pulled By: sahrens
fbshipit-source-id: 8909532dfddd8628b7fb3380c198f0dfa88f240a
Summary:
Subview clipping still causes issues on Android and would be pretty hard to fix properly, I investigated this a bit and sticky header views are getting removed because it doesn't take transform into consideration. It would also require to recalculate subview clipping on every transform change so I think it is better to just disable subview clipping in when there are sticky headers, especially since we seem to be moving away from subview clipping with things like FlatList.
**Test plan**
Tested that sticky headers work in ListView paging example.
Fixes#14000
Closes https://github.com/facebook/react-native/pull/14010
Differential Revision: D5283723
Pulled By: sahrens
fbshipit-source-id: 183b3202765ae09aaae05497694c3f514e969ea1
Summary:
Curently FlatList does not implement setting native props directly like the old ListView did. This pr introduce the `setNativeProps` function which delegates to MetroListView or VirtualizedList. Thos don't have `setNativeProps` handling either, so, I delegated further to the respective ListView and Scroll components, which do have handling for it, thus, allowing to set the native props through FlatList.
Create a project with a FlatList and change a native property using `setNativeProps`:
```javascript
componentDidMount() {
setInterval(() => {
this.list.setNativeProps({ style: {backgroundColor:"white"} })
}, 1000)
}
render() {
return (
<View style={styles.container}>
<FlatList ref={component => this.list = component}
style={{backgroundColor:"black"}}
data={[{key: 'a'}, {key: 'b'}]}
renderItem={({item}) => <Text>{item.key}</Text>} />
</View>
)
}
```
Fixes#13501
Closes https://github.com/facebook/react-native/pull/13529
Differential Revision: D5283593
Pulled By: sahrens
fbshipit-source-id: 8f96f88e286042d82452fef924689b5a8a783987
Summary:
<details>
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [ ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
Please read the [Contribution Guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md) to learn more about contributing to React Native.
</details>
_What existing problem does the pull request solve?
In iOS when sending a silent push notification you need to configure the 'content-available' APS key to the value of 1 (When this key is present, the system wakes up your app in the background and delivers the notification to its app delegate, see [apple docs](https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/PayloadKeyReference.html#//apple_ref/doc/uid/TP40008194-CH17-SW1)).
This PR exposes this property to the notification event handler so app code can handle silent push scenario specifically. Currently this property is not available.
I've updated the PushNotificationIOSExample in the RNTester.
1. Open RNTester in xcode
2. Enable the push notifications capability
3. run on device
4. Go to PushNotificationIOS
5. click on "send fake notification"
6. verify alert message contains 'content-available' with a value of 1.
Closes https://github.com/facebook/react-native/pull/14584
Differential Revision: D5279181
Pulled By: shergin
fbshipit-source-id: d2288e147d89ba267f54265d819aa0a9969095e7
Summary:
When rendering a large list without a getItemLayout (ie SectionList, where it's hard to compute), it freaks out and attempt to render them all, starving the rendering/layout engine from computing the size (and more accurately figurnge out how few it actually should render.)
Before this change, with <FlatList maxToRenderPerBatch={5} data={objectOfLengthN} />, I essentially saw it doing:
```
{first: 0, last: 0}
{first: 0, last: 5}
{first: 0, last: 10}
....
{first: 0, last: N}
```
(no more hiPri renders since all elements have been rendered)
(actually renders and lays out all N objects, and computes their sizes)
(realizes that it doesn't need to show all N for my current screen size and row size)
```{first: 0, last: 55}```
After this change, that whole first part where it keeps incrementing `last` to try to "keep up with the scrolling" disappears.
Closes https://github.com/facebook/react-native/pull/14563
Differential Revision: D5278796
Pulled By: sahrens
fbshipit-source-id: 5db117b40909ec4bc92fba9b5556c6a2add046ac
Summary:
Clarified documentation for keyboardWillShow on Android as seen in issue #14275
Clarifies documentation of keyboardWillShow
None as it is just a comment that changed.
Closes https://github.com/facebook/react-native/pull/14350
Differential Revision: D5275173
Pulled By: shergin
fbshipit-source-id: d4fb08de71e6be40bb363dfc82d38b191570c476
Summary:
Replace object with cached styles from StyleSheet
Create new style object may cause performance problems
Check that ImageBackground position works the same way.
Closes https://github.com/facebook/react-native/pull/14486
Differential Revision: D5274503
Pulled By: shergin
fbshipit-source-id: 09b81e6f7ae2ada7f68854e409909caafd85e56a
Summary:
The overflow: visible option does not work on Android. This just add a little note to the docs of that property to make that clear.
See #3198 and https://react-native.canny.io/feature-requests/p/add-overflow-support-to-android .
Make it clear that this property is unavailable on Android. We had to figure this out by trial and error when porting an existing codebase, a small note in the docs would be helpful!
I could not find how to build the website - I tried `cd website && npm install && node ./server/generate.js` but I'm getting an error (*JSDOC_ERROR: There are no input files to process.*). But it is such a small change I can't see how it would break the docs build!
Closes https://github.com/facebook/react-native/pull/14103
Differential Revision: D5225814
Pulled By: shergin
fbshipit-source-id: a3136e791178d2a7090f324041be23628130199e
Summary:
WTF
(I updated it to the latest version too)
Reviewed By: yungsters
Differential Revision: D5256525
fbshipit-source-id: f3c7d620faf817a0e3c1e4c2bed9370318dff40a
Summary:
This fixes a `Attempt to get native tag from node not marked as "native"` error that happens because some animated values are not converted to native before calling the base class `__makeNative`. This makes sure we call the `__makeNative` method of input nodes before calling `super.__makeNative`.
**Test plan**
Tested that it fixes the issue I encountered and that native animations still work with properly in RNTester.
Closes https://github.com/facebook/react-native/pull/14435
Differential Revision: D5236092
Pulled By: javache
fbshipit-source-id: cb02616aec05f220c65b58831ca4334b58d0383b
Summary: Allows video uploads from native iOS by using the proper network handler, `RCTAssetsLibrary` rather than `RCTImageLoader`. Currently, uploading a camera roll video via its `assets-library://` URI would upload the first image frame. This fixes it by checking if the `assets-library://` URI is of the extension `MOV`, and if so, declines to process it from `RCTImageLoader`.
Reviewed By: javache
Differential Revision: D5223351
fbshipit-source-id: 8de92c5bb72acb02ed4d9fb92d69f68c8b5d1b36
Summary:
This uses `context` to render inner lists of the same orientation to a plain `View` without
virtualization instead of rendering nested `ScrollView`s trying to scroll in the same direction,
which can cause problems.
Reviewed By: bvaughn
Differential Revision: D5174942
fbshipit-source-id: 989150294098de837b0ffb401c7f5679a3928a03
Summary:
This is necessary to fix an extraneous warning when a VirtualizedList is constructed on the first frame.
On the first frame, the dt is huge (ie, time since epoch).
On the second frame (which may legitimately be slow as a result of a lot to render), it will then assume there were two consecutive slow frames, and print a warning:
"VirtualizedList: You have a large list that is slow to update..."
Closes https://github.com/facebook/react-native/pull/14393
Differential Revision: D5210467
Pulled By: sahrens
fbshipit-source-id: 2e79218c3d66a4a9df4884f328a125047ef264ed
Summary: Optimize ScrollView by adding flag "DEPRECATED_sendUpdatedChildFrames" to gate whether updatedChildFrames data is computed and propagated on scroll events. The frame data is used in ListView by the onChangeVisibleRows prop. When this prop is not defined, unnecessary computation in ScrollView should not be performed.
Reviewed By: sahrens
Differential Revision: D5174898
fbshipit-source-id: e3eaed8760b76becf14dfeb00122bdebdaeae4ef
Summary:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The CameraRoll docs have a method for `saveImageWithTag`. I wanted to know how to use it and how it differs from the other methods. So I open the react-native repo and used the source.
I discovered this method is deprecated. It does use a console warning to notify upon use. A developer should not have to use a deprecated method to know it's no longer supported. The docs should state this until it is removed from the library.
```bash
git clone https://github.com/facebook/react-native.git
cd react-native
npm install
cd website
npm install
npm start
open http://localhost:8079/react-native/docs/cameraroll.html
```
Verify there are comments for `saveImageWithTag` method notifying developers that it is deprecated.
Closes https://github.com/facebook/react-native/pull/14345
Differential Revision: D5198453
Pulled By: shergin
fbshipit-source-id: 2b74120a1ee450b903cdcff3812a83747dac5bb8
Summary:
Flashing scroll indicators is a standard behavior on iOS to show the user there's more content.
Launch RNTester on iOS, go to the ScrollView section, tap the "Flash scroll indicators" button.
You'll see this:
![Flash scroll indicators](https://cloud.githubusercontent.com/assets/57791/26250919/ebea607a-3cab-11e7-96c6-27579cc809ab.gif)
I've exposed the method `flashScrollIndicators` on all scrolling components that were already exposing a `scrollToXXX` method so it's usable from those components using a ref.
Let me know what you think.
Closes https://github.com/facebook/react-native/pull/14058
Differential Revision: D5103239
Pulled By: shergin
fbshipit-source-id: caad8474fbe475065418d771b17e4ea9766ffcdc
Summary:
I expanded the documentation of the scrollToOffset method a bit in FlatList
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The documentation of the scrollToOffset method in FlatList was a bit confusing. Also, there was no documentation for this method on VirtualizedList. I added the doc block there and linked to it from the FlatList doc block.
Please check if the link on the FlatList scrollToOffset method links to the scrollToOffset method of the VirtualizedList docs page.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/14317
Differential Revision: D5192378
Pulled By: hramos
fbshipit-source-id: 6131a8e5adb2a2f7cb84344541f4f8b999a232d2
Summary:
Compiler is giving a warning about an unused variable.
Tested by compiling the source code and verifying the warning is removed.
Closes https://github.com/facebook/react-native/pull/13819
Differential Revision: D5189680
Pulled By: shergin
fbshipit-source-id: 89848fcd3e988d1c256b315cfa2ef60a62c2ad56
Summary:
When ListViews has multiple sections, then rowIDs are required to be unique per section.
However the ListViewMock required rowIDs to be unique per whole list.
This change fixes the limitation of ListViewMock.
Closes https://github.com/facebook/react-native/pull/13642
Differential Revision: D5189675
Pulled By: shergin
fbshipit-source-id: 8a4fb68feb74af3307407d6d70f3f6642f50452a
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
This change allows app code to access the 'category' property of incoming iOS remote push notifications. Currently the property is not made available.
Create a test application which:
- registers for remote notifications with APNs
- passes the returned token to your push notification service provider
- displays the contents of the notification, including the 'category'
Send a remote push notification including a value for the category property in the payload. Check that the category is displayed in the application.
I considered updating RNTester but I couldn't for the life of me figure out how to get it to compile on my machine, sorry ;-) I can confirm my change works when applied directly in the node_modules of an existing RN project.
I've signed the CLA. Hope this is enough info to go on, please let me know if not!
Closes https://github.com/facebook/react-native/pull/14322
Differential Revision: D5184941
Pulled By: javache
fbshipit-source-id: b69decedafac37a5212efcf32faf858aa67ed691
Summary:
Fixes#13691.
Prior to this change, VoiceOver generally didn't say anything when selecting a multiline TextInput. The only exception was VoiceOver would announce the TextInput's placeholder if it had one set.
After this change, VoiceOver announces the following for multiline TextInputs:
- The TextInput's content.
- The TextInput's placeholder if the TextInput doesn't have any content in it.
- The fact that the TextInput is a textfield.
- The cursor position if the TextInput is being edited.
This is similar to the behavior of single line TextInputs.
This change achieves this by disabling `RCTTextView` as an accessibility element. `RCTTextView` is a subclass of `RCTView` so VoiceOver doesn't recognize this as a textfield. Instead, VoiceOver now sees the child `RCTUITextView` which is a subclass of `UITextView` so VoiceOver does recognize it as a textfield. Additionally, an `accessibilityLabel` implementation was added to `RCTUITextView` in order to take the value of the placeholder into account.
Verified the announcements of TextInputs with various props:
- No placeholder and no content
- Just a placeholder
- Just content
- Both a placeholder and content
Did this for both singe line inputs and multiline inputs. For setting content in multiline inputs, I tested both using the `value` prop and passing children. All other props being equal, these configurations resulted in similar announcements.
I verified that the following accessibility props work the same on singleline and multiline TextInputs:
- `accessible`
- `accessibilityLabel`
- `accessibilityTraits`
- `accessibilityViewIsModal`
- `onAccessibilityTap`
- `onMagicTap`
Additionally, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14200
Differential Revision: D5185727
Pulled By: shergin
fbshipit-source-id: 94271e6c8b089eb82006b52fe7917649d69e74af
Summary:
Sometimes, when we implement some custom RN view, we have to proxy all accessible atributes directly to some subview which actually has accesible content. So, in other words, this allows bypass some axillary views in terms of accessibility.
Concreate example which this approach supposed to fix:
https://github.com/facebook/react-native/pull/14200/files#diff-e5f6b1386b7ba07fd887bca11ec828a4R208
Reviewed By: mmmulani
Differential Revision: D5143860
fbshipit-source-id: 6d7ce747f28e5a31d32c925b8ad8fd4b98ce1de1
Summary: It can be useful when you want to setup `tintColor` for the image or get a reference to call `setNativeProps` then.
Reviewed By: ericvicenti
Differential Revision: D5158908
fbshipit-source-id: 873c1cae9bd0af711a42016dcc548231e3cf89e7
Summary:
The `requestIdleCallback` sometimes doesn't work in `Debug JS Remotely` mode if I use real device, the callback will never called. I guess it may be debugger worker and device caused by the time gap, or some cause websocket blocking, so it's just sometimes happening.
I think we can support [options](https://developer.mozilla.org/zh-TW/docs/Web/API/Window/requestIdleCallback#Parameters) for that.
Added an example `Run requestIdleCallback with timeout option` for Timers of UIExplorer, it use `{ timeout: 100 }` option with burn CPU 100ms, we can see `didTimeout` is true.
Closes https://github.com/facebook/react-native/pull/13116
Differential Revision: D4894348
Pulled By: hramos
fbshipit-source-id: 29c4c2fe5634b30a8bf8d3495305cd8f635ed922
Summary:
minor spelling error fix
Thanks for submitting a PR! Please read these instructions carefully:
- [ Found this small spelling error while reading thought of reporting it ] Explain the **motivation** for making this change.
- [ Test not required ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
If you have added code that should be tested, add tests.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/14273
Differential Revision: D5160964
Pulled By: hramos
fbshipit-source-id: 3142cc511476e8b494576b8e31faf43eb97b40c5
Summary:
We are removing support of nesting views inside <Image> component. We decided to do this because having this feature makes supporting intrinsinc content size of the <Image> impossible; so when the transition process is complete, there will be no need to specify image size explicitly, it can be inferred from actual image bitmap.
And this is the step #2: Yellow Box.
<ImageBackground> is very simple drop-in replacement which implements this functionality via very simple styling.
Please, use <ImageBackground> instead of <Image> if you want to put something inside.
Reviewed By: yungsters
Differential Revision: D5139264
fbshipit-source-id: 99442107e10a321618fd34802c57a8c205ce66fb
Summary:
This PR aims to update the Inspector tool in React Native to use the new inspection APIs that have been added to the ReactNative renderer:
https://github.com/facebook/react/pull/9691
This PR also cleans up the code in `Inspector.js` so there's no usage of React's internals.
Closes https://github.com/facebook/react-native/pull/14160
Reviewed By: bvaughn
Differential Revision: D5129280
Pulled By: trueadm
fbshipit-source-id: b1b077c04f46b0f52cdea0e19b4154441558f77a
Summary:
This change introduces some APIs that are useful for making announcements through the screen reader on iOS:
- `announceForAccessibility`: The screen reader announces the string that is passed in.
- `announcementFinished`: An event that fires when the screen reader has finished making an announcement.
You can already solve similar problems with RN Android using the `accessibilityLiveRegion` prop. Live regions are a different feature but they can be used to solve the same problem. This commit does not attempt to add live region support in RN iOS because Apple did not build live region support into iOS.
Verified that `announceForAccessibility` causes VoiceOver to announce the string when VoiceOver is enabled. Verified that `announcementFinished` fires with the appropriate data in the event object. Additionally, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14168
Differential Revision: D5137004
Pulled By: javache
fbshipit-source-id: b3c10f3dfc716430a16fcc98e1bb6fe52cabd6a5
Summary:
Motivation:
* We maintain two different implementation of <TextInput> (multilined and singlelined), this change makes the implementations much similar which will help us to support and improve both of them in the (near) future;
* We have to have separated RCTView-based container view for (TextField) to support sofisticated bordering and so on;
* It opens to us possibility to unify UITextView and UITextField subclasses and remove code duplication across RCTTextView and RCTTextField;
* Making things decoupled in general will allow us to fix existing bugs with events.
Reviewed By: mmmulani
Differential Revision: D5083010
fbshipit-source-id: 2f2d42c2244d2b39256c51480c1f16f4e3947c01
Summary: Now padding, border and intinsic sizes are computed same way as for singlelined text input.
Reviewed By: mmmulani
Differential Revision: D5075880
fbshipit-source-id: 1bc2fd479c13a003c717b1fc3d9c69f4639d4444
Summary:
Because it introduces inconsistency in RN layout model, confuses people and hurts dev experience.
The original problem was introduced in D1611014 as an attempt to address the intrinsic size issue.
So, now <TextInput> has intrinsic size (D5069971) and we don't need this hack anymore.
GH issues:
https://github.com/facebook/react-native/issues/11892https://github.com/facebook/react-native/issues/9646
Reviewed By: javache
Differential Revision: D5072833
fbshipit-source-id: d9a60ab09b728e6de89bfa53eda07069377f1369
Summary: Previosly `borderWidth` did not affect actual content inset (which was a problem).
Reviewed By: mmmulani
Differential Revision: D5072483
fbshipit-source-id: d43cba7414a9335b9f9fd4d1565d7aee403cce0e
Summary: Because we believe in Objective-C.
Reviewed By: javache
Differential Revision: D5070920
fbshipit-source-id: 17e2335c829f2e5857981c5028e3bcecbe5dc13f
Summary:
Singleline <TextInput> now has intrinsic size which is equal to size of placeholder.
And if <TextInput> does not have placeholder it still has intrinsic height.
So, we don't need to set the size up manually every single time anymore!
(Multiline <TextInput> already has this feature.)
Reviewed By: mmmulani
Differential Revision: D5069971
fbshipit-source-id: f65c1062a812259b66d287929314dc571dc1f3ee
Summary:
…cookies on Android Lollipop or later versions.
Third party cookies in WebView are [disabled by default](https://developer.android.com/reference/android/webkit/CookieManager.html#setAcceptFileSchemeCookies(boolean)) on Android Lollipop or later versions. This prevented users from logging in by using _Login by Facebook_ method (in redirect mode) in Android Webview.
This PR exposes a prop `thirdPartyCookiesEnabled` which will enable third party cookies in Android Webview. This setting is ignored on versions below Android Lollipop and on iOS as third party cookies are enabled in them by default.
Appropriate documentation was added in code and they were reflected in the website.
Closes https://github.com/facebook/react-native/pull/14013
Differential Revision: D5145059
Pulled By: shergin
fbshipit-source-id: 67bcb3a497a9c6f6db1d12e8d16197d2facd157e
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4989881
fbshipit-source-id: 674bb98c89ada1fca7b3b20b304736b2a3b8304e
Summary:
Currently it's not possible to create a silent local notification (which is useful for badge updates) with PushNotificationIOS. This commit solves the problem - when **soundName** param is not specified in **PushNotificationIOS.scheduleLocalNotification** method, a silent notification will be created.
Local notification without sound:
```
let fireDate = new Date();
fireDate = fireDate.setSeconds(fireDate.getSeconds() + 15); //fire in 15 seconds
PushNotificationIOS.scheduleLocalNotification({
fireDate: fireDate,
alertBody: "I'm silent!"
});
```
Local notification with sound:
```
let fireDate = new Date();
fireDate = fireDate.setSeconds(fireDate.getSeconds() + 15); //fire in 15 seconds
PushNotificationIOS.scheduleLocalNotification({
fireDate: fireDate,
alertBody: "I'm with sound!",
soundName: "Any sound"
});
```
Closes https://github.com/facebook/react-native/pull/13734
Differential Revision: D5144848
Pulled By: shergin
fbshipit-source-id: dc990b2673305a01cfd868fcdedcf27c461d0a34
Summary:
We found that `-[CALayer renderInContext:]` produces bad results in some cases (which is actually documented thing!),
so we decided to replace it with `-[UIView drawViewHierarchyInRect:]` which is more reliable (I hope).
As part of this change I completly removed support of `CALayer` from local fork of `RNTesterIntegrationTests`.
See https://github.com/facebook/react-native/pull/14011#issuecomment-303844580 for more details.
janicduplessis
Reviewed By: javache
Differential Revision: D5129492
fbshipit-source-id: 6a9227037c85bb8f862d55267f5301e177985ad9
Summary:
The documentation for the prop `scrollEnabled` on the `ScrollView` component does not clarify that scrolling is still possible by calling `scrollTo` on the view ref.
Please see [this expo snack demo](https://snack.expo.io/BJKTVMM-Z) showing scrolling is allowed while `scrollEnabled` is `false`.
This PR makes the documentation for this prop more clear, in that setting it to false will only disable scrolling by touches, not universally.
In my opinion, this also raises the question of a need for an additional prop which would disable all scrolling, even when calling `scrollTo`.
I have attached a screenshot of what this part of the documentation looks like with my edit:
![screen shot 2017-05-23 at 3 38 59 pm](https://cloud.githubusercontent.com/assets/4976096/26374045/e73a035e-3fd1-11e7-93cd-3617c4ac4db8.png)
Closes https://github.com/facebook/react-native/pull/14140
Differential Revision: D5138593
Pulled By: shergin
fbshipit-source-id: db1a5f9c8ac41ecfce952e7b1fce9428b2068162
Summary:
When using native animated we don't go through the shadow thread and use the NativeViewHierachyOptimizer so we have to make sure the views won't get optimized away. Also since we are not passing certain props because they are driven by native it is possible that the view will be marked as layout only when in fact it is not.
**Test plan**
Animated a simple view that will be collapsed with native animated and reproduce the error (it's actually just an error log in logcat now and no longer a redscreen) and checked that this fixes it.
Fixes#12975
Closes https://github.com/facebook/react-native/pull/12983
Differential Revision: D4811420
Pulled By: javache
fbshipit-source-id: f217f244baca64df2b76cbe08cce2d847c0dc985
Summary:
Follow up to #11973 to add support to Animated.loop with useNativeDriver on iOS.
**Test plan**
Test with new UIExplorer example
Run unit tests
Closes https://github.com/facebook/react-native/pull/13359
Differential Revision: D4960754
Pulled By: javache
fbshipit-source-id: caa840281f1b060df7a2b1c50405fcae1e1b0de6
Summary:
This change introduces an API, `setAccessibilityFocus`, which moves the screen reader's focus to the passed in element. This causes VoiceOver to announce the element and draw a focus rectangle around it.
Similar functionality is already available in RN Android through the `sendAccessibilityEvent` method. Here's an example of what exists today in RN Android:
```
RCTUIManager.sendAccessibilityEvent(
node,
8 /* TYPE_VIEW_FOCUSED */);
```
Called `setAccessibilityFocus` on a couple of elements to verify that focus does indeed move when VoiceOver is enabled. Additionally, my team is using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14169
Differential Revision: D5137002
Pulled By: javache
fbshipit-source-id: 466e8b187e625de7c0f0d36e0400327dcd8d192a
Summary:
What existing problem does the pull request solve?
Beginning in iOS9, Apple has deprecated `-application:openURL:sourceApplication:annotations:`
`- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(nullable NSString *)sourceApplication annotation:(id)annotation NS_DEPRECATED_IOS(4_2, 9_0, "Please use application:openURL:options:") __TVOS_PROHIBITED;`
This PR uses the newly recommended method:
`- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey, id> *)`
while meanwhile, leaving the deprecated one for developers wishing to use the older `-application:openURL:sourceApplication:annotations:` for apps that support versions 8.x or less.
Benefits will include:
- [x] less warnings
- [x] official deprecation should happen when iOS 11 is deployed
- [x] TVOS support
Closes https://github.com/facebook/react-native/pull/13615
Differential Revision: D4987980
Pulled By: javache
fbshipit-source-id: ae07715a55ca627860262a9c8cf7df1e3c5e752b
Summary:
Fixes https://github.com/facebook/react-native/issues/13784
The section footer was only rendered with the last item of the section. However, that meant in sections where no items were rendered, no section footer would be rendered. This patch makes sure that when there are no items the section footer is rendered with the section header in addition to adding tests asserting the existance of section footers in empty lists.
One potential point of contention is whether or not a section separator (as defined by the `SectionSeparatorComponent` prop to `<SectionList>`) should be rendered in an empty list. I did not include a section separator for empty lists, but let me know if you think one should be included. See the test plan below for an image of an empty section rendered without a section separator.
I was also running into a lint error, `no-alert`, in `SectionListExample.js` around line 135 that blocked me from publishing. This error looks to be triggered when the `alert()` global function is called, so to fix the error I added an import for the `Alert` module and called the `alert()` function on that module.
To help debug the `scrollToLocation()` behavior that was modified as a part of this PR I added three buttons (can be seen in the test plan image) which scroll to arbitrary points in the list.
Reviewed By: sahrens
Differential Revision: D5084095
fbshipit-source-id: 4c98bebc1c3f1ceaa5a634fa144685d83d1072df
Summary:
There was an edge case where sometimes a view could be added and removed in the same batch so this caused issues because we ran `disconnectAnimatedNodeFromView` before `connectAnimatedNodeToView`. This separates restoring default values from `disconnectAnimatedNodeFromView` so we can run only `restoreDefaultValues` on the pre-operations queue and just do nothing in case the view doesn't exist (it is fine because we know it will be removed immediately).
**Test plan**
Tested that native animations still work properly in RNTester and tested that the edge case crash was fixed.
Closes https://github.com/facebook/react-native/pull/14114
Differential Revision: D5128989
Pulled By: javache
fbshipit-source-id: 9f47a2d3aafeb06d8ed1a4dd1800b8af225edb7d
Summary:
This is a simple bugfix. `_updateViewableItems` expects the `data` prop, as it calls `getItemCount` on it. Without this, `onViewableItemsChanged` updates twice for each scroll position, once from `_onScroll` with the incorrect results, and once from `_updateCellsToRender` with the correct results. This means the callback nigh-on unusable.
I simply logged the results of `onViewableItemsChanged` and made sure they were correct.
Closes https://github.com/facebook/react-native/pull/14162
Differential Revision: D5128363
Pulled By: sahrens
fbshipit-source-id: 3faef812068921a26ed871339da79870fd0d911c
Summary:
The lack of very clear docs on supported image formats is causing unnecessary issues (#13806).
This should mitigate and keep the issue list cleaner.
Its only a documentation change. No code changes made.
Closes https://github.com/facebook/react-native/pull/13807
Differential Revision: D5023002
Pulled By: javache
fbshipit-source-id: b1e3562ae7649cf71833b300e125966d6e832a69
Summary:
We are removing support of nesting views inside <Image> component. We decided to do this because having this feature makes supporting `intrinsinc content size` of the `<Image>` impossible; so when the transition process is complete, there will be no need to specify image size explicitly, it can be inferred from actual image bitmap.
And this is the step #0.
<ImageBackground> is very simple drop-in replacement which implements this functionality via very simple styling.
Please, use <ImageBackground> instead of <Image> if you want to put something inside.
Reviewed By: yungsters
Differential Revision: D5100021
fbshipit-source-id: 640c0fb2d1066e166d974efba39b4cfaaee7dd45
Summary:
Close#13500
I've been bothered by this issue for quite a long time, finally get some time to look into it.
I find the root cause is that after a prop of the native driven node is assigned with a plain value, if you set it to be a `Animated.Value` again , it will take no effect any more, so I just keep it be a `Animated.Value` all the time.
`value --> Animated.Value (✅) --> value (✅) --> Animated.Value (❌)`
ping janicduplessis
Closes https://github.com/facebook/react-native/pull/13885
Differential Revision: D5077094
Pulled By: javache
fbshipit-source-id: 3fb5d8196d94101200394b2bb2b95c776fb1d2f3
Summary:
There was an issue that sometimes sticky headers would stop moving when re-rendering because we did not reattach events properly. This makes sure that we always detach and reatach on rerender in case the scroll view ref changes.
**Test plan**
Tested that this fixes issues with sticky headers we discovered when updating Expo to RN 0.44.
Closes https://github.com/facebook/react-native/pull/14012
Differential Revision: D5094418
Pulled By: javache
fbshipit-source-id: a56050ae786712e8a3de2a6e3b4e8749a2fde86e
Summary:
cc hramos
Pretty sure I've hit all of the places where AppRegistry is called in CRNA-pastable examples. Let me know whether you think we need to approach the version lag differently, I figure a caveat is as natural a place to call it out as any.
If you end up finding anything else that needs tweaking before cherry picking, I'm happy to push that up here too.
Closes https://github.com/facebook/react-native/pull/13744
Differential Revision: D5071038
Pulled By: hramos
fbshipit-source-id: 4a4a6f2a73079aca627f17d75a4e4b395ecbd4a8
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The current code for IOS contains deprecated code for incoming urls.
in iOS 10 deprecated openURL.
more details here: https://useyourloaf.com/blog/openurl-deprecated-in-ios10/
1. Create an RN app with iOS 10. set up linking as per instructions.
2. Using the iOS9 code snippet, with the app is open, navigate to the apps url scheme (in safari) appname://value1/value2, the eventListener will not trigger. note: it will however trigger getInitialURL if app is closed.
3. Replace the old iOS9 code with the iOS 10 and trigger an incoming url from a browser appname://
with the new code in the doc it will trigger for both open and closed apps.
Closes https://github.com/facebook/react-native/pull/13942
Differential Revision: D5071851
Pulled By: hramos
fbshipit-source-id: 8394de73014a1d2a5982b22b1b6fd09e0cf524dd
Summary:
Added a missing license header to UnimplementedView.js
No code logic got changed, just added a comment. So the regular CircleCI tests should be fine.
Closes https://github.com/facebook/react-native/pull/13952
Differential Revision: D5056778
Pulled By: javache
fbshipit-source-id: feb106946a9a34cfdf2df63de21305ac779296f4
Summary:
And clean it up.
**TestPlan**
No more warning when launching RNTester
LayoutAnimationExample still works, also without warnings.
Reviewed By: fkgozali
Differential Revision: D5055050
fbshipit-source-id: a3a6cdf25632dc4f9455d795e8a2e3c00f968e09
Summary:
D5016368 to suppress the warning had a typo which meant `_isMounted` would never get set
`false` and thus some functions could be called on unmounted refs.
Reviewed By: yungsters
Differential Revision: D5034076
fbshipit-source-id: 6334db6ee2f9e19c1bb4da2572987dc10773e28d
Summary:
The list items' selected state is inside the `selected` Map, not inside the `state`.
This PR corrects a small mistake in the minimal example in the Documentatioin of the FlatList component.
1. Create a vanilla React Native project.
2. Create the components involved in the minimal example of FlatList.
3. Run to see if the `selected` property of the `MyListItem` changes as intended.
Currently the example has this mistake so an error will show up when running:
![2017-05-05 2 00 12](https://cloud.githubusercontent.com/assets/5442413/25735154/c091f11a-319b-11e7-9646-427c6a56f901.png)
Closes https://github.com/facebook/react-native/pull/13795
Differential Revision: D5010105
Pulled By: javache
fbshipit-source-id: 09585cea2f2e3e6746419ef54ef8da9dbdb8dbb1
Summary: Exporting an object instead of an array so it can be used as an enum by other files.
Reviewed By: sahrens
Differential Revision: D5007488
fbshipit-source-id: 8253a424f0dbb51511b889b1da637f366c0f290a
Summary:
Hey there :)
Please let me know if the name `ListEmptyComponent` should be changed. I also thought about `ListNoItemsComponent`. Or maybe `ListPlaceholderComponent`?
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
In a FlatList, I wanted to show some placeholder when my data is empty (while keeping eventual Header/Footer/RefreshControl).
A way around this issue would be to do something like adding a `ListHeaderComponent` that checks if the list is empty, like so:
```js
ListHeaderComponent={() => (!data.length ? <Text style={styles.noDataText}>No data found</Text> : null)}
```
But I felt it was not easily readable as soon as you have an actual header.
This PR adds a `ListEmptyComponent` that is rendered when the list is empty.
I added tests for VirtualizedList, FlatList and SectionList and ran `yarn test -- -u`. I then checked that the snapshots changed like I wanted.
I also tested this against one of my project, though I had to manually add my changes because the project is on RN 0.43.
Here are the docs screenshots:
- [VirtualizedList](https://cloud.githubusercontent.com/assets/82368/25566000/0ebf2b82-2dd2-11e7-8b80-d8c505f1f2d6.png)
- [FlatList](https://cloud.githubusercontent.com/assets/82368/25566005/2842ab42-2dd2-11e7-81b4-32c74c2b4fc3.png)
- [SectionList](https://cloud.githubusercontent.com/assets/82368/25566010/368aec1e-2dd2-11e7-9425-3bb5e5803513.png)
Thanks for your work!
Closes https://github.com/facebook/react-native/pull/13718
Differential Revision: D4993711
Pulled By: sahrens
fbshipit-source-id: 055b40f709067071e40308bdf5a37cedaa223dc5
Summary:
The main reason to use **VirtualizedList** is to set the `getItem` and `getItemCount` props, so having default values for these props makes things error prone.
* In **VirtualizedList**, changed the `getItem` and `getItemCount` props from optional to required, and removed default values.
* Ensured that implementing classes **FlatList** and **SectionVirtualizedList** are always passing these props.
* Updated VirtualizedList-test.js accordingly.
Reviewed By: sahrens
Differential Revision: D4980236
fbshipit-source-id: ad1838931253bc61ff9068c40929f6e9c755b92c
Summary:
- If the initial render doesn't extend past `onEndReachedThreshold` it is likely that onEndReached won't get called until scroll, which can be a bad experience if the `initialNumToRender` is very close to the viewport height. This happens because when `onContentSizeChange`, `onLayout` may not have fired yet so we don't know what the `visibleLength` is. Fix is to also call `maybeCallOnEndReached` in `_onLayout` as well.
- We have an optimization that does hi-pri render window updates when scrolling quickly and the content reaches the edge of the viewport, but there is also an important case where the user has scrolled to the end of the content and is waiting for a network response. Once the new data comes in, we want to render it ASAP because the user is waiting for it. To solve this we refactor our scheduling code into a shared function that always checks if it should be a hi-pri update instead of just in `_onScroll`.
Reviewed By: bvaughn
Differential Revision: D4975314
fbshipit-source-id: 8d64832ecbcbdbac430a08a4018d7a32b2216a85
Summary:
- [x] Explain the **motivation** for making this change.
- [ ] ~Provide a **test plan** demonstrating that the code is solid.~
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The key name required to access the CameraRoll in iOS is incorrect.
Closes https://github.com/facebook/react-native/pull/13755
Differential Revision: D4994048
Pulled By: javache
fbshipit-source-id: 9ec2f793f03f529e9cf0f89106f88445fde50f2a
Summary: People rarely re-order sections so this is an annoying requirement and we can just use the index by default.
Reviewed By: thechefchen
Differential Revision: D4972154
fbshipit-source-id: 256c445b36c9ba101277614d30a6dc1dbd477ee0
Summary: The xcode project for these bundled libraries should not depend on UIExplorer
Reviewed By: yungsters
Differential Revision: D4979629
fbshipit-source-id: 440b225805e9ebaf0a02b39a35c3ab9c2a83ad05
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4680300
fbshipit-source-id: 337836deef0767e5f26350f5a8ce73adb4146a02