Replacing all non-integral, single-precision floating point literals with double-precision values explicitly cast to CGFloat. For example, `0.1f` should become `(CGFloat)0.1`.
Regex used:
```
([0-9]*\.)([0-9]*?)([1-9]+)([0-9]*?)[fF]
```
PiperOrigin-RevId: 220683126
Removes the need to copy-paste stanzas from other files anymore as we'll rely on #4478 to generate the correct stanza for us instead.
This was an automated change generated by running a find-and-replace regular expression:
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
// Copyright $1-present the Material Components for iOS authors. All Rights Reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
```
This is the first part of a two-part change that addresses the behavior outlined in https://github.com/material-components/material-components-ios/issues/4104. The second part will expose a similar behavior in the AppBar component.
---
This PR introduces a new top safe area inset behavior to the flexible header view, gated behind the runtime flag `inferTopSafeAreaInsetFromViewController`.
When this behavior is enabled, the flexible header will no longer attempt to infer the top safe area inset from the device's insets using `MDCDeviceTopSafeAreaInset`. Instead, it will infer the top safe area inset from the view controller ancestry of the flexible header view controller.
This new behavior addresses a number of issues related to safe area insets, namely:
- https://github.com/material-components/material-components-ios/issues/4104 (incorrect insets when shown in a popover or modal dialog on iPad).
- Flexible headers can now be used in app extensions.
- The flexible header now properly reacts to status bar visibility changes.
### New feature: top safe area guide
This change introduces a new layout guide that can be used to position content within the flexible header view while respecting the top safe area insets. The `topSafeAreaGuide` API is available on the MDCHeaderView instance of the flexible header view controller and supports iOS 8 and up. An example of its usage to align a view to the bottom of the flexible header's top safe area guide:
```
[NSLayoutConstraint constraintWithItem:self.titleLabel
attribute:NSLayoutAttributeTop
relatedBy:NSLayoutRelationEqual
toItem:self.fhvc.headerView.topSafeAreaGuide
attribute:NSLayoutAttributeBottom
multiplier:1.0
constant:0]
```
The new layout guide works whether `inferTopSafeAreaInsetFromViewController` is enabled or disabled.
### Additional information
If using `MDCFlexibleHeaderContainerViewController`, this new behavior is now enabled by default.
The new behavior (and all of the other "new" behaviors) have been enabled on every FlexibleHeader example.
### Results
A screenshot of the result of this API once enabled on the App Bar:
### Architecture
This change builds off of the foundation introduced in 80fd217f766e0f5be6a3bc6bef5923f231721f9d. As part of that change, we made it possible to modify a given view controller's top layout guide such that it equalled the top safe area insets + the flexible header height. Unfortunately, that change was still limited by the fact that the flexible header always assumed that it was placed as a full-screen view.
With the new `inferTopSafeAreaInsetFromViewController` behavior, we are able to extract the top safe area inset from our view controller ancestry instead. We can then combine this extracted value with our flexible header's height before ultimately writing that to the target top layout guide. This flow is roughly shown in the following diagram:
In order to implement this flow we needed to implement two things:
1. A mechanism by which we could infer the root-most ancestral view controller from which we could extract safe area insets.
2. A mechanism by which we could be notified every time that root view controller's safe area insets changed.
The first mechanism is implemented by `fhv_inferTopSafeAreaSourceViewController` as a simple ancestral traversal. We walk up the view controller tree from the flexible header's parent until we run out of ancestors. There is some nuance to this algorithm, in that we need to ensure that our ancestor isn't our `topLayoutGuideViewController` or we risk creating an infinite loop. If we encounter such a situation we attempt to break the loop by walking up the topLayoutGuideViewController's ancestry instead, but at this point it's very likely we won't have a viable ancestor and we'll throw an assertion if/when we can't find a viable ancester.
With an ancestor in hand, we then determine whether to KVO observe `topLayoutGuide` or `safeAreaInsets` based on whether we're running pre-iOS 11 or iOS 11+, respectively.
KVO then informs us of any changes to the top safe area insets, which we can then propagate through the flexible header view and eventually on to the top layout guide (if `topLayoutGuideAdjustmentEnabled` is also enabled).
This PR is a rolled-forward version of https://github.com/material-components/material-components-ios/pull/3754. The original PR had to be rolled back while we were cutting v55.1.0 due to the fact that it introduced behavioral changes that would have negatively affected clients.
This roll-forward maintains the entirety of the existing flexible header behavior unless `.topLayoutGuideAdjustmentEnabled = true`.
The primary change between this PR and the previous PR is that all new behavior is now gated by the `topLayoutGuideAdjustmentEnabled` property.
---
# Original PR description
This change introduces more predictable behavior surrounding topLayoutGuide and additionalSafeAreaInsets when using a flexible header (fhvc) container view controller (vc).
The purpose of this change is to support flexible header container view controllers with no-tracking-scroll-view based content.
## Background
Prior to this change, the fhvc was not adjusting the topLayoutGuide of the content vc when using a MDCFlexibleHeaderContainerViewController. The container vc was also not setting the bounds and autoresizing mask of the content view controller, leading to an oddly positioned content vc with no awareness of its occluding header. Many of our catalog examples are implemented with incorrect layout because of this, and I've seen a few examples of client usage that's attempting to work around this behavior.
The content vc's top layout guide is not being adjusted was because the flexible header view was always assuming that its parent vc was the vc whose topLayoutGuide should be updated. This is not the case when using a container vc - the flexible header vc is a sibling to the content vc, with the parent being the container view controller.
## Possible solutions
There were two paths to fixing this that I could see:
1. Make the fhvc a child of the content view controller. This would require zero changes to the fhvc, but may introduce behavioral changes to clients. This would require introducing a somewhat tricky behavioral flag (on change, we'd have to reparent the fhvc).
2. Allow the fhvc to keep updating the container vc's top layout guide, and constrain the container vc's top layout guide to the content vc's top layout guide.
2. Make it possible for the fhvc to target a specific view controller's top layout guide. This will also be a behavioral change, but a somewhat easier one to gate.
In any path, we need to also set the content vc's frame to match the container vc's bounds and set an autoresizing mask accordingly.
This PR represents option 3 because it represents the cleanest, most explicit mechanism for updating the correct top layout guide. We don't care if the container's top layout guide gets updated (option 2), and changing the fhvc hierarchy for containers is a fairly involved task that I feel could be tackled separately.
## This change
After this change, clients can enable a new flag on the container view controller to enable the desired topLayoutGuide behavior.
For example:
```swift
container.topLayoutGuideAdjustmentEnabled = true
```
This will ensure that the topLayoutGuide and additionalSafeAreaInsets of the content view controller are modified when the flexible header's height changes.
This runtime flag introduces new behavior and is off by default to avoid creating a breaking change. We will eventually enable this flag by default once all internal clients have migrated to the new behavior. The breaking behavior is primarily due to the fact that we are now properly setting the content view controller’s frame and autoresizing mask, which can affect client layouts.
This change is the first in a series of changes that will allow us to better support scroll view-less view controllers that otherwise have no way to position their content below the flexible header. Scroll view-less controllers are most commonly wrapped in a container view controller.
## Upcoming deprecations
This change marks `updateTopLayoutGuide` on MDCFlexibleHeaderViewController as to-be-deprecated because it exposes an implementation detail.
## Follow-up work
I will add this same flag and behavior to AppBar's container vc.
I will then enable this behavior in the MDCCatalog on a case-by-case basis so that we can fix layouts by using the top layout guide and/or safe area insets.
---
Closes: https://github.com/material-components/material-components-ios/issues/2471
Closes https://github.com/material-components/material-components-ios/issues/4192
This change introduces more predictable behavior surrounding topLayoutGuide and additionalSafeAreaInsets when using a flexible header (fhvc) container view controller (vc).
The purpose of this change is to support flexible header container view controllers with no-tracking-scroll-view based content.
## Background
Prior to this change, the fhvc was not adjusting the topLayoutGuide of the content vc when using a MDCFlexibleHeaderContainerViewController. The container vc was also not setting the bounds and autoresizing mask of the content view controller, leading to an oddly positioned content vc with no awareness of its occluding header. Many of our catalog examples are implemented with incorrect layout because of this, and I've seen a few examples of client usage that's attempting to work around this behavior.
The content vc's top layout guide is not being adjusted was because the flexible header view was always assuming that its parent vc was the vc whose topLayoutGuide should be updated. This is not the case when using a container vc - the flexible header vc is a sibling to the content vc, with the parent being the container view controller.
## Possible solutions
There were two paths to fixing this that I could see:
1. Make the fhvc a child of the content view controller. This would require zero changes to the fhvc, but may introduce behavioral changes to clients. This would require introducing a somewhat tricky behavioral flag (on change, we'd have to reparent the fhvc).
2. Allow the fhvc to keep updating the container vc's top layout guide, and constrain the container vc's top layout guide to the content vc's top layout guide.
2. Make it possible for the fhvc to target a specific view controller's top layout guide. This will also be a behavioral change, but a somewhat easier one to gate.
In any path, we need to also set the content vc's frame to match the container vc's bounds and set an autoresizing mask accordingly.
This PR represents option 3 because it represents the cleanest, most explicit mechanism for updating the correct top layout guide. We don't care if the container's top layout guide gets updated (option 2), and changing the fhvc hierarchy for containers is a fairly involved task that I feel could be tackled separately.
## This change
After this change, clients can enable a new flag on the container view controller to enable the desired topLayoutGuide behavior.
For example:
```swift
container.topLayoutGuideAdjustmentEnabled = true
```
This will ensure that the topLayoutGuide and additionalSafeAreaInsets of the content view controller are modified when the flexible header's height changes.
This runtime flag introduces new behavior and is off by default to avoid creating a breaking change. We will eventually enable this flag by default once all internal clients have migrated to the new behavior. The breaking behavior is primarily due to the fact that we are now properly setting the content view controller’s frame and autoresizing mask, which can affect client layouts.
This change is the first in a series of changes that will allow us to better support scroll view-less view controllers that otherwise have no way to position their content below the flexible header. Scroll view-less controllers are most commonly wrapped in a container view controller.
## Upcoming deprecations
This change marks `updateTopLayoutGuide` on MDCFlexibleHeaderViewController as to-be-deprecated because it exposes an implementation detail.
## Follow-up work
I will add this same flag and behavior to AppBar's container vc.
I will then enable this behavior in the MDCCatalog on a case-by-case basis so that we can fix layouts by using the top layout guide and/or safe area insets.
---
Closes: https://github.com/material-components/material-components-ios/issues/2471
* Added warnings to examples.
* fixed some warnings
* using button sender parameter.
* use button sender in example
* use button sender in example
* removed sender from methods that don’t use it.
* removed sender from methods that don’t use it.
* use button sender in example
* use button sender in example
* use button sender in example
* use button sender in example
* Fixed init of header configurator to use passed in parameter
* removed unused API
* use button sender in example
* Revert "Added warnings to examples."
This reverts commit 91f0480f86cb609c47b00f1346f82de67c31c4e9.
* fixed example: Using the view controllers navigationItem rather than creating a new one.
* removed finished checks from animation blocks in examples.
* reverted id sender checks
* revert id sender check for Flexible header UINavigationBar
* revert clug
* revert clug
* addressing nits
* removed sender check for FeatureHighlightTypicalUseView
* more nits
All examples now have at least the required `+catalogBreadcrumbs` and `+catalogIsPrimaryDemo`. All examples in the same breadcrumbs path have only one primary demo. There should be only one `-catalogDescription` attached to the primary demo.
Closes#1897
* Replace MDC all icons
* Update border
* Replace MDCActionExtension icon with new logo
* Update all headers to be white on black
* Make Catalog greyscale to match Material’s style.
* Fix collection tile
* Update all headers to be white on black
* Make Catalog greyscale to match Material’s style.
* Fix collection tile
* WIP: Updating TabBar example to use black/green theme.
* WIP: Monochoroming all examples.
* Switch MDC Catalog to a black and white theme (#1355)
* Replace MDC all icons
* Update border
* Replace MDCActionExtension icon with new logo
* Update all headers to be white on black
* Make Catalog greyscale to match Material’s style.
* Fix collection tile
* Update all headers to be white on black
* Make Catalog greyscale to match Material’s style.
* Fix collection tile
* Fix floats
* Make Catalog greyscale to match Material’s style.
* More black and whiting
* WIP: Snackbar and global style
* Simplify snack bar examples.
* Page control
* MDC_#870 - Base implementation
* MDC_#870 - Moved references out from delegate to flexibleViewController to prevent inadvertent manipulation. Added comments
* MDC_#870 - Update container view controllers utilizing flexible header
* MDC_#870 - Added example use for topLayoutGuide, updated README
* MDC_#870 - Added Unit Tests
* MDC_#870 - Updated test class name, spacing on MDCFlexibleHeaderVC
* MDC_#870 - Code Styling
