Summary:
The actual badgeColor prop causes the following error when run on device with a version inferior to iOS 10 like iPad 2 and iPad mini 1.
`*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UITabBarItem setBadgeColor:]: unrecognized selector sent to instance 0x7968be80'`
This PR fixes it by checking at runtime if the selector is available for the current running version.
It also makes the color available at start by using the variable `self.barItem`. Currently, the color appears only after a reload.
Closes https://github.com/facebook/react-native/pull/12354
Differential Revision: D4598036
Pulled By: shergin
fbshipit-source-id: 9f104fc27db51213a54273e33c5a22f1b350c55e
Summary:
In some cases, the accessibilityLabel contains a leading space. This is because `RCTRecursiveAccessibilityLabel` adds a space before every iteration of the loop including the first.
After this change, the contract is that:
- `RCTRecursiveAccessibilityLabel` always returns a string with a leading space.
- `accessibilityLabel` never returns a string with a leading space.
**Test plan**
I created a test app with the following code:
```
<View style={{height: 100, width: 100, backgroundColor: 'steelblue'}} accessible={true}>
<View style={{height: 20, width: 20, backgroundColor: 'red'}} accessibilityLabel='One' />
<View style={{height: 20, width: 20, backgroundColor: 'yellow'}} accessibilityLabel='Two' />
<View style={{height: 20, width: 20, backgroundColor: 'green'}} accessibilityLabel='Three' />
</View>
```
Before this change, the accessibilityLabel of the outermost View was " One Two Three" (notice the leading space).
After this change, it is "One Two Three" as desired.
Adam
Closes https://github.com/facebook/react-native/pull/12269
Reviewed By: javache
Differential Revision: D4596761
Pulled By: shergin
fbshipit-source-id: 7d5ff704e858d9f277d1547339a2831ffa90f592
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:
Now things look much more clear, I hope.
This diff:
* Introduces new property of `RCTRootShadowView` `availableSize` which represents exactly what we transmit to layout engine;
* Illuminates conflict between logical `availableSize` and explicitly specified size of DOM node (current `size`);
* Splits overcomplicated `setSize:forView:` method into two unrelated ones;
* Changes actual values of `RCTRootViewSizeFlexibility` enum constants for simpler usage;
* Completely removes `sizeFlexibility` concept from `RCTRootShadowView` (in favor of special values of `availableSize`);
* Makes the code clearer finally.
This is beginning of big effort to improve `RCTRootView` and co.
Reviewed By: mmmulani
Differential Revision: D4562834
fbshipit-source-id: f5baaf2859ea430d44645a6b5d35f222f15a668e
Summary: With the Cxx bridge, properties are not guaranteed to be set it any order (and furthermore, they should not be). RCTRefreshControl previously had its title set first, and would crash otherwise. This fixes that.
Reviewed By: mhorowitz
Differential Revision: D4580253
fbshipit-source-id: 39baecceb8b67c6a851c08ba9cabbf4dc99359cb
Summary: I broke Circle CI builds by moving a file, so I am updating the OSS build setup with details of the move. Whilst I was testing the change, I noticed that the UI Explorer build was also already broken, so this diff also changes some of its configuration to make it build again.
Reviewed By: javache
Differential Revision: D4579137
fbshipit-source-id: 4cbb1ef148075280b991cbc5bb47bf96ec3d543a
Summary: This method was defined in the .m file already, so we can just expose it to the header for other usages.
Reviewed By: mmmulani, shergin
Differential Revision: D4557942
fbshipit-source-id: a1be8af8e31b88a152cabfab6d4cf82316088572
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: 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: Now layout direction (LTR or LTR) can be specified not only for whole app but also for view subtree via `direction` style property.
Reviewed By: mmmulani
Differential Revision: D4510206
fbshipit-source-id: 4e56c5886b6e42f2343165eb76be897e681c5ba4
Summary:
Motivation:
* `RCTShadowView`'s `frame` property actually represents computed layout of the view. We must not use it as a setter for yoga node styles;
* Using `frame` and `setLeftTop` in existing way actually works only for view with absolute positioning, so it is super rare and special case;
* Internally, setting `frame` only make sense to `RootView`, and in that case there we always must not change `origin` we are introducing `setSize` method.
Changes:
* `[-RCTShadowView setFrame:]` was removed, `frame` property is readonly now;
* `[-RCTShadowView setLeftTop:]` was removed; no replacement provided;
* `[-RCTShadowView size]` read-write property was added;
* `[-RCTUIManager setFrame:forView:]` was deprecated, use (just introduced) `setSize:forView:` instead;
* `[-RCTUIManager setSize:forView:]` was added.
If you are still need some of removed methods, you are probably doing something wrong. Consider using `setIntrinsicContentSize`-family methods,
`setSize`-family methods, or (in the worst case) accessing `yogaNode` directly.
Reviewed By: javache
Differential Revision: D4491384
fbshipit-source-id: 56dd84567324c5a86e4c870a41c38322dc1224d2
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
Summary:
Eliminates a build warning related to the use of the deprecated `NSStringArray` typedef.
This fix was more complex than I'd anticipated because `NSStringArray` was also being used as part of a macro-generated selector name, and in two different ways for debug/release. I've added a macro which allows the selector name to be specified explicitly, thus generally allowing for converters which return arrays of templated types.
There's an argument for ditching `RCT_JSON_ARRAY_CONVERTER` in favour of `RCT_JSON_ARRAY_CONVERTER_NAMED` as they're both private, but `RCT_ARRAY_CONVERTER` is in the public API so we'd at least need to retain that. There are also arguments for ditching the use of the macro for the nested array case(s) - since afaik this is the only one at the moment. Feedback appreciated :)
Tested with the `UIExplorer` unit tests and by diffing the preprocessor output of `RCTConvert.m` in both release and debug configs, verifying that they're identical apart from that `NSStringArray` is replaced by
Closes https://github.com/facebook/react-native/pull/11799
Differential Revision: D4441197
fbshipit-source-id: 7535ebe6f8ad4566df742e805b0a64530d1b269f
Summary:
In theory, we should be able to animate any non-layout property, including custom ones. While there is still work to be done on the native side to fully enable this, we should start by dropping the prop whitelist.
Closes https://github.com/facebook/react-native/pull/10658
Differential Revision: D4379031
Pulled By: ericvicenti
fbshipit-source-id: fe9c30ea101e93a8b260d7d09a909fafbb82fee6
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
This change is required when you try to set a focus on a view that doesn't exist and thus cannot be focused. In my specific use case, this occurred when trying to set a focus on a list item in a setInterval when the View (with the specific list item) had been popped. The while loop ran infinitely (eventually freezing the app) since the rootView doesn't exist. This adds that check and breaks out if so.
All obj-c tests ran successfully.
dlowder-salesforce
Closes https://github.com/facebook/react-native/pull/12073
Differential Revision: D4468989
Pulled By: ericvicenti
fbshipit-source-id: 7926c887035722c983c41cb6b6d9df567010c2ee
Pieter De Baets
Benoit VALLON
Adam Comella
Valentin Shergin
Ashok Menon
Mathieu Baudet
Mehdi Mulani
Alexey Lang
Emil Sjolander
Lukas Piatkowski
Kevin Gozali
David Hart
Lukas Wöhrl
Ciprian Pãtru
Marc Horowitz
Max Graey
Rob Hogan
rh389
Martin Konicek
Ryan Gomba
Eric Vicenti