We will be dropping all runtime support for AppBar at the start of 2022q3, with intent to delete the component entirely one year later.
PiperOrigin-RevId: 390353332
As I've gone through and replaced all the READMEs I haven't always been good at deleting the markdown files that were stitched together to make the old READMEs. This PR removes all the ones I forgot to remove. All the relevant material in these files is already in the new READMEs, so we're not losing anything by doing this.
Closes https://github.com/material-components/material-components-ios/pull/10029
COPYBARA_INTEGRATE_REVIEW=https://github.com/material-components/material-components-ios/pull/10029 from andrewoverton:delete-unused-docs 65ea55253af300ea7a4c13ea4ce14976097a6253
PiperOrigin-RevId: 318079032
Before this change, it was never possible to interact with the navigationController property in a pushed view controller's viewDidLoad property when using MDCAppBarNavigationController. This behavior is surprising for folks using UINavigationController, which does allow you to access navigationController from within viewDidLoad.
This expectation is an anti-pattern (e.g. viewDidLoad is never guaranteed to be invoked after a view controller has been pushed onto a navigationController stack), but the goal of MDCAppBarNavigationController is to provide a drop-in replacement for UINavigationController so our intent is to align behaviors, even if they're not necessarily for the right reasons.
All that being said, the change introduced in this CL simply swaps the ordering of pushing the view controller and injecting the AppBar, such that the injection now happens after the super implementation of pushViewController has been invoked. This allows the viewDidLoad logic to be invoked after navigationController has been initialized on the view controller.
The reason we were doing it the other way before was so that the AppBar could intercept the relevant status bar appearance events. We work around that requirement in this change by invoking setNeedsStatusBarAppearanceUpdate and setNeedsUpdateOfHomeIndicatorAutoHidden immediately after injecting the AppBar.
PiperOrigin-RevId: 313410464
Before this change, it was never possible to interact with the navigationController property in a pushed view controller's viewDidLoad property when using MDCAppBarNavigationController. This behavior is surprising for folks using UINavigationController, which does allow you to access navigationController from within viewDidLoad.
This expectation is an anti-pattern (e.g. viewDidLoad is never guaranteed to be invoked after a view controller has been pushed onto a navigationController stack), but the goal of MDCAppBarNavigationController is to provide a drop-in replacement for UINavigationController so our intent is to align behaviors, even if they're not necessarily for the right reasons.
All that being said, the change introduced in this CL simply swaps the ordering of pushing the view controller and injecting the AppBar, such that the injection now happens after the super implementation of pushViewController has been invoked. This allows the viewDidLoad logic to be invoked after navigationController has been initialized on the view controller.
The reason we were doing it the other way before was so that the AppBar could intercept the relevant status bar appearance events. We work around that requirement in this change by invoking setNeedsStatusBarAppearanceUpdate and setNeedsUpdateOfHomeIndicatorAutoHidden immediately after injecting the AppBar.
PiperOrigin-RevId: 311342757
## The bug
Repro steps:
1. Open MDCDragons on an iPhone with a notch.
2. Open App Bar -> Presented hidden.
3. Present the App Bar.
4. Observe.
Expected behavior:
- The AppBar is completely hidden.
Actual behavior:
- The AppBar is partially hidden.
## Root cause analysis
When the FlexibleHeader is hidden using shiftHeaderOffScreenAnimated:, the expectation is that the header will be shifted entirely off-screen. If this method is invoked before the FlexibleHeader is attached to a window hierarchy, then the offset applied to shift the header off-screen may not correctly include the necessary safe area insets to hide the header fully.
When flexibleHeaderSafeAreaTopSafeAreaInsetDidChange was being invoked after the safe area insets were made available to the FlexibleHeader, we were not taking into consideration whether the FlexibleHeader was supposed to be hidden which resulted in the FlexibleHeader getting stuck in a partially hidden state.
## The fix
In flexibleHeaderSafeAreaTopSafeAreaInsetDidChange, we now check whether the FlexibleHeader wants to be hidden and, if it does (and we're not already animating it), we immediately snap the FlexibleHeader to the new necessary offset.
PiperOrigin-RevId: 311104051
The example was reusing the same view controller instance after each presentation, which made it difficult to consistently test the same buggy behavior.
PiperOrigin-RevId: 310980123
This example demonstrates a bug where the AppBar does not appear to respect shiftHeaderOffScreenAnimated: when the shiftBehavior is set to hideable.
PiperOrigin-RevId: 310898136
This example doesn't actually manage its own app bar; it only presents one. This fixes a bug where the example did not show a navigation bar at all.
PiperOrigin-RevId: 310870101
The prior names of composed vs inherited didn't meaningfully translate to the intended purpose of the two view controllers, which is to provide harnesses within which the flexible header can be placed either as a child or as a sibling to its tracking scroll view. This distinction is important because the flexible header behaves differently when it is a child of its tracking scroll view, as is the case when using UITableViewController.
PiperOrigin-RevId: 310869953
