This adds a dismissOnAccessibilityPerformEscape bit that allows clients to control whether the bottom drawer should dismiss or not on Z swipe. This is useful for when clients have an extra step before dismissal (e.g. confirmation on dismiss).
PiperOrigin-RevId: 331594189
This adds a new property to MDCBottomDrawerViewController and MDCBottomDrawerContainerViewController that allows for non-fullscreen mobile landscape bottom drawer view.
PiperOrigin-RevId: 327626953
This adds a new property to MDCBottomDrawerViewController that allows for non-fullscreen mobile landscape bottom drawer view.
PiperOrigin-RevId: 327070504
(One of the previous MDCBottom* CLs was reverted b/c the layout changes caused a bug in OneGoogle's bottom drawer spec. This CL has a property described below that allows apps to adopt the change on their own schedule.)
BEGIN_PUBLIC
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
1) Update the MDCBottom* classes with properties and layout adjustments to have the container view controller use the window's size instead of the screen's size in iPad Slide Over.
2) Default this new property to NO to maintain old behavior for all other apps that use MDCBottom* to avoid forced adoption and potential bugs.
END_PUBLIC
MDCBottomDrawerContainerViewController has the wrong size in iPad Slide Over (when the window height is shorter than the screen height), causing GTETaskCreationViewController to have the wrong y origin b/c it thinks it's within a taller window.
Before and after screenshots in b/159595242.
PiperOrigin-RevId: 320475781
BEGIN_PUBLIC
Revert MDC Bottom Drawer behavior change for iPad Slide Over.
The change introduced issues in downstream components.
END_PUBLIC
*** Reason for rollback ***
The original CL changes OneGoogle's bottom drawer behavior against the spec.
See b/160351551
*** Original change description ***
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
BEGIN_PUBLIC
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
END_PUBLIC
MDCBottomDrawerContainerViewController has the wrong size in iPad Slide Over (when the window height is shorter than the screen height), causing GTETaskCreationViewController to have the wrong y origin b/c it thinks it'...
***
PiperOrigin-RevId: 319809092
BEGIN_PUBLIC
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
END_PUBLIC
MDCBottomDrawerContainerViewController has the wrong size in iPad Slide Over (when the window height is shorter than the screen height), causing GTETaskCreationViewController to have the wrong y origin b/c it thinks it's within a taller window.
Note: this is 1 of 2 parts to the fix for b/only fixes. The after screenshots below are only partially correct and will be fixed in the next CL.
Before and after screenshots in b/159595242.
PiperOrigin-RevId: 319253730
This change adds a new theming method, `-[MDCBottomDrawerViewController+MaterialTheming applyThemeWithScheme:applyToTrackingScrollView:]` to allow clients to opt-in to functionality which sets `-[MDCBottomDrawerViewController trackingScrollView].backgroundColor` to the theme's background color.
PiperOrigin-RevId: 317116346
In 33daf325e6 (diff-a3db687b7d16849448cb7f189976eb0f) we added this property to allow the drawer to support max height. In adding this property my assumption was that we needed to shift the scroll view down by the amount of the topSafeArea but this is an incorrect assumption, we should leave it to the client to determine the height of the drawer an not _magically_ shift it down by an amount. Also, we tied the drawer max height to the `shouldIncludeSafeAreaInContentHeight` to the height of the drawer this caused the drawer to be shifted down by the safeArea.bottom height. The property `shouldIncludeSafeAreaInContentHeight` is related to the `maximumInitialDrawerHeight` property but not the `maximumDrawerHeight` property. Both of these values should be on the client to pass in instead of us _magically_ shifting down potentially causing issues where a client expects the drawer to be "x" height but it shows as "x - (safeArea.top + safeArea.bottom)".
Tested via the catalog examples.
PiperOrigin-RevId: 314127239
We recommend clients set the tracking scroll view of the navigation drawer so that they have a smooth scrolling experience but before this change it could be confusing if we intended clients to set this property to a scroll view from their content view controller or if it was an internal one.
PiperOrigin-RevId: 314124930
If a client sets the `maximumDrawerHeight` and the `maximumInitialDrawerHeight` to the same value then the drawer should be opened to its _max_ height. Currently if that happens the drawer allows for _safeArea.top_ pts of scrolling. This is due to us adjusting the `contentHeaderTopInset` which is then used to layout all the content. We typically adjust it because we assume that the header adds the _safeArea.top_ pts to it's height as it approaches the safe area. So really the `contentHeaderTopInset` typically _maxes out_ at that amount but if we never approach the safe area then we need to allow for this value to be 0.
Tested in the Catalog via Infinite Scrolling example.
PiperOrigin-RevId: 313814020
Currently the NavigationDrawer drawer expands to full screen as a user scrolls, this allows the client to set a maximum height that a navigation drawer can grow to. I tried doing multiple calculations to prevent the drawer from going passed a certain height but that made the component much more complex and still had some bugs. If a client chooses a `maximumDrawerHeight` that goes into the safe area the header will not grow, I am going to address that in a follow up.
PiperOrigin-RevId: 313214108
This allows our UI test runner to fetch the catalog by convention tree at runtime in order to generate dynamic test runners that walk the entire catalog by convention tree without requiring maintenance of an explicit list of breadcrumbs.
In this change I have replaced the explicit list of components with such a dynamic walker. In a follow-up change we will be able to dynamically walk through every node of the three and take screenshots. In a subsequent change from there we may allow certain nodes to implement "testActionStart" and "testActionStop" methods that allow the test runner to invoke certain canonical actions automatically (e.g. present a dialog).
A couple examples are flaky, so a new convention has been added to those examples of providing a "flaky" tag on the example's metadata. If this flag is YES, then the example will not be snapshotted.
PiperOrigin-RevId: 306214455
NOTE: This will also fix a similar issue from occurring if a client explicitly specifies `shouldPresentAtFullscreen` for their drawer presentation.
PiperOrigin-RevId: 304639191
We recommend using `initWithDefaults` and we should follow the recommendation. This change removes all usage of `init` within MDC components in order to let us remove that initializer from the public surface.
PiperOrigin-RevId: 302958447
This resolves said issue by adding an adjustment for the difference if applicable.
This change is necessary to fully support changes in modal presentation style as of iOS 13 + Xcode 11, which is important for clients because building with SDK 13/Xcode 11 is required for app store submission starting April 2020.
I verified this by testing the solution as it applies to our internal related bug, b/151091406, as well as by verifying this solution in the example project attached to the original reporting of this bug, b/148977218, and have added screencasts of this below (also attached to original bug for easier viewing).
As a sanity check, I also applied these changes to the catalog application and verified that it does not break any of the examples for this component.
PiperOrigin-RevId: 301395392
