Summary: The method FabricUIManager.scheduleMountItems receives only one MountItem, is makes more sense to be called FabricUIManager.scheduleMountItem
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D16062749
fbshipit-source-id: a27063be33b644af83ede6a9198edbfb1c3296e1
Summary: I've been analyzing some issue in RN Android code and I noticed some warnings to clean up
Reviewed By: ejanzer
Differential Revision: D16060522
fbshipit-source-id: 327fa86c24c7dd67ac2376bbd2f0ca4339f106d1
Summary: This diff exposes LayoutDirection as part of UpdateLayoutMountItem
Reviewed By: JoshuaGross
Differential Revision: D16060521
fbshipit-source-id: 163bf2a0bdca62dcecb03a8aaa2f4bf595b18c8f
Summary:
This diff adds support to Update Modal State when there is a change on the size of the screen
// TODO
Reviewed By: JoshuaGross
Differential Revision: D16000755
fbshipit-source-id: be87caa6d7f85c3d2778d2707c1e0cd821d6f6c6
Summary: After we ran google-java-format D16071725, some Javadocs which weren't properly written broke. This includes putting unordered and ordered lists not using <ul> and <ol>, putting code blocks and pseudo-graphics not using <pre>. I ran through all the changed classes and tried to fix the broken Javadocs.
Reviewed By: cpojer
Differential Revision: D16090087
fbshipit-source-id: f31971cbc0e367a04814ff90bbfb2192751d5e16
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
ScrollView doesn't handle the scrollEnabled property using dpad. When set to false, the directionnal pad still allows to scroll in the view.
## Changelog
[ANDROID] [ADDED] - Prevent scrollView to scroll with dpad when scrollEnabled property is set to false.
Pull Request resolved: https://github.com/facebook/react-native/pull/25309
Test Plan:
Add P67680731 to Playground.js and start the Catalyst Android app:
```buck install -r catalyst```
Send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_LEFT```
```adb shell input keyevent DPAD_RIGHT_RIGHT```
Make sure the ScrollView doesn't scroll to the left and right.
Add ```horizontal={true}``` to ScrollView and send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_TOP```
```adb shell input keyevent DPAD_RIGHT_BOTTOM```
Make sure the ScrollView doesn't scroll to the top and bottom.
Reviewed By: mdvacca
Differential Revision: D15983785
Pulled By: makovkastar
fbshipit-source-id: 678cc801a168531d71c8651b986c99ecd9da400e
Summary:
Right now JS triggers a view manager command with the following code:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
UIManager.getViewManagerConfig('RCTView').Commands.hotspotUpdate,
[destX || 0, destY || 0],
);
```
As we want to get rid of calls to UIManager, we need to stop looking for the integer defined in native from JavaScript. We will be changing methods like this to be:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
'hotspotUpdate',
[destX || 0, destY || 0],
);
```
We need to support ints and Strings to be backwards compatible, but ints will be deprecated.
Reviewed By: shergin
Differential Revision: D15955444
fbshipit-source-id: d1c488975ae03404f8f851a7035b58a90ed34163
Summary: This diff fixes a typo in the JavaDoc for ReactScrollViewManager.
Reviewed By: cpojer
Differential Revision: D15965028
fbshipit-source-id: 3506cdde21c8d00ab916455a2d9fa29772f35359
Summary:
On Android, if the ActivityIndicator component is initially set to `animate={false}`, it does not display if later set to `true` (https://github.com/facebook/react-native/issues/9023)
For some reason, the layout width/height of the associated ProgressBar remains 0, despite the parent layout having the correct width/height:
I wasn't able to determine why this is the case, but I did notice that changing the visibility settings from `View.GONE` to `View.INVISIBLE` fixes the issue while not (as far as I can tell) having an impact on the React Native layout:
#### Before:
#### After:
Using `View.INVISIBLE` appears to alleviate the issue.
This should fix https://github.com/facebook/react-native/issues/9023
## Changelog
[Android][fixed] - ActivityIndicator appears as expected when `animated={false}` is later set to `true`.
Pull Request resolved: https://github.com/facebook/react-native/pull/25354
Test Plan:
Link this branch to a new React native project with the following App.js class:
```javascript
import React, { Component } from "react";
import {
StyleSheet,
Text,
Button,
View,
ActivityIndicator,
TouchableHighlight
} from "react-native";
export default class App extends Component {
constructor() {
super();
this.state = {
show: false
};
}
hide = () => {
this.setState({ show: false });
};
show = () => {
this.setState({ show: true });
};
render() {
return (
<View>
<ActivityIndicator
animating={this.state.show}
size="large"
style={styles.indicator}
/>
<ActivityIndicator
animating={this.state.show}
size="small"
style={styles.indicator}
/>
<View style={{ flexDirection: "row" }}>
<Button title="Hide" style={styles.button} onPress={this.hide} />
<Button title="Show" style={styles.button} onPress={this.show} />
</View>
<Text>Showing ? {this.state.show.toString()}</Text>
</View>
);
}
}
const styles = StyleSheet.create({
indicator: {
borderColor: "red",
borderWidth: 1
},
button: {
marginRight: 8
}
});
```
Differential Revision: D15963366
Pulled By: cpojer
fbshipit-source-id: ee3df3fd84acbff342599dc6f4f4a391704876fa
Summary:
I found that on Android we only support 2 fontWeight options, either **normal** or **bold**, even developer can set any numeric value. But iOS supports all possible numeric values. This PR tries to add support for all possible numeric values on Android, even if it's supported only on Android P(28) and above.
This change might break texts where fontWeight use improperly, because this PR removes conversion of values above 500 to BOLD and below 500 to normal.
FYI, also moved **mCustomTypefaceCache** usage up because it was working after unnecessary mFontCache usage.
## Changelog
[Android] [Changed] - add custom font weight support to Text component on Android, only on P(API 28) and above versions.
Pull Request resolved: https://github.com/facebook/react-native/pull/25341
Test Plan: RNTester app's Text examples will show Rubik Regular, Rubik Light, Rubik Bold, Rubik Medium and Rubik Medium Italic texts in corresponding font family, style and weights.
Differential Revision: D15956350
Pulled By: mdvacca
fbshipit-source-id: 61079d953c65fb34ab4497d44c22317912a5a616
Summary:
Similar to D15909582, this change makes the Android TextInput take strings for the value of autoCapitalize and not just numbers. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style.
Changelog:
[Android] [Internal] - Supporting autoCapitalize as string to clean up internal TextInput.js file
Reviewed By: mdvacca
Differential Revision: D15911323
fbshipit-source-id: b236fdb314489cc1ef33f9214ff2d6b0e28b7310
Summary:
Previously DrawerLayoutAndroid required taking an int as the drawerPosition. This required a complex dance of pulling these constant values off of the native view config. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style. The old way of specifying the sizes will go away in a future release.
Changelog:
[Android][Added] - DrawerLayoutAndroid now supports strings and not just numbers for drawerPosition.
Reviewed By: mdvacca
Differential Revision: D15912607
fbshipit-source-id: b444454a1e74f8f659995b9ebe5e164ac9660138
Summary:
This is a follow up PR to https://github.com/facebook/react-native/issues/24359. There's a good thread in the mentioned PR for more background for why I'm doing this change. Essentially `focusable` makes more sense since it is about whether a view can receive user-initiated focus from a pointer or keyboard.
Pull Request resolved: https://github.com/facebook/react-native/pull/25274
Differential Revision: D15873739
Pulled By: cpojer
fbshipit-source-id: 0f526bb99ecdc68131dfc10200a5d44c2ef75b33
Summary:
Previously SwipeRefreshLayout (RefreshControl on Android) required taking an int as the size. This required a complex dance of pulling these constant values off of the native view config. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
We will change the type of size from:
```
size?: ?(
| typeof RefreshLayoutConsts.SIZE.DEFAULT
| typeof RefreshLayoutConsts.SIZE.LARGE
),
```
to:
```
size?: ?('default' | 'large')
```
In this commit we are supporting the old style as well as the new style. The old way of specifying the sizes will go away in a future release.
Changelog:
[Android] [Added] - RefreshControl now supports strings and not just numbers for size.
Reviewed By: mdvacca
Differential Revision: D15909582
fbshipit-source-id: 1849edc980e1698de147e88d710e0f28d0fdc8d8
Summary:
There's an issue with TextInput on Android where if you have TalkBack enabled, double tapping doesn't focus the text input. It turns out this is because we ignore all focus events that aren't from JS in ReactEditText. This diff makes an exception for the accessibility click event.
I think this should also fix https://github.com/facebook/react-native/issues/17624
Reviewed By: lunaleaps
Differential Revision: D15818103
fbshipit-source-id: 354728b58f1023c4d44edd48337c8daa8ea15c0c
Summary:
D14014668 introduced support for nesting views within Text on Android. Part of the implementation involved accessing the UIManagerModule from ReactTextView through context. This doesn't work in bridgeless RN because we have no UIManagerModule, and the ReactContext has no Catalyst instance. Trying to access the Catalyst instance from ReactContext throws an exception if it doesn't exist, so i'm just adding a simple check here to make sure the instance exists before proceeding.
This means that this feature won't work in bridgeless mode, but that's ok for now - eventually we want to change the way this works so that it doesn't rely on accessing views in Java, which is potentially unsafe (there's nothing to stop you from mutating the views, and cpp/js would never know about it).
Reviewed By: mdvacca
Differential Revision: D15703100
fbshipit-source-id: 0448d55b8345fc707a25210a505cb6ac520c708a
Summary:
Scrolling improvements in ReactAndroid:
1.
Issue: With current ReactHorizontalScrollView behavior, it treats all views as focusable, regardless of if they are in view or not. This is fine for non-paged horizontal scroll view, but when paged this allows focus on elements that are not within the current page. Combined with logic to scroll to the focused view, this breaks the paging for ReactHorizontalScrollView.
Fix: limit the focusable elements to only elements that are currently in view when ReactHorizontalScrollView has paging enabled
2.
Issue: When keyboard is attached and user tries to navigate through Tab key, Scroll views do not scroll to the focused child.
Since ReactScrollView handles layout changes on JS side, it does not call super.onlayout due to which mIsLayoutDirty flag in android ScrollView remains true and prevents scrolling to child when requestChildFocus is called.
Fix: To fix the focus navigation, we are overriding requestChildFocus method in ReactScrollView. We are not checking any dirty layout flag and scrolling to child directly. This will fix focus navigation issue for KeyEvents which are not handled by android's ScrollView, for example: KEYCODE_TAB. Same applies to ReactHorizontalScrollView.
3.
Set Android ScrollView to be non-focusable when scroll is disabled. Prior to this change, non-scrollable Scrollview would still be focusable, causing a poor keyboarding experience
## Changelog
[Android] [Fixed] Scrolling improvements in ReactAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/25105
Differential Revision: D15737563
Pulled By: mdvacca
fbshipit-source-id: 0d57563415c68668dc1acb05fb3399e6645c9595
Summary: This moves the Toolbar Java files out RN and into our internal React shell.
Reviewed By: fkgozali
Differential Revision: D15469205
fbshipit-source-id: 15298505d74260618eb89673deb12d1b837b559f
Summary:
This diff fixes the bug of the switch component on Android being stuck in the middle when a user releases their finger whily dragging the thumb.
When a user releases their finger while dragging the thumb, `setChecked` will be called and if `mAllowChange` is set to false, `super.setChecked` is never called. The supper method will actually make sure the thumb will be animated to the correct edge. Without calling the super method, the thumb might stay in the middle of the switch where a user released their finger.
The fix had to be applied both to ReactSwitch and FbReactSwitchCompat.
One more fix had to be made to FbReactSwitchCompat since D5884661 was applied to ReactSwitch, but not to FbReactSwitchCompat:
if (mAllowChange && **isChecked() != checked**) {
...
}
Reviewed By: mdvacca
Differential Revision: D15535611
fbshipit-source-id: 22ca1fe3fa993ae65cbd677bfae2208a02c368d4
Summary:
Add prop showSoftInputOnFocus to TextInput. This fixes#14045. This prop can be used to prevent the system keyboard from displaying at all when focusing an input text, for example if a custom keyboard component needs to be displayed instead.
On Android, currently TextInput always open the soft keyboard when focused. This is because `requestFocus` calls `showSoftKeyboard`, which in turn instructs `InputMethodManager` to show the soft keyboard.
Unfortunately even if we were to define a new input type that extends ReactEditText, there is no way to overcome this issue.
This is because `showSoftKeyboard` is a private method so it can't be overriden. And at the same time `requestFocus` needs to invoke `super.requestFocus` to properly instruct Android that the field has gained focused, so overriding `requestFocus` in a subclass of ReactEditText is also not an option, as when invoking `super.requestFocus` we would end up calling again the one defined in ReactEditText.
So currently the only way of doing this is to basically add a listener on the focus event that will close the soft keyboard immediately after. But for a split second it will still be displayed.
The code in the PR changes `requestFocus` to honor showSoftInputOnFocus as defined in Android TextView, displaying the soft keyboard unless instructed otherwise.
## Changelog
[Android] [Added] - Add showSoftInputOnFocus to TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25028
Differential Revision: D15503070
Pulled By: mdvacca
fbshipit-source-id: db4616fa165643d6ef2b3185008c4d279ae08092
Summary:
Changelog: [Android] [FIXED] - Fix backgroundColor top level prop of TextInput
This diff fixes two issues with the `backgroundColor` top level property of TextInput on Android:
* Now it is possible to set a **string** value for the top-level `backgroundColor` property of TextInput (crashed the app previously):
```
<TextInput backgroundColor="#ffccbb">Hello, React Native</TextInput>
```
* Now it's possible to set an **integer** value for the top-level `backgroundColor` property of TextInput (had no effect previously):
```
<TextInput backgroundColor={0xffccbbff}>Hello, React Native</TextInput>
```
A `customType = "Color"` annotation parameter must be provided for `ReactBaseTextShadowNode.setBackgroundColor(...)` since the color value must be previously processed in JS before sending it over the bridge to the native code. The JS code will parse the color value and return the proper ARGB color integer to the native platforms (https://fburl.com/uqup52tn).
Without providing the custom type for the background color, if a string value is set for the top-level `backgroundColor` property in the JS code, the Android code will crash since it expects an integer value for the color in `ReactBaseTextShadowNode.setBackgroundColor(...)`, but a string will be passed from JS without any conversion and there will be a `ClassCastException` thrown. If an integer value without the alpha component (like `0xffccbb`) is set, the Android native view would get an integer color value with its alpha component set to `0x00`, which means a transparent color.
On a side note: the alpha component of a color must always be set when using an integer value for `backgroundColor` since the JS code, while processing the color type, shifts the rightmost 8 bytes (alpha component) to the leftmost position. If those 8 bytes are not the alpha component, you will get the wrong color in the end. It doesn't seem to be a problem for string values of `backgroundColor` though.
Reviewed By: mdvacca
Differential Revision: D15453980
fbshipit-source-id: f3f5d9c9877cdbce79a67f2ed93ad4589576d166
Summary: As of D14529038, LayoutAnimations can sometimes throw an exception due to the view being null. This can happen when elements are removed/added and is not fixable in product code. This is a temporary fix - the root cause for this issue will be fixed soon.
Reviewed By: lunaleaps
Differential Revision: D15428791
fbshipit-source-id: 41200e572ed7d5d470754792c5576a0ea23fe946
Summary:
We're working on a custom EditText that supports some rich text editing, and one of the places where our logic has to be different from the textinput provided by RN is the text setting logic:
https://github.com/facebook/react-native/blob/7abfd23b90db08b426c3c91b0cb6d01d161a9b9e/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java#L377
However, some of the important members are private and our subclass cannot access them (we work around this now with reflection). It would be nice if we could work with them directly, either using getters and setters or by changing the access. Let me know what you think about this. Thanks.
## Changelog
[Android] [Added] - allow custom maybeSetText logic for ReactEditText subclasses
Pull Request resolved: https://github.com/facebook/react-native/pull/24927
Differential Revision: D15431682
Pulled By: cpojer
fbshipit-source-id: 91860cadac0798a101ff7df6f6b868f3980ba9b1
Summary:
The `measure` API receives LocalData and Props, it should also receive State.
This will also be used in future diffs.
Reviewed By: mdvacca
Differential Revision: D15325182
fbshipit-source-id: 6cb46dd603ce7d46673def16f0ddb517e2cf0c4f
Summary:
Fixes#13351
Two root causes:
1. Android Spinner will reset selection to undefined after setAdapter()
which will trigger onValueChange().
The behavior is not expected for RN.
And the solution is to setSelection() explicitly
2. In original implementation, it setups `items` immediately,
but delays the `selected` setup after update transaction.
There will be some race condition and incosistency
if update `items` only.
The fix will do the setup all after update transaction.
[Android] [Fixed] - Fix#13351 PickerAndroid will reset selected value during items update.
Pull Request resolved: https://github.com/facebook/react-native/pull/24793
Differential Revision: D15293516
Pulled By: cpojer
fbshipit-source-id: 5a99a60015c7e1b2968252cdc0b2661d52a15b9d
Summary:
In https://github.com/facebook/react-native/pull/23865, RN introduced support for custom fonts the Android Way. But it introduced performance regression because it'll lookup for a font using getIdentifier() every time fontFamily changed. This PR fixes regression by requiring custom fonts to be listed in **fonts** array, and populating **mTypeCache** at first use using the list.
[Android] [Changed] - Require custom fonts to list in **fonts** array. Fixes performance regression.
Pull Request resolved: https://github.com/facebook/react-native/pull/24595
Reviewed By: mdvacca
Differential Revision: D15184590
Pulled By: fkgozali
fbshipit-source-id: e3feb2396609583ebc95101130186a1f5af931da
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Summary:
Hello Everyone, this series of commits helps to fix problems related to ART on Android. The main problem in here is that the ART components would disappear if the user turns off the screen and then turn it on again. It's important to note that this behaviour only occurs after Android N (7.1 or higher).
Pull Request resolved: https://github.com/facebook/react-native/pull/22624
Differential Revision: D15122573
Pulled By: cpojer
fbshipit-source-id: e7fb8b9280b4c52562e3d0c1a89759d4d31cd53d
Summary:
React Native Environment Info:
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Memory: 1.12 GB / 15.55 GB
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 8.10.0 - /usr/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 3.5.2 - /usr/bin/npm
SDKs:
Android SDK:
API Levels: 16, 19, 22, 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-16 | Google APIs Intel x86 Atom, android-19 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
npmPackages:
react: 16.8.6 => 16.8.6
react-native: git+https://github.com/facebook/react-native.git#v0.59.5 => 0.59.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
The workaround implemented in https://github.com/facebook/react-native/pull/21117 tries to fix
https://issuetracker.google.com/issues/112385925 scroll direction (according to the latest comments, the scroll direction problem has been reverted in security patches so not sure if the workaround is still valid).
But... proposed solution in fling method is using signum which leads to zero computedVelocityY in case of zero mOnScrollDispatchHelper.getYFlingVelocity() on old devices(Samsung s4 mini) even when real velocityY is non zero
```
final int correctedVelocityY = (int)(Math.abs(velocityY) * Math.signum(mOnScrollDispatchHelper.getYFlingVelocity()));
```
Proposed solution is to take signum from original velocityY in case of zero
```
float signum = Math.signum(mOnScrollDispatchHelper.getYFlingVelocity());
if (signum == 0) {
signum = Math.signum(velocityY);
}
final int correctedVelocityY = (int)(Math.abs(velocityY) * signum);
```
The symptoms are the same as described in issue https://github.com/facebook/react-native/issues/22925, but proposed workaround doesn't work.
[Android][fixed] - Fix smooth scrolling on old devices (SDK >=16)
Pull Request resolved: https://github.com/facebook/react-native/pull/24545
Differential Revision: D15044834
Pulled By: cpojer
fbshipit-source-id: 3f523eb1a438df774e22387aecded433b9031ab9
Summary: It seems like ReactContext isn't actually needed in measure functions. Changing the signature of ViewManager.measure() to take a Context instead.
Reviewed By: lunaleaps
Differential Revision: D14940330
fbshipit-source-id: b29987fd1d7f9c191a5f26138151082ca61cb351
Summary:
In order to meet our accessibility requirements we need to have full support for keyboard navigation. The Touchable components works with press/tap with a finger, but doesn't respond to 'enter' when using a keyboard. Navigation works fine. This PR adds an onClick listener to touchable views that have the onPress prop defined.
[Android] [Added] - Add View.OnClickListener to Touchable components when onPress is defined
Pull Request resolved: https://github.com/facebook/react-native/pull/24359
Differential Revision: D14971230
Pulled By: cpojer
fbshipit-source-id: ca5559ca1308ee6c338532a00dcea4d00fa57f42
Summary: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
Summary:
Would like feedback from the community as this may not be the best solution for all
I would like to restrict (or paginate) the fling of a horizontal ScrollView when `snapToInterval` is set. This is not currently possible with `pagingEnabled`, since the pagination works only when items are the entire width of the ScrollView.
This implementation simply restricts the predicted `targetOffset` found from the `x` velocity and replaces it with the offset when the pan gesture ended.
To get pagination working, I may paginate based on the interval by calculating the offset delta from the beginning of the gesture to current offset and restricting the scrolling behavior to the `snapToInterval`. If this is preferred, I can update this PR or make a new one, but wanted to start a discussion since it seems like there are many in the community that would like this feature #21302 .
[General] [Added] - add prop `disableIntervalMomentum` to disable the predictive scrolling behavior of horizontal ScrollViews
Pull Request resolved: https://github.com/facebook/react-native/pull/24045
Differential Revision: D14939754
Pulled By: sahrens
fbshipit-source-id: 26be19c47dfb8eed4d7e6035df53a77451e23081
Summary: Similar to iOS, here we provide the basic impl of unimplemented view.
Reviewed By: mdvacca
Differential Revision: D14895706
fbshipit-source-id: 9053edfb2175b370d9070b6921794dbcafa1f37a
Summary:
Android API 26 and Android Support Library 26 added support for font resource type and native/downloadable fonts. It allows apps to easily download fonts from online providers, but also use of various font weights other than normal and bold, like medium. So it deprecated APIs for asset fonts, and should be removed in the future.
Advantages:
- Just copy font files in res/font and use it specifying filename (without extension) in fontFamily
- Define custom font-family using XML file (in res/font) and font files, it may have many weights and styles. See PR for example.
- Define configuration to download fonts from online font providers, and use it.
See https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml and https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts
[Android] [Changed] - add support for custom/downloadable fonts
Pull Request resolved: https://github.com/facebook/react-native/pull/23865
Differential Revision: D14506542
Pulled By: hramos
fbshipit-source-id: 67ba3148fb4b548cdbc779213cf6c1b2c3baffd2
Summary:
Fixes#22511
I understand the motivation of adding extraRadiusForOutline to corner radius: without it there can be an empty space between border and view's background color.
So I add simple check: if corner radius is more than zero we still add extraRadiusForOutline. And if not, we don't add it to prevent all the corners to become slightly curved.
[GENERAL] [Fixed] - fix of Android's bug that causes all the corners to become slightly curved if only specific corners' radius should be more than zero.
Pull Request resolved: https://github.com/facebook/react-native/pull/24390
Differential Revision: D14870476
Pulled By: cpojer
fbshipit-source-id: df40fc584a2f8badc499413cb3c4e4d96b9e18cf
David Vacca
Oleksandr Melnykov
soh335
Eli White
aamalric
Nate
Dulmandakh
Sam Mathias Weggersen
Kudo Chien
Emily Janzer
Onti Vals
Christoph Nakazawa
Luna Wei
valerio.ponte
Vojtech Novak
Blair Vanderhoof
Uilque Messias
Joshua Gross
Piotr Trocki
Guilherme Iscaro
Kevin Gozali
Pavel Rotek
Rick Ratmansky
Taylor123
Пётр Потапов
