Summary:
In Android `RecyclerViewBackedScrollView` didn't provide the `scrollTo` API, however iOS does.
If a ListView was created with `RecyclerViewBackedScrollView` as its `renderScrollComponent`, then calling `scrollTo` wouldn't work.
This diff enables the `scrollTo` API in `RecyclerViewBackedScrollView` on Android.
Reviewed By: dmmiller
Differential Revision: D3605233
fbshipit-source-id: f192053361f45453e5fce3fb6038ab03ac4025af
Summary:
There were several fixes to how calls to propType checkers. This is to
account for the new deprecation warning - React.PropTypes will not be
part of production builds in the future.
Note: There is still a warning about an invalid argument to `React.PropTypes.oneOf` (React is running that validation sooner now). Specifically [both of these](b1e49832ef/Libraries/Components/Touchable/TouchableWithoutFeedback.js (L44-L45)) because `View.AccessibilityTraits` is actually undefined in tests (didn't look into why you conditionally set that).
**Test plan (required)**
`npm test` & fixed all warnings due to proptype secret
Closes https://github.com/facebook/react-native/pull/8758
Reviewed By: zpao
Differential Revision: D3564288
Pulled By: bestander
fbshipit-source-id: 1ff1f90907f41855e364048aa730ccd239c522b4
Summary:
`BackAndroid` JS event subscriptions should be called in reverse order
(the subscription from the latest `addEventLister` should run first).
Also if listener returns true, don't call other listeners.
**Motivation**: We use `BackAndroid` listeners to prevent closing screens with user's input.
When we have two screens in stack (each screen with listener, which show alerts),
we want to show alert only from the last screen listener, not from all.
Closes https://github.com/facebook/react-native/pull/8929
Differential Revision: D3598978
Pulled By: dmmiller
fbshipit-source-id: a7b0762b36a60755a844e90fffd58887f89c9ffb
Summary:
Before this PR, ```RCTImageLodaer```'s Cache was too big(200MB on disk) and It doesn't work with HTTP Cache-Control header. So to provide dynamic image, the users must have to add random value on url( ex. adding current date) to avoid cache.
So I change that cache system to default ```NSURLRequest```'s cache system, which is well-working with HTTP specs. As the discussion on this issue #7571 , making custom cache policy processor is not ready yet and useless, over-tech things, I think.
Even we have no plan about image cache system(or would change plan later), before having a nice plan, I think we should let user use image module with common HTTP Specs.
So I remove custom ```NSURLCache```, and make logic like below,
1. try fetch image,
2. on response, get ```Date``` on response's header and make ```cacheKey``` with ```Date```.
> (why? because if ```NSURLRequest```'s response was cached, the response's ```Date``` header dosen't change.)
3. find decoded imag
Closes https://github.com/facebook/react-native/pull/8235
Reviewed By: bnham
Differential Revision: D3469086
Pulled By: javache
fbshipit-source-id: 35a5552cda6e6c367481020bbf3c28eb4a9d0207
Summary:
This uses `[UIImage imageNamed:]` to load local assets that are bundled using `require('../image/path.png')` and makes sure it is done synchronously on the main queue to prevent images from flickering. This improves user experience a lot when using large local images and prevents icon flickers to match the behaviour of most native apps.
This adds to methods to the ImageLoader protocol, one to tell if the image loader must be executed on the url cache queue and one to tell if the result of the image loader should be cached. I then use these to make the LocalImageLoader bypass the url cache queue and avoid caching images twice.
Note that this doesn't affect debug builds since images are loaded from the packager.
I'm not sure if we want to still support async loading of local images as I'm not sure how much of a perf difference this will make. Maybe someone at fb can benchmark this see how it affects your apps but there wasn't a noticeable one in mine. Also I only enabled this for loading png and jpg im
Closes https://github.com/facebook/react-native/pull/8102
Reviewed By: bnham
Differential Revision: D3433647
Pulled By: javache
fbshipit-source-id: 37bd6aff20c0465c163db3cdbcaeaedff55f7b1f
Summary: Add support for top, bottom, and center layout gravity to ToastAndroid
Reviewed By: AaaChiuuu
Differential Revision: D3590224
fbshipit-source-id: 84dbbcfbe4133f291d62723c5c261acd7b32b46e
Summary: RCTShadowText currently overrides a couple methods from RCTShadowView to reset the count of the cssNode children to 0. This diff instead moves that logic into RCTShadowView behind a configurable flag making it easier to reason about.
Reviewed By: javache
Differential Revision: D3586434
fbshipit-source-id: 4389a8119dc49e3fc4357174c87c0c69287ae385
Summary: fillCSSNode was only ever used in RCTShadowView to set the child count which is already performed in insert/remove subview calls and in RCTShadowText is was used to set the measure function which can be done in the initializer instead.
Reviewed By: majak, javache
Differential Revision: D3586418
fbshipit-source-id: de2155daf0f1702c8977bf23183a3b6a650d016b
Summary:
The `setupDevtools` for Android looks coming on [v0.30](22fbb6d46d), currently we need to run `adb reverse tcp:8097 tcp:8097`, I think get host IP (`10.0.2.2`, Genymotion: `10.0.3.2`) for Android will be better. (it can be found in `AndroidConstants` native module)
Closes https://github.com/facebook/react-native/pull/8811
Differential Revision: D3586177
Pulled By: javache
fbshipit-source-id: 3bfe04391b0fea608e4d3deab03dd376fab8727c
Summary:
Addresses this comment: https://github.com/facebook/react-native/issues/2296#issuecomment-232446493
This pull request adds the `center` value to `ImageResizeMode`.
When set, it will center the image within its frame.
If the image is larger than its frame, the image is downscaled while maintaining its aspect ratio.
That is how the Android implementation works, too.
Sorry, don't have time to write tests. 😢
Any reviewers should make sure `RCTTargetRect` returns the correct value when:
- the image is smaller than its frame (ie: no downscaling needed)
- the image is larger than its frame (should be downscaled to avoid clipping)
Closes https://github.com/facebook/react-native/pull/8792
Differential Revision: D3586134
Pulled By: javache
fbshipit-source-id: 78fb8e5928284003437dac2c9ad264fa584f73ec
Summary:
I thought it would be useful to help clear out references to no longer used styles and also catch typos on style names to have flow error when we try to access a style that isn't defined.
Example:
```javascript
export default class AuthenticationScreen extends React.Component {
render() {
// This throws an error because `continer` is misspelled
return (
<View style={styles.continer} />
)
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
},
}
```
```javascript
export default class AuthenticationScreen extends React.Component {
render() {
// This throws an error because no fancyContainer style is defined
return (
<View style={[styles.container, styles.fancyContainer]} />
)
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
},
}
```
All credit goes to jeffmo in this tweet: https://twitter.com/lbljeffmo/status/755179096271888385
Also included in the PR is some cleanup on styles that
Closes https://github.com/facebook/react-native/pull/8876
Differential Revision: D3584983
Pulled By: yungsters
fbshipit-source-id: 0ee0e12ff3d976c137d932688e323c26690e0a52
Summary:
As per javache comments in #8734.
Also removes now useless feature detection check.
**Test plan**
Tested that rIC still works in UIExplorer example.
Closes https://github.com/facebook/react-native/pull/8795
Differential Revision: D3572566
Pulled By: javache
fbshipit-source-id: 261d13d8b03898313f8b4184d634c70f81a61b62
Summary:
For now, `PanResponder.create()` return a new object which may hold a handle
for interaction. The handle is created when the gesture starts, and it's cleared
when the gesture finishes.
However, the handle may become stale cause the owner (view) is removed or
re-rendered before the gesture finishes, which leaves InteractionManager
with handles that can never be removed.
In some cases, this blocks the app that waits for InteractionManager to
be idle and having leaky handles prevents InteractionManager from being idle
again.
The fix is to move the handle from the instance to the static variable, and
we'd clear it whenever a gesture finishes.
Reviewed By: sahrens
Differential Revision: D3550699
fbshipit-source-id: 412e9046a6cd9be34b3a7d572258008016a29f41
Summary:
The description of `AlertIOS.prompt()` parameter `defaultValue` is wrong, correct it.
Closes https://github.com/facebook/react-native/pull/8793
Differential Revision: D3566939
fbshipit-source-id: c6378d8142c66e9f9b854f216afcf10c489ec750
Summary:
In Android, `RecyclerViewBackedScrollView` wasn't using `refreshControl` prop.
If a ListView were created with `RecyclerViewBackedScrollView` as its `renderScrollComponent`, then the `refreshControl` wouldn't work.
example:
```js
<ListView
dataSource={this.props.dataSource}
renderRow={this._renderRow.bind(this)}
refreshControl={
<RefreshControl
refreshing={this.props.isRefreshing}
onRefresh={this._onRefresh.bind(this)}
/>
}
renderScrollComponent={props => <RecyclerViewBackedScrollView {...props} />}/>;
```
This works in iOS, since the `RecyclerViewBackedScrollView` just returns an `ScrollView`.
This pull request uses the `refreshControl` to decide whether it should wrap the `NativeAndroidRecyclerView` with an
`AndroidSwipeRefreshLayout` or not.
This fixes the issue #7134.
Closes https://github.com/facebook/react-native/pull/8639
Differential Revision: D3564158
fbshipit-source-id: c10a880ea61cd80b8af789b00be90d46d63eaf9a
Summary: When pasting text longer than maxlenght, the textDidChange: call we did would end calling back into textView:shouldChange: because we saw an unexpected multi-character change. Since this is an expected mutation, update predictedText appropriately.
Reviewed By: majak
Differential Revision: D3561524
fbshipit-source-id: 07bb78d830ccfa3aed6ee274dc30adeadce9e1f8
Summary:
Just noticed the old syntax was used in the docs.
Closes https://github.com/facebook/react-native/pull/8765
Differential Revision: D3560355
Pulled By: mkonicek
fbshipit-source-id: 13db21a498be205a32921a89058167dd47e1bbdf
Summary:
This is a follow up of the work by brentvatne in #5052. This addresses the feedback by astreet.
- Uses ReactChoreographer with a new callback type
- Callback dispatch logic moved to JS
- Only calls into JS when needed, when there are pending callbacks, it even removes the Choreographer listener when no JS context listen for idle events.
** Test plan **
Tested by running a background task that burns all remaining idle time (see new UIExplorer example) and made sure that UI and JS fps stayed near 60 on a real device (Nexus 6) with dev mode disabled. Also tried adding a JS driven animation and it stayed smooth.
Tested that native only calls into JS when there are pending idle callbacks.
Also tested that timers are executed before idle callback.
```
requestIdleCallback(() => console.log(1));
setTimeout(() => console.log(2), 100);
burnCPU(1000);
// 2
// 1
```
I did *not* test with webworkers but it should work as I'm using executor tokens.
Closes https://github.com/facebook/react-native/pull/8569
Differential Revision: D3558869
Pulled By: astreet
fbshipit-source-id: 61fa82eb26001d2b8c2ea69c35bf3eb5ce5454ba
Summary:
WebView component detect phone numbers in html as URL links by default. But sometimes we don't want this behavior.
This PR add dataDetectorTypes as a prop of WebView, so one can specify value of this prop as one or more of phoneNumber/link/address/calendarEvent/none/all
This prop maps to UIWebView.dataDetectorTypes
Closes https://github.com/facebook/react-native/pull/8743
Differential Revision: D3556440
fbshipit-source-id: 55f01d2cdd785381f261a9dc931aa9311f0ad1d4
Summary:
In preparation for Blob support (wherein binary XHR and WebSocket responses can be retained as native data blobs on the native side and JS receives a web-like opaque Blob object), this change makes RCTNetworking aware of the responseType that JS requests. A `xhr.responseType` of `''` or `'text'` translates to a native response type of `'text'`. A `xhr.responseType` of `arraybuffer` translates to a native response type of `base64`, as we currently lack an API to transmit TypedArrays directly to JS. This is analogous to how the WebSocket module already works, and it's a lot more versatile and much less brittle than converting a JS *string* back to a TypedArray, which is what's currently going on.
Now that we don't always send text down to JS, JS consumers might still want to get progress updates about a binary download. This is what the `'progress'` event is designed for, so this change also implements that. This change also follows the XHR spec with regards to `xhr.response` and `xhr.responseText`:
- if the response type is `'text'`, `xhr.responseText` can be peeked at by the JS consumer. It will be updated periodically as the download progresses, so long as there's either an `onreadystatechange` or `onprogress` handler on the XHR.
- if the response type is not `'text'`, `xhr.responseText` can't be accessed and `xhr.response` remains `null` until the response is fully received. `'progress'` events containing response details (total bytes, downloaded so far) are dispatched if there's an `onprogress` handler.
Once Blobs are landed, `xhr.responseType` of `'blob'` will correspond to the same native response type, which will cause RCTNetworking to only send a blob ID down to JS, which can then create a `Blob` object from that for consumers.
Closes https://github.com/facebook/react-native/pull/8324
Reviewed By: javache
Differential Revision: D3508822
Pulled By: davidaurelio
fbshipit-source-id: 441b2d4d40265b6036559c3ccb9fa962999fa5df
Summary:
In recent change in 2f73ca8 all javascript files under UIExplorer were moved to js subfolders but PanResponderExample link wasn't updated accordingly.
Closes https://github.com/facebook/react-native/pull/8725
Differential Revision: D3554851
fbshipit-source-id: 798b9a76ecb667512a23a405d0fee0691a9debce
Summary:
Attempt to fix#7919.
Currently, if the app is launched into the background and you read `AppState.currentState` too soon, you will see the value `'active'` instead of `'background'`. This is because the default value of `AppState.currentState` is hardcoded to be `'active'` and it is initialized with the actual value asynchronously.
This attempts to fix the bug by having the `RCTAppState` module provide the initial state as a module constant.
As noted in #7919, it looks like this fix was already tried and reverted with 0fb3d8de83c4d8b79a8a110e9cd1300b39ab8918. zjj010104, hedgerwang, nicklockwood -- can you explain why? I would very much like to get this bug fixed. Nobody has followed up on the issue I filed so I decided to just go ahead and make a PR with my best guess at a fix.
**Test plan (required)**
Built a small app as described in the repro steps for #7919 and verified that, when the app is launched into the background, `init currentState: background` is printed. Also verified that `i
Closes https://github.com/facebook/react-native/pull/8058
Differential Revision: D3554619
fbshipit-source-id: 5d950b85e335765552bbd3cf6ed91534062e35a1
Summary:
I would like to believe it's some black magic code but no it's just a typo.
Closes https://github.com/facebook/react-native/pull/8712
Differential Revision: D3550809
fbshipit-source-id: 00a7ba1cbcd36e29af44cdefd5fc1148d11d26e3
Summary:
NavigationTransitioner prepares for transition within `componentWillReceiveProps`, using previously-saved state to determine how to properly handle new props. If a transition is to take place, the code saves new info in state, executes the transition, and cleans up scenes within `_onTransitionEnd`.
If the transition is a jump-to transition, or otherwise takes very little time, then it is possible for the setState call within `_onTransitionEnd` to use state which hasn't yet been set by the code within `componentWillReceiveProps`, resulting in a failed transition.
This fix ensures that the initial setState call is completed before executing the transition.
Closes https://github.com/facebook/react-native/pull/8709
Differential Revision: D3550872
fbshipit-source-id: 1364612048025f5f970b44cbfd0c31acc4a60f56
Summary: Provide RTL support in NavigationPager
Reviewed By: fkgozali
Differential Revision: D3536850
fbshipit-source-id: 29890a125dc5e001b4c10208cd53bfeca0d9b5c3
Summary: create new RCTI18nManager.js to warp-up native module I18nManager and fix current use of it.
Reviewed By: ericvicenti
Differential Revision: D3547427
fbshipit-source-id: 53a695c94ca6bba2f566d0725c553e58d60bf451