### Context
When the migration from MDCAppBar to MDCAppBarViewController occurred, a small piece of code was left out, specifically in `addSubviewsToParent`.
### The problem
When running the catalog app in split screen on iPad and viewing the examples for MDCAppBarViewController, the App Bar is not sized correctly and overflows outside of the bounds.
### The fix
Re-add the frame width modifying logic from `addSubviewsToParent` into `didMoveToParentViewController:parent` for MDCAppBarViewController.
### Related bugs
closes#5479, b/118126496
### Screenshots
| Before | After |
| - | - |
|||
I did an audit of the Catalog app to track down screens with an incorrect status bar color and the ones that I found are:
* AppBar -> Presented (This example does not use the app theme so I was able to set the style directly)
* AppBar -> Wrapped
* BottomAppBar
Additionally, I found that changing the Catalog theme from black to another color (and vice-versa) resulted in the status bar being incorrect until the next page navigation. So I created a fix for this too.
Closes#3778
Setting the view's frame is an important part of migrating from MDCAppBar to MDCAppBarViewController. Failure to do so can result in the app bar's width not matching the parent view's width.
This example was provided by @babakbo in https://github.com/material-components/material-components-ios/issues/5156
The purpose of this example is to be able to test the behavior of multiple tabs that are added and removed from the view controller hierarchy as the selected tab changes. This is different from the typical tabs usage, which relies on a horizontally-paging scroll view to allow the tabs to be switched between.
In addition, this example is demonstrating the use of the canAlwaysExpandToMaximumHeight API which has been provided specifically for @babako and team.
## Screenshots
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.
```
Removes the need to copy-paste stanzas from other files anymore as we'll rely on https://github.com/material-components/material-components-ios/pull/4478 to generate the correct stanza for us instead.
This was an automated change generated by running a find-and-replace regular expression:
### Find
```
/\*
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\.
\*/
```
### Replace
```
// 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
Repro case:
- Open MDCDragons.
- Open the App Bar -> WKWebView small content bug
Expected behavior: the web view does not allow the content to be scrolled up and down.
Actual behavior: the web view's scroll view's content size height appears to have extra padding, allowing the content to be scrolled.
---
This change introduces a runtime check for WKWebView. If the tracking scroll view is a scroll view of a WKWebView, we disable the content inset adjustment behavior in favor of using additionalSafeAreaInsets on iOS 11 and up. On older iOS devices, clients must instead rely on the topLayoutGuide and position their web view below the header accordingly. This is demonstrated in the two added examples.
This bug stems from the fact that UIKit's implementations of its various UIScrollView subclasses each have individual quirks. UITableView reacts differently to additionalSafeAreaInsets than WKWebView's scroll view, and a pure UIScrollView reacts differently from either of them. The most notable difference in behavior is how and when the contentOffset is adjusted in reaction to changes in the additionalSafeAreaInsets.
My original attempt at this fix included a public behavioral flag that would allow clients to opt in to using additionalSafeAreaInsets for any tracking scroll view, but the various quirks of UITableView and friends was expanding the scope of the fix too much. I would like to move the Flexible Header towards relying solely on additionalSafeAreaInsets in the future, but for now it is out of scope of this particular bug fix. As such, I've introduced a more focused behavioral flag that only enables itself if the tracking scroll view is a WKWebView's scroll view.
Closes https://github.com/material-components/material-components-ios/issues/4377
set cell selection style to none in following examples:
Activity Indicator Demo
App Bar Demo
AppBarSectionHeaderExample
AppBarImageryExample
closes#3870
This change further formalizes our pattern of annotating APIs that will be or are deprecated using class categories. Moving an API into such a category has the benefit of being picked up by the API diff toolchain and elevated into our release notes as a result.
2645cc539f6a17e8ecb729a1b5b7997be24f07fa changed the app bar initialization such that it would no longer touch self.view during initialization. This means that viewDidLoad now only gets called when the client adds the app bar view controller's view to the view hierarchy.
A client was depending on the header stack view's `topBar` property being set to the navigation bar immediately after initialization, so the above change broke this contract for them.
This change moves this logic into the app bar view controller's initialization phase so that the header stack view is fully configured upon initialization, renewing the contract that the client team expected.
Added a unit test to ensure that we maintain this contract into the future.
This logic was moved to the app bar view controller's viewDidLoad as part of 2645cc539f6a17e8ecb729a1b5b7997be24f07fa. However, this affected some downstream clients that were depending on the shadow layer already being initialized immediately after initializing the app bar.
This change essentially reverts the moved behavior by moving the initialization to the app bar view controller's init- methods.
Prior to this change, view controllers that were provided to an MDCAppBarNavigationController via the setViewControllers:animated: API would not have an app bar injected.
After this change, MDCAppBarNavigationController will properly inject an app bar into the set view controllers, as expected.
Closes https://github.com/material-components/material-components-ios/issues/4735
This is in preparation for the eventual deprecation of MDCAppBar in favor of MDCAppBarViewController.
We have to leave the old header behind because client teams are still directly importing our component headers :(
This change introduces the following changes:
- MDCAppBarViewController is a new public API.
- MDCAppBarViewController is now a subclass of MDCFlexibleHeaderViewController.
- MDCAppBar and friends are marked as to be deprecated.
- MDCAppBar is now a simple shell for MDCAppBarViewController and it forwards all messages to the view controller accordingly.
- MDCAppBarNavigationController exposes new APIs related to the app bar view controller. The old MDCAppBar APIs have been marked as "to be deprecated".
- Themers all have new APIs for the new view controller. The App Bar-specific APIs have been marked as "to be deprecated".
- All internal implementation details make use of the view controller where possible instead of an app bar.
- The app bar view controller is now a flexible header view controller, rather than a child of it. If any clients were depending on the private previous behavior for any reason then this change will break them.
There is a follow-up change to this that will update the catalog to the new APIs. I have split that out to a separate change due to its size.
This API change will ease client integrations, giving them a clearer conceptual understanding of "App Bar as a sub-type of Flexible Header", vs the previous "model" pattern which bound the App Bar's views to a flexible header view controller instance.
## Typical client migration
```swift
// Step 1
- let appBar = MDCAppBar()
+ let appBarViewController = MDCAppBarViewController()
// Step 2
- self.addChildViewController(appBar.headerViewController)
+ self.addChildViewController(appBarViewController)
// Step 3
- appBar.addSubviewsToParent()
+ view.addSubview(appBarViewController.view)
+ appBarViewController.didMove(toParentViewController: self)
```
This includes two changes that increase the likelihood of us detecting existing App Bars in a pushed view controller:
1. Some clients manage view controllers in viewDidLoad. We're already accessing .view in the injection logic, but we were not doing so until after the check for an App Bar. We now fetch the view before we check the view controller hierarchy, giving the pushed view controller an opportunity to configure itself before we check for an existing App Bar.
2. There are cases within our own catalog where we have a "nested dolls" of view controllers, i.e. an App Bar in a container inside another view controller. We were not recursing our pre-existing flexible header view controller check, meaning we would miss these deeply-nested view controller cases. This change adds a recursive step to the view controller check.
I verified that the added test fails prior to this change and succeeds after this change.
## Screenshots
Before:
After:
Repro case for the incorrect behavior:
- Open MDCCatalog in portrait on any iPhone.
- Open the Tabs component.
- Rotate to landscape.
Expected behavior: the App Bar's navigation bar collapses with the app bar's content.
Actual behavior: the App Bar's navigation bar still thinks that there is a status bar.
---
Prior to this change we were only enabling inferTopSafeAreaInsetFromViewController on the flexible header. This meant that the App Bar's layout constraints were not being updated with respect to the contextual top safe area insets.
After this change, we enable inferTopSafeAreaInsetFromViewController on the App Bar as well.
This bug only affects clients of the app bar navigation controller.
This new API provides a dead-simple integration path for adding an App Bar to an app. I expect this API to be the dominant way for clients to integrate with the App Bar component.
The existing mechanisms of creating an App Bar (injection and wrapping with a container) are still feasible, and both methods can be used interchangeably with the navigation controller. If the navigation controller detects that a flexible header is already present in a pushed view controller it will not add an App Bar.
As part of this change I also explored simply providing a UINavigationControllerDelegate that responded to the willShow event. This approach had the following limitations:
- I did not see a clear path to properly supporting status bar styles. Properly supporting status bar styles requires that somebody, at some point in the hierarchy, is able to route status bar style queries to the flexible header view controller. A delegate lacks this facility.
- The willShow event is fired after the viewWillAppear: event fires, meaning we had to simulate the invocation of this on the injected view controllers. This required that we recursively traverse the App Bar's flexible header view controller and its children (in order to also notify the app bar's internal view controller of the viewWillAppear event). I was concerned that the requirement for this patch would lead to unexpected behavior down the road.
As a result of encountering the above limitations, I pivoted to providing a concrete UINavigationController subclass. I have been hesitant to provide this class for some time because of a very colorful history of supporting similar APIs over the last half decade. At this point, however, I feel that the number of behavioral APIs we've landed allow us to implement the navigation controller with minimal logic, keeping the implementation as simple as possible.
Notably, users of the new app bar navigation controller API will benefit from all injected App Bars having all of the most "modern" APIs enabled because this is a new API. This means that the scroll view's content offset is observed, it respects safe area insets based on the context, and the content view controller's top layout guide / safe area insets accurately reflect the space consumed by the flexible header.
Example usage:
```swift
let navigationController = MDCAppBarNavigationController()
navigationController.pushViewController(viewController, animated: true)
```
If you want to be able to theme the injected App Bar then you'll need to implement the navigation controller's delegate and respond to the willAdd events, like so:
```swift
// MARK: MDCAppBarNavigationControllerInjectorDelegate
func appBarNavigationController(_ navigationController: MDCAppBarNavigationController,
willAdd appBar: MDCAppBar,
asChildOf viewController: UIViewController) {
MDCAppBarColorThemer.applySemanticColorScheme(AppTheme.globalTheme.colorScheme, to: appBar)
MDCAppBarTypographyThemer.applyTypographyScheme(AppTheme.globalTheme.typographyScheme,
to: appBar)
}
```
Closes https://github.com/material-components/material-components-ios/issues/268
This behavior enables the similarly-named behavior added to the Flexible Header in bb245597d8895a78c346c76f7d0986d7a993ad12. In addition to allowing the flexible header's min/max height to use the contextual safe area insets, the App Bar will use the flexible header view's top safe area guide to position its header view (rather than using MDCDeviceSafeAreaInsets(), which we want to remove).
This change enables the new behavior in the App Bar examples and in the MDCCatalog node list view controller.
Closes https://github.com/material-components/material-components-ios/issues/4104
This new opt-in behavior allows a client to more easily integrate the Flexible Header (and relatedly, the App Bar) when they do not require shifting behavior (which is most of the time).
The new behavior can be enabled by setting `observesTrackingScrollViewScrollEvents` to true on the flexible header view instance.
When this property is enabled, the flexible header will no longer allow tracking scroll view events to be manually forwarded, and it will also enforce the shift behavior being set to a disabled state. The intent of this enforcement is to encourage unambiguous usage of the flexible header (you're either allowing it to observe events, or you're forwarding events, but not both).
I've rolled this new behavior out to all of the App Bar examples to demonstrate how much code it removes. I expect this to be a large win for client teams that are integrating with the App Bar.
The underlying implementation of this new behavior relies on KVO of the scroll view's contentOffset property. We manage registration of KVO events through the fhv_startObservingContentOffset and fhv_stopObservingContentOffset APIs.
Prior to iOS 11, the KVO implementation of observers required that you deregister any observers from an object before it is deallocated. As such, if a client wishes to use this behavior and they also support iOS 10.* or below, they must also explicitly nil out the tracking scroll view before it is deallocated. This is required because we keep a weak reference to the tracking scroll view (for a variety of important reasons, namely: avoiding retain cycles and ensuring we don't keep the tracking scroll view alive longer than its owning controller). Because of the weak reference, we can't rely on our own dealloc method being invoked before the tracking scroll view is deallocated. As such, only the client who provided us with a tracking scroll view is capable of making an informed decision as to when to nil out the tracking scroll view. In essence, this behavior comes with a KVO contract (a cost) while providing a much easier integration experience (the benefit).
If a client supports iOS 11 and up, they can simply enable this behavior with no additional code.
Closes https://github.com/material-components/material-components-ios/issues/347
This enables the new FlexibleHeader/AppBar behavior that correctly updates the content view controller's safe area insets/top layout guide to match the flexible header's height and sets the frame of the content view controller to match the bounds of the container view controller.
As part of this change, we were able to remove the Catalog logic that would manually adjust the frame of examples that did not have a scroll view. Examples are now expected to adjust their content according to the top layout guide / safe area insets, as can be seen in the ButtonsTypicalUse example.
Examples that *do* have a scroll view will also now make use of the correct top layout guide / safe area insets behavior. This behavioral change can most notably be seen in the ActivityIndicator example, which no longer has a 20 point "dead zone" above the table view.
