This example demonstrates a bug where the safe area layout guide does not appear to be working as expected (i.e. the content does not pin to the bottom of the FlexibleHeader).
PiperOrigin-RevId: 310220555
This new shift behavior mode enables the flexible header to mimic the behavior of UINavigationController's setNavigationBarHidden:. When the shift behavior is set to this new value, the flexible header can be hidden or shown using the shiftHeaderOnScreenAnimated: and shiftHeaderOffScreenAnimated: APIs, but user interactions will not affect the header's visibility.
Added an example to the configurator to demonstrate the behavior.
Part of https://github.com/material-components/material-components-ios/issues/5185
Closes https://github.com/material-components/material-components-ios/issues/5813
Problem:
Prior to this change, the shift phase values were nonsensical when a flexible header was a child of its tracking scroll view.
Root cause:
The scroll phase value logic was looking at self.frame, which is undefined if self.transform is not the identity. When a flexible header is a child of its tracking scroll view, we modify self.transform in order to keep it "pinned" to the top of the screen. This resulted in unpredictable values for self.frame in the phase calculation logic.
The fix:
Rather than rely on self.frame, we now inspect self.center which is unaffected by self.transform. We calculate what the "top edge" of the flexible header is and feed that value in to the phase calculation logic.
Tested:
Added new log statements to the flexible header configurator demo. Verified that the values output matched the documented behavior of the scroll phase properties.
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.
```
We can now make use of @available throughout our codebase.
We support Xcode 9 and up, which includes the iOS 11 SDK. This means we can remove any guards for SDKs prior to iOS 11.
This was cleaned up by running a global find-and-replace with the following regular expression:
```
Find:#if defined\(__IPHONE_11_0\) && \(__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_11_0\)\n(.+if \(@available\(iOS 11.0, \*\)\) \{(?:.|\n)*?)(?:#else(?:.|\n)*?)?\n#endif
Replace:$1
```
With some additional cleanup for stragglers that didn't match this pattern. Note that else clauses were intentionally dropped.
Closes https://github.com/material-components/material-components-ios/issues/4909
### Release notes
`canAlwaysExpandToMaximumHeight` is a new behavior on the Flexible Header component that is available through an extension target, `FlexibleHeader+CanAlwaysExpandToMaximumHeight`.
Enabling this behavior on a flexible header instance will allow the flexible header to expand to its maximum height even when the flexible header is floating in front of its content.
---
We intend to keep usage of this API fairly restricted internally, so we have added the behavior as a separate target that we'll whitelist internally to clients. The API is still supported by the typical API contract for public clients.
The behavior is implemented using the same shift accumulator logic that enables header shifting. When the accumulator is positive, we're shifting off-screen. When the accumulator is negative, we're expanding the height of the flexible header.
Closes https://github.com/material-components/material-components-ios/issues/4393
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 example is implemented as a subclass of the Objective-C example, which creates all manner of bugs due to the fact that it duplicates most of the initialization logic.
Removing this example because it's not providing significant value and will require being completely rewritten as not a subclass of the Objective-C example.
This change only affects flexible headers that are being used in a horizontally-paging setting.
Repro steps:
- Open MDCDragons.
- Open the Flexible Header horizontal paging example.
- Scroll the first page down until the header is collapsed.
- Swipe to the next page.
Prior to this changew, the flexible header's height would increase after moving to the new page.
After this change, the flexible header's height will stay collapsed after moving to the new page.
Related to https://github.com/material-components/material-components-ios/issues/3130
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
* [FlexibleHeader] Always update opacity for views that hide when shifted.
Before this change, views that hide when shifted would only change their visibility if shifting was enabled. This resulted in a bug where if shifting was disabled then views would not become visible again once the header shifted back on screen.
After this change, views that hide when shifted will always change their visibility when the header's frame changes.
* Simplify the logic.
* ORder.
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
ButtonBar, FlexibleHeader, HeaderStackView, and NavigationBar are all implementation details of AppBar. While these components can be used on their own, in practice we expect most typical usage to rely on AppBar. FlexibleHeader is a bit blurry in that there is often value in relying on it solely, but because it is not a true concept in the spec and its behavioral demos largely overlap with AppBar's, it is now a dragons demo.
Pivotal story: https://www.pivotaltracker.com/story/show/156982162
Currently this example, when configured such that:
Basic Behavior
Can over-extend - ON
In front of infinite content - OFF
Hide status bar - OFF
Shift Behavior
Enabled - ON
Enabled with status bar - OFF
Header content is important - OFF
the header text overlaps the status bar. This change ensures the minimum height is always great enough to prevent that.
* 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
If UIKit insets the horizontal paging scroll view then it will allow vertical scrolling on the horizontal view, which is not desired because vertical scrolling is meant to be managed by each scrollview page.
* [FlexibleHeader] Fixes to support scroll views with Safe Area insets.
* Fix typo
* [FlexibleHeader] Update header height when safe area changes.
* [FlexibleHeader] Only adjust sizes and margins on iOS11+.
* [FlexibleHeader] Bring back hardocded status bar const.
* [Catalog] Fix unintended hidden status bar when in landscape.
* Code reviews
* [Podspec] Add MaterialApplication as a dependency on MDCAppBar
* [FlexibleHeader] Make Xcode 8 stop complaining about unused parameter.
* [FlexibleHeader] Fix typo.
* [UnitTest] Remove hardcoded status bar height.
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
* [TextFields] Linting
* [Catalog] Swift style.
* [Catalog] Swift style.
* [Buttons] Swift style.
* [FlexibleHeader] Swift style.
* [NavBar] Swift style.
* [Snackbar] Swift style.
* [Tabs] Swift style.
