By having mdc_resolvedColorWithTraitCollection:elevation be an iOS13 only API, it forces the client using this API to have iOS13 checks surrounding this method, when in fact we are already adding those checks inside the method itself, making clients have to do additional work that is unneeded.
Secondly, having the method return nil if it isn't iOS13 and not just return the original color causes clients (and our theming extensions) to add additional checks if its nil and apply the original color otherwise:
```
self.backgroundColor = [self.backgroundColor resolvedColorForTraitCollection:self.traitCollection elevation:elevation] ?: self.backgroundColor;
```
Instead of just doing:
```
self.backgroundColor = [self.backgroundColor resolvedColorForTraitCollection:self.traitCollection elevation:elevation];
```
Lastly, I don't believe it makes sense to make the method an iOS13 API only as in fact UITraitCollections exist since iOS8, and is legitimate to pass it to the function even though userInterfaceStyle is not there yet.
Closes: #8216
In the UIColor+MaterialElevation category the formula to convert elevation to alpha has a jump for elevations that are 0 to anything bigger than 0.
This means that elevation 0 returns an alpha that is 0, but any elevation that is above 0, even 0.000000001 will return an alpha of 2 or bigger. This causes 2 problems:
Some of our components return elevations that are very close to 0, like 0.0000000000005 (AppBar in particular). If we don't fix this, it will cause constant flickering of the background color of the AppBar as it transitions between 0 and something closer to 0.
There is a big jump when component elevations between 0 and anything larger than 0 occurs which makes it seem like a jump and not smooth to the observer.
The change provide a smooth function that occurs between values of 0 and 1. This formula has been thought out in collaboration with design.
Closes: #8213
As clients will initialize their material components and want to provide a background color that fits the component's elevation, they will need to get its absolute elevation value. Therefore, currently they need to add mdc_currentElevation + mdc_baseElevation themselves to get that.
In this PR I am adding an mdc_absoluteElevation getter where clients can get that and not have to do unneeded calculation in their code. Furthermore, because elevationDidChangeBlock effectively returns the absolute elevation, it would be easier for clients to understand that concept by also providing an absoluteElevation property.
Added easier to understand description of what exactly the elevationDidChangeBlock elevation param it provides.
Similarly to `traitCollectionDidChangeBlock`, we want to pass `self` here in cases where the object is being injected, and also to remove the need from clients to weakify self and possibly cause retain cycles.
When our components conform to this block, they should be more type specific to what self is. As an example in the MDCCard header, I would expect conforming to this block would be declared like:
```
@property(nonatomic, copy, nullable) void (^mdc_elevationDidChangeBlock)
(MDCCard * elevatableSelf, CGFloat elevation);
```
Adds a category to UIView to get a mdc_baseElevation for a given view. This new property will allow views to know the elevation of everything below them.
Related to #7964
This change adds a method to UIView elevationDidChange to inform all UIViews and their subviews that one of their _superview_s changed elevation and they may need to be re-themed.
Closes#8005
Similarly to `traitCollectionDidChangeBlock`, we want to pass `self` here in cases where the object is being injected, and also to remove the need from clients to weakify self and possibly cause retain cycles.
When our components conform to this block, they should be more type specific to what self is. As an example in the MDCCard header, I would expect conforming to this block would be declared like:
```
@property(nonatomic, copy, nullable) void (^mdc_elevationDidChangeBlock)
(MDCCard * elevatableSelf, CGFloat elevation);
```
Adds a category to UIView to get a mdc_baseElevation for a given view. This new property will allow views to know the elevation of everything below them.
Related to #7964
Add an optional property for clients to override their elevation if they are using a UIPresentationController or another object that may not be in the view hierarchy but in the UIWindow.
Part of #7964
This change adds a protocol `MDCElevation` for clients to conform to so that their is a consistent API for getting a `UIView` elevation. This is in it's own folder because it can be used as a standalone protocol and is agnostic of ShadowElevations and schemes/Color.
For additional context please see go/material-dark-mode-elevation-support
Closes#7961
