Summary:
This PR is based on files ericvicenti gave me. Specifically, he gave me:
- AccessibilityInfo.android.js
- AccessibilityInfo.ios.js
- AccessibilityInfoModule.java
Before this change, only a native iOS implementation of AccessibilityInfo existed. This change includes:
- A native Android implementation of AccessibilityInfo.
- JavaScript wrappers for the AccessibilityInfo module for both iOS and Android.
- UIExplorer changes to illustrate how to use AccessibilityInfo on iOS and Android.
- Documentation for the AccessibilityInfo APIs.
**Test plan (required)**
Tested the UIExplorer AccessibilityInfo example on iOS and Android with the screen reader both enabled and disabled.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12273
Reviewed By: mkonicek
Differential Revision: D4527224
Pulled By: ericvicenti
fbshipit-source-id: d04638465ccbdbb35ecfc9504daaeb8e33aab57a
Summary:
Android API 15 still have 1.5~2.0% distribution (refer: [Dashboard - Android Developer](https://developer.android.com/ndk/guides/standalone_toolchain.html#creating_the_toolchain)).
React Native is a good tec but many companies cannot endure loose their consumer. [Choreographer](https://developer.android.com/reference/android/view/Choreographer.html) triggered UI operation is the only reason that React Native Android sdk use minSdkVersion 16, so we can use a backward solution **only in API 15**: [Handler](https://developer.android.com/reference/android/os/Handler.html).
In this PR, the biggest change is :
- Make core operation of ReactChoreographer to an interface: ReactUIDriver;
- Impl ReactUIDriver by Handler => UIDriverHandlerImpl, refactor ReactChoreographer to UIDriverChoreographerImpl;
- Let UIDriverFactory to choose which one impl would be in use. (Only use handler in api 15).
Closes https://github.com/facebook/react-native/pull/12396
Reviewed By: AaaChiuuu
Differential Revision: D4588399
Pulled By: astreet
fbshipit-source-id: 76408e53664314dd926e6a553cde6bafbd37779e
Summary:
This PR fixes#6332
The issue is that Android Framework will return the same drawable instance for all requests if they request for the same resource. So the changes on the drawable instance will affect all users(`TextInput` in this case). The solution is very easy, call `mutate()` before change it will get a new drawable instance which make sure the change doesn't affect other users.
Closes https://github.com/facebook/react-native/pull/12493
Differential Revision: D4620034
Pulled By: astreet
fbshipit-source-id: a7b10fbc7447e01132b7ca0e1f78413796493e07
Summary: Adding providesModule annotations to files that don't have a `providesModule` annotation but are in directories that packager crawls.
Reviewed By: cpojer
Differential Revision: D4612455
fbshipit-source-id: b23f0d6bbe2d26f480e93b56b67c6c8b1075e9f7
Summary:
This PR will:
- add missing documentation for `caretHidden` prop to the docs
- add `caretHidden` prop implementation for Android
I noticed this by accident when looking at `RCTTextFieldManager.m` and there is `RCT_EXPORT_VIEW_PROPERTY(caretHidden, BOOL)` which hides caret on iOS. Then I realised that the docs were missing for this prop and implementation on Android side :)
Render `TextInput` with prop `caretHidden`. After this caret is not visible anymore.
`<TextInput style={styles.input} caretHidden />`
If you omit the prop then caret is visible again
`<TextInput style={styles.input} />`
Closes https://github.com/facebook/react-native/pull/11863
Differential Revision: D4448402
fbshipit-source-id: 456e1df3e2cbb8af32540d2c7a8f4e7da219f5c3
Summary:
Developers are complaining about horrible lag (https://github.com/facebook/react-native/issues/11809) caused by PR https://github.com/facebook/react-native/pull/11222.
The issue was that hasNewLayout in yoga is actually a dirty bit and indicates that either you OR one of your children has a new layout. We still need to manually check whether the component's layout actually is different from before.
Reviewed By: sahrens
Differential Revision: D4597545
fbshipit-source-id: 27d4605afd00badfdcdacae740ee2e477adee929
Summary:
Native animated events sometimes end up lagging a frame behind on android because we perform the update in the normal animation loop instead of doing it immediately when we receive the event. We had the same issue on iOS and was fixed in a similar way.
Moved some code around to have a method that updates a list of node that we can use to update the node in the animated event handler and also use it in the animation update loop.
**Test plan**
Tested that it did fix sticky headers lagging a frame behind during momentum scrolling in my PR #11315 and also tested the native animations examples still work properly.
Closes https://github.com/facebook/react-native/pull/11994
Reviewed By: mkonicek
Differential Revision: D4488977
Pulled By: sahrens
fbshipit-source-id: 831a1565bc7b8fa88cadd5a8c1be876fbdefbf66
Summary:
Since we are reading from a file, we should make sure this struct is packed, just in case we change it down the line and the compiler decides it might want to introduce padding, we're now protected against that.
There was also a discussion about the fact that people might use `ptr += sizeof(BundleHeader)` as an idiom in their code, which would currently be incorrect, if padding was introduced at the end of the file. Actually, it remains incorrect to do that now, because a RAM bundle header is a different size to a BC Bundle header. If people are properly testing their code, they should spot this pretty quickly, because it will always be an incorrect thing to do with a RAM bundle, so this isn't as bad as previously thought: where the code only succeeds when the compiler deigns to not pad the struct at the end.
This diff also cleans up how headers are initialised. `BundleHeader` has a constructor that explicitly zero-initialises it so we can rely on the default initializer to do the right thing now.
Reviewed By: mhorowitz
Differential Revision: D4572032
fbshipit-source-id: 7dc50cfa9438dfdfb9f842dc39d8f15334813c63
Summary:
A copy of https://github.com/facebook/react-native/pull/7791 because of our very imperfect tools that mirror the changes from pull requests in the fb monorepo. The internal Phabricator revision for #7791 is in an 'abandoned' state (by foghina probably because of changing teams) and Phabricator doesn't allow me to claim that revision and merge it. Therefore I'm creating a new one.
(It's not foghina's fault, no one probably knew about this "abandoned Phabricator revision" edge case, don't remember we hit it before.)
Will try to keep attribution (git blame) to rigdern when merging.
Closes https://github.com/facebook/react-native/pull/12448
Differential Revision: D4584743
Pulled By: mkonicek
fbshipit-source-id: 66e5b88134fca1980adc4cd8a2ff17c42e10022c
Summary: We're logging all console logs from webview. This strips console logging for non debug builds
Reviewed By: AaaChiuuu
Differential Revision: D4578071
fbshipit-source-id: 79b21012a6ef215eb35701911662a720cb6be280
Summary:
This matches the behavior on iOS, there was no way before to change the cursor color per input, it was only possible to change it globally via the theme. Ideally cursor color and selection color would be 2 different props but I think this is better than what we have (and matches iOS).
Sadly there is no api to change it pragmatically (only possible via xml) so this uses reflection and can easily break so it is wrapped in a try catch to avoid crashes. I think it is better to just silently fail in this case. Definetly not super happy about the solution but I think it's worth adding since it is possible to do it natively using xml so it would suck not to be able to do it in RN.
**Test plan**
Tested that the cursor has the same color as before the change when not setting the prop and that it gets the selectionColor color when set.
Closes https://github.com/facebook/react-native/pull/12280
Differential Revision: D4571858
Pulled By: astreet
fbshipit-source-id: 7dca2db33a0a4eecb6115b45155549b1265ffbed
Summary:
I couldn't resist to do this 😄#394
This adds ```flex-wrap: wrap-reverse```
I think we hit a edge case here:
https://stackoverflow.com/questions/33891709/when-flexbox-items-wrap-in-column-mode-container-does-not-grow-its-width
as is differs here from chrome, but I think that yoga is here more correct.
So I haven't added this test yet as this would fail against chrome, as chrome outputs a width of 30 for root, whereas yoga gets a width of 60 here, which I think is correct. Strangely the output of ```flex-wrap:wrap``` is in jsfiddle also only with a (visual) width of 30 on chrome, while the tests gets generated with 60.
```html
<div id="wrap_reverse_column" style="height: 100px; flex-wrap: wrap-reverse">
<div style="height: 30px; width: 30px;"></div>
<div style="height: 30px; width: 30px;"></div>
<div style="height: 30px; width: 30px;"></div>
<div style="height: 30px; width: 30px;"></div>
</div>
```
Looking forward what you think here emilsjolander
Closes https://github.com/facebook/yoga/pull/398
Reviewed By: astreet
Differential Revision: D4564711
Pulled By: emilsjolander
fbshipit-source-id: 33dc055abd8444b2aa7796ef90bd7ec99e961bb8
Summary:
...to reflect the modern world we live in with dynamic DPI platforms :)
Closes https://github.com/facebook/yoga/pull/375
Reviewed By: dshahidehpour
Differential Revision: D4528518
Pulled By: emilsjolander
fbshipit-source-id: e422bd4ae148e02c598a7b484a6adfa8c0e1e0c9
Summary:
Even so I know there are some opinions against ```margin: 0 auto``` it's still part of the spec: https://www.w3.org/TR/css-flexbox-1/#auto-margins and pretty usefull if you have to position via ```justify-content```.
This PR adds an implementation for that.
It adds an additonal ```YGUnitAuto``` and margins got ```YGNodeStyleSetMarginAuto``` functions as well.
Closes https://github.com/facebook/yoga/pull/357
Reviewed By: astreet
Differential Revision: D4501142
Pulled By: emilsjolander
fbshipit-source-id: 86519f8632496f46e78a7c9dbc5b21e212e3e0c7
Summary:
The PR description has been updated to reflect the new approach.
**Breaking Change Summary**
On Android, the following properties now return a different number:
- `Dimensions.get('window').fontScale`
- `Dimensions.get('screen').fontScale`
- `PixelRatio.getFontScale()`
This is a breaking change to anyone who was using these properties because the meaning of these properties has now changed.
These properties used to return a value representing font scale times density ([`DisplayMetrics.scaledDensity`](https://developer.android.com/reference/android/util/DisplayMetrics.html#scaledDensity)). Now they return a value representing just font scale ([`Configuration.fontScale`](https://developer.android.com/reference/android/content/res/Configuration.html#fontScale)).
**PR Description**
This PR changes a few things:
- Correctly exposes the font scale to JavaScript as `Dimensions.get('screen').fontScale`. UIManager was exporting `DisplayMetrics.scaledDensity` under the name `fontScale`. How
Closes https://github.com/facebook/react-native/pull/11008
Differential Revision: D4558207
Pulled By: astreet
fbshipit-source-id: 096ce7b28051325dfd45fdb2a14b5e9b7d3bc46f
Summary:
cc astreet
The goal of this PR is to enable the buck module `uimanager` to depend on `modules/core` without introducing any dependency cycles.
PR #11008 relies on this PR. PR #11008 needs `uimanager` to depend on `modules/core` so that `uimanager` can fire events using `RCTDeviceEventEmitter` which is in `modules/core`.
This PR moved a number of classes and interfaces:
- `com.facebook.react.modules.debug.DeveloperSettings` -> `com.facebook.react.modules.debug.interfaces.DeveloperSettings`
- `com.facebook.react.devsupport.DevOptionHandler` -> `com.facebook.react.devsupport.interfaces.DevOptionHandler `
- `com.facebook.react.devsupport.DevSupportManager` -> `com.facebook.react.devsupport.interfaces.DevSupportManager`
- `com.facebook.react.devsupport.DevServerHelper.PackagerStatusCallback` -> `com.facebook.react.devsupport.interfaces.PackagerStatusCallback`
- The class `com.facebook.react.devsupport.StackTraceHelper.StackFrame` was renamed to `StackFram
Closes https://github.com/facebook/react-native/pull/12329
Differential Revision: D4551160
Pulled By: astreet
fbshipit-source-id: 3a78443c4f30469b13ddfbdcc9bbef6af9e8381a
Summary:
Adds the two missing alignments ```space-between``` and ```space-around``` for ```align-content``` . Those values are a noop on ```align-items``` in order to prevent a breaking changes for an additional enum.
Fix#229
Closes https://github.com/facebook/yoga/pull/364
Reviewed By: gkassabli
Differential Revision: D4528561
Pulled By: emilsjolander
fbshipit-source-id: ea6291b6dd22cef05d9eec03893250d50371236e
Summary:
If we throw an exception from a UIOperation, the UI is likely in a bad state and we shouldn't execute any other operations on it. In non-dev mode, this would mean we've crashed and don't have to worry about that. But in dev mode, we may have shown a redbox and the instance is still active. This means doing something like reloading, which will trigger onPause and thus flush more UI operations, can crash the app while its sitting on a red box.
This diff aims to prevent that by no longer executing UI operations after one has thrown an exception.
Reviewed By: AaaChiuuu
Differential Revision: D4536925
fbshipit-source-id: 15c21bb76ad3419a54d9d5de94b6bd1f70a3e4a4
Summary: Activity lifecycle events in native modules can cause exceptions: we should redbox them like we do all other application-logic triggered exceptions.
Reviewed By: AaaChiuuu
Differential Revision: D4537111
fbshipit-source-id: 71abf8696173a3d647e858c4ea316a169ad2d8ef
Summary:
Don't call OnBatchComplete on NativeModules that have'nt been initialized.
Also a follow up to D4479604. This also removes the extra allocation of OnBatchCompleteListener per NativeModule that implements OnBatchCompleteListener.
This means NativeModules which implement OnBatchCompleteListener will have to be explicitly initialized or called into before the OnBatchCompleteListener of that NativeModule will be triggered.
Reviewed By: javache
Differential Revision: D4483682
fbshipit-source-id: 6a9431c82f72d17605d1c1e0ee9194f8d8fc2ddc
Summary: Like GuardedAsyncTask, et al, but for Runnables.
Reviewed By: achen1
Differential Revision: D4537287
fbshipit-source-id: 8ae60c7007843c0b7d8e5c3835d0847921fb3db5
Summary:
Some nodes have a value of NaN initially so if we assign the value of the input in the constructor it is possible we get NaN as a value and then it will break when trying to update the value. Initializing at 0 is actually fine with this node since it will get updated properly in the `update` method.
**Test plan**
Tested in an app that uses native animated diffclamp where I noticed the issue. Made sure this change fixed it.
Closes https://github.com/facebook/react-native/pull/12279
Differential Revision: D4527866
fbshipit-source-id: add3fc0d86ffcf4ddcd01ff3251f2373eeaa2cf5
Summary: We deprecated `transformMatrix` and `decomposedMatrix` in D3239960 10 months ago. This revision finally removes remains of this functionality from native code.
Reviewed By: mmmulani
Differential Revision: D4515760
fbshipit-source-id: b4d5b7e834ac4a775f4992b28270b4ff961889a6
Summary:
Fix#241 and successor for #302
Added new property ```display``` with ```YGDisplayFlex``` and ```YGDisplayNone```. Allows to hide nodes from the layout without the need to remove it from the DOM.
Closes https://github.com/facebook/yoga/pull/369
Reviewed By: astreet
Differential Revision: D4501141
Pulled By: emilsjolander
fbshipit-source-id: 0dfeee381f6d1e4bbba81926126b83dd7abab9d6
Summary:
Corresponding iOS PR: https://github.com/facebook/react-native/pull/11002
This adds an onScroll event to TextInput which is useful when a multiline TextInput has so much content that it is scrollable.
**Test plan (required)**
Verified the event works properly in a test app. Also, my team uses this event in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11001
Differential Revision: D4220941
Pulled By: mkonicek
fbshipit-source-id: 7e420579946f2ae840c9e1fcdc8afab68007da17
Summary:
Fixes LayoutAnimation when animating the position of a view that has a transform, the animation would start at the wrong position, offset by the transform translation value. I noticed this bug while working on sticky headers using animated in the UIExplorer <ListView> - Paging example.
**Test plan**
Made a simple repro for the bug https://gist.github.com/janicduplessis/eb985dc3accfd5982c77761be692e395 and tested that it fixed it. Also tested that the UIExplorer <ListView> - Paging example with sticky headers worked properly with this fix.
Closes https://github.com/facebook/react-native/pull/12140
Differential Revision: D4494389
Pulled By: mkonicek
fbshipit-source-id: dd49cb2db9dd4950e293596fbc773f7d79e8b10a
Summary:
This prop exposes the functionality provided by Android ScrollView's setOverScrollMode method.
One interesting thing to note is that, if you were to read the Android docs, you would think that the value "always" is the default over scroll mode. However, the docs are incorrect and "always-if-content-scrolls" is actually the default value (http://stackoverflow.com/a/27116306).
**Test plan (required)**
Verified this change in a test app. Also, our team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10905
Differential Revision: D4500957
Pulled By: mkonicek
fbshipit-source-id: 873eba38183defba133c228e0c1038efa83297d3
Summary:
The DCIM folder is a better mapping to a "CameraRoll" than the "movies" or "pictures" directories.
https://developer.android.com/reference/android/os/Environment.html#DIRECTORY_DCIM
```
DIRECTORY_DCIM
The traditional location for pictures and videos when mounting the device as a camera.
Note that this is primarily a convention for the top-level public directory, as this convention makes no sense elsewhere.
```
**Test plan**
- Make sure tests pass on both Travis and Circle CI.
- Test `saveToCameraRoll` in an example app, and check it is saved to the expected folder in a photos app.
Closes https://github.com/facebook/react-native/pull/12059
Differential Revision: D4500946
Pulled By: mkonicek
fbshipit-source-id: 8af994492303c175374502dffe6fd2f3e4e9975e
Summary:
Especially for newcomers, this may help since some may think the effect is immediate.
Closes https://github.com/facebook/react-native/pull/12066
Differential Revision: D4500929
Pulled By: mkonicek
fbshipit-source-id: dfa05134f208c084dacb3e490fe9eb8df323ffd5
Summary: `RecyclerViewBackedScrollView` was added a long time ago to work around the scroll-back-when-data-is-added bug, but that has now been fixed directly in the `ScrollView` (`ReactScrollView.java`) in open source and internally.
Reviewed By: astreet
Differential Revision: D4482105
fbshipit-source-id: 208f21f00045d5c5a83b74ad69b3db6fa63391d7
Summary:
**Motivation**
Ability to customize slider colors is desirable to match the brand. Currently iOS allows using images for slider parts, but android doesn't have any customization options. This PR adds support for customizing `thumbTintColor`, `trackTintColor` and `progressTintColor`.
**Test plan (required)**
Run UIExplorer example with the changes and verify everything works fine.
![image](https://cloud.githubusercontent.com/assets/1174278/22020752/f32a6eec-dcdf-11e6-928d-481bb28bd0a3.png)
cc brentvatne
Closes https://github.com/facebook/react-native/pull/11946
Differential Revision: D4427474
fbshipit-source-id: ec3a38db600bac6108691a4cfa15e2409143b9f3
Summary:
We were noticing the following crash in our application, that was occurring fairly often, but still hard to reproduce:
```
12-12 10:37:35.342: E/AndroidRuntime(9064): FATAL EXCEPTION: main
12-12 10:37:35.342: E/AndroidRuntime(9064): Process: com.bloomberg.android.plus, PID: 9064
12-12 10:37:35.342: E/AndroidRuntime(9064): java.lang.NullPointerException: Attempt to invoke interface method 'void com.facebook.react.uimanager.UIViewOperationQueue$UIOperation.execute()' on a null object reference
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQueue$2.run(UIViewOperationQueue.java:782)
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:829)
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQueue.access$1500(UIViewOperationQueue.java:44)
12-12 10:37:35.342: E/AndroidRuntime(9064): at com.facebook.react.uimanager.UIViewOperationQ
Closes https://github.com/facebook/react-native/pull/11428
Differential Revision: D4487841
Pulled By: astreet
fbshipit-source-id: ae49ef77967edea7514cbf40cb533c4b63fd34ae
Summary:
This is a followup for https://github.com/facebook/react-native/pull/12088 and implements the scrolling to end on Android natively rather than sending a large scroll offset from JS.
This turned out to be an OK amount of code, and some reduction in the amount of JavaScript. The only part I'm not particularly happy about is:
```
// ScrollView always has one child - the scrollable area
int bottom = scrollView.getChildAt(0).getHeight() + scrollView.getPaddingBottom();
```
According to multiple sources (e.g. [this SO answer](http://stackoverflow.com/questions/3609297/android-total-height-of-scrollview)) it is the way to get the total size of the scrollable area, similar to`scrollView.contentSize` on iOS but more ugly and relying on the fact the ScrollView always has a single child (hopefully this won't change in future versions of Android).
An alternative is:
```
View lastChild = scrollLayout.getChildAt(scrollLayout.getChildCount() - 1);
int bottom = lastChild.getBottom() + scrollLayout.getPadd
Closes https://github.com/facebook/react-native/pull/12101
Differential Revision: D4481523
Pulled By: mkonicek
fbshipit-source-id: 8c7967a0b9e06890c1e1ea70ad573c6eceb03daf
Summary:
According to #11992 fix skew transform in native code as well
janicduplessis vjeux
Closes https://github.com/facebook/react-native/pull/12106
Differential Revision: D4479880
fbshipit-source-id: d84780842b555f6352d84d229b5b6c5c3c6a0647