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
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
Prior to these changes, changing the maximumInitialDrawerHeight did not have any effect after initial presentation. This adds the ability to modify the value after presentation.
Also enables the ability to change the preferred content size with an animation. If the preferred content size is less than the maximum initial drawer height, the visible portion of the content will be adjusted. Previously, the visible portion would remain the same size, even if more could be shown on screen.
Closes#7369.
Added ability to account for bottom safe area in presentation of initial drawer height, parameterized by default-off flag.
Fixes#9322.
I tried adding unit tests on this, per our conversation @yarneo, but ran into some issues with writing tests around this as:
1) unit testing for this is difficult as one cannot manually set the `safeAreaInsets`
2) snapshot testing this requires that the test suite is done on an iPhone X or similar device with bottom insets, which is not the current test device for snapshots as far as I can tell
I'm happy to add tests but need a bit of guidance regarding how to best test this given the above constraints. I didn't see a test testing the related `shouldIncludeSafeAreaInContentHeight` behavior, which I was looking to use as a test reference, but perhaps could do something similar to: b8090cb638/components/FlexibleHeader/tests/unit/supplemental/FlexibleHeaderTopSafeAreaTestsFakeViewController.m (L90-L94).
Wanted to get your thoughts on this before diving further @yarneo.
[BottomDrawer] Allow touch events to propagate to delegate for MDCBottomNavigationDrawer
Allow the drawer to optionally forward touch events to the delegate for handling. This enables tap thru to the underlying VC if the client needs that behavior.
An example use case would be when the client wants to present the drawer on top of a VC that has controls that they want to still be tappable. For example: A video player or a podcast player with play/pause controls. Then the client VC could still receive the tap event on the control and respond to that and close the drawer at the same time. This would allow the user to save a tap.
this is a second attempt at https://github.com/material-components/material-components-ios/pull/8486
original cl/270318683
[NavigationDrawer] Add delegate methods to allow the presenting VC to gain access to the transitionCoordinator used during the present/dismiss transitions. Also provide callbacks for y-offset changes so that the presenting VC can animate content along with the y-offset changes.
Fixed requests from previous PR and added some tests for the callbacks.
Screen recording of the usage:
https://github.com/material-components/material-components-ios/files/3633638/navdrawer.mov.zip
Allow the drawer to optionally forward touch events to the delegate for handling. This enables tap thru to the underlying VC if the client needs that behavior.
An example use case would be when the client wants to present the drawer on top of a VC that has controls that they want to still be tappable. For example: A video player or a podcast player with play/pause controls. Then the client VC could still receive the tap event on the control and respond to that and close the drawer at the same time. This would allow the user to save a tap.
Add delegate methods to allow the presenting VC to gain access to the transitionCoordinator used during the present/dismiss transitions. Also provide callbacks for y-offset changes so that the presenting VC can animate content along with the y-offset changes.
Fixed requests from previous PR and added some tests for the callbacks.
Screen recording of the usage:
[navdrawer.mov.zip](https://github.com/material-components/material-components-ios/files/3633638/navdrawer.mov.zip)
This adds the notion of elevation and a customizable shadow color to the Bottom Drawer.
Addition of unit tests and snapshot tests.
This now allows the Navigation Drawer to properly support MDCElevation as part of the Dark Mode work.
The `_contentHeaderTopInset > _contentHeightSurplus` check in `MDCBottomDrawerContainerViewController`'s `cacheLayoutCalculationsWithAddedContentHeight:` function was erroneously evaluating to `true` when presenting content:
- in full screen
- with no header
- with the content's height being equal to the available height
Because of how `_contentHeightSurplus` is calculated, it was almost (but not quite) equal to `_contentHeaderTopInset`, which was causing the function to infinitely recurse.
This PR also adds an example that demonstrates the issue. To reproduce:
1. Open MDCDragons
1. Navigate to the "Bottom Drawer No Header Less Content" example
1. Rotate the phone/simulator to landscape
1. Show the bottom navigation drawer by tapping on the menu icon
Expected:
The bottom drawer is displayed.
Actual:
The `cacheLayoutCalculationsWithAddedContentHeight:` infinitely recurses and the app crashes due to stack overflow.
Closes#7633
This adds a new opt-in flag for clients to tell the drawer to add the bottom safe area inset to the content height. That way the content can be seen correctly without overlapping on the bottom safe area.
This issue has been reported by an internal client and helps with bug: b/123500336 .
This is a follow up PR to https://github.com/material-components/material-components-ios/pull/7544
In some cases, clients may have their contentViewController's preferredContentSize only update later in the lifecycle. In cases like that, the _preferredContentSize property may still be 0. Before this change, it would cause the drawer to be much smaller than it should be. This resolves the problem by not updating the drawer height if the content height is still 0.
This has been reported by 2 internal clients so far.
Related bugs: b/123500336 , #7369
We are adding a new property for NavigationDrawer's API called `maximumInitialDrawerHeight` which allows clients to set the initial height of the drawer, rather than it always being 50% of the screen's height.
We also had to be mindful that in some cases allowing any percentage could have the offset of the scrollView be a fractional number that wasn't reasonable, and therefore UIKit would round the scrollView's contentOffset to a close (yet different) value. Therefore to not cause inconsistencies between what the scrollView content offset returns and the drawer's initial offset, we rounded the number after the initial percentage calculation.
Unit tests have been added and all examples have been tested with and without the variable.
Resolves#7080
## Related links
* Related bugs: #5804#6305
* Component: [NavigationDrawer](https://github.com/material-components/material-components-ios/tree/develop/components/NavigationDrawer)
## Introduction
While working on #6305 I noticed that in certain cases the NavigationDrawer would not set the `trackingScrollView` correctly in certain cases.
## The problem
There was a race condition that if a user set any one of the properties on the `presentationController` before they set the `trackingScrollView` then the `trackingScrollView` internally would be nil.
## The fix
Set the tracking scroll view on the `presentationController` instead of on the `transitionController`.
## Related links
* Bug: #6305
* Component: [NavigationDrawer](https://github.com/material-components/material-components-ios/tree/develop/components/NavigationDrawer)
* Related PRs: #5928#5587#5520#5443
## Introduction
The navigation drawer should support resizable content. This content should be able to change and the drawer stay at the same height or not _jump_ to another height. There was a problem where the drawer would jump between heights for certain `preferredContentSize`'s of the `contentViewController`. This was thought to be addressed in #5928. Upon investigation the root cause was not that the drawer jumped when `preferredContentSize` changed but that some how the drawer was able to open passed it's `initialDrawerFactor`. Therefore when the `preferredContentSize` did change the drawer go to the correct `initialDrawerFactor` and when it changed back it would go to the incorrect value. Additionally, when the drawer got into this state it would be in an `.expanded` drawer state because the drawer thought it should open up passed the `initialDrawerFactor`.
## The problem
The drawer thought it had less content that it actually had and therefore would go into the incorrect state and override `initialDrawerFactor`.
## The fix
Upon investigation fixing the drawer's internal calculation as to how much _content_ it actually has vs how tall the `presentingViewBounds.height` multiplied by `initialDrawerFactor`.
## Tests
Tests were updated as well as comments around them to understand why they were updated.
## Code snippet
In order to test the before and after behavior edit `BottomDrawerInfiniteScrollingExample.swift` as outlined below.
```diff
let bottomDrawerViewController = MDCBottomDrawerViewController()
+ contentViewController.supportsScrollToTop = false
bottomDrawerViewController.contentViewController = contentViewController
```
Doing the above will showcase how the drawer got into it's broken state.
This PR closes#5600 .
The drawer now has added functionality allowing users to expand the drawer to full screen with duration and completion.
Clients have asked for this functionality, and it is also providing the expand to full screen functionality correctly even when the content is less than the full height of the screen.
### Context
Currently `MDCBottomDrawerViewController` _jumps_ if the preferredContentSize changes. A client is asking for this _jump_ to not happen but instead the drawer will look the same but have more content.
#### Conditional checks
1. The check to see if `_contentVCPreferredContentSizeHeightCached` is zero is because on initial layout this value is 0 until we call `cacheLayoutCalculations` which sets this value.
2. The check to see if `percentageFullScreen > 0.5` is there to make sure we never have an initial drawer factor more than design has specified.
### The problem
`MDCBottomDrawerViewController` _jumps_ if the preferredContentSize changes
### The fix
Set initialDrawerFactor to a custom value so that change doesn't cause a jump.
### Videos
| Before | After |
| - | - |
|||
### Context
A lot of the test used the same code in the given portion of the test. All of those given statements can be summarized into a function to reduce complexity of the test.
### The problem
Similar code throughout the test.
### The fix
Pull all of that code into a function.
**Context:**
Clients want the ability to scroll their content in the drawer to a specific content offset, most commonly to the top of the content.
**Problem:**
There is no current API that exposes a set content offset or moreover no API that exposes the internal scrollView to allow our clients to set its content offset as they will.
**Solution:**
Provide an API to set the content offset Y of the scrolled content of the drawer. Setting that offset Y to 0 essentially scrolls the user to the top. This API also allows the scrolling to be animated or not.
**Related Bugs:**
Closes#5713
**Context:**
There is degraded scrolling performance for clients who have heavier calculations when providing the `contentViewController`'s `preferredContentSize`. This is pretty common for dynamically sized content.
**Problem:**
We are calling preferredContentSize more times than we should, when we can defer re-calling it unless we are receiving a `preferredContentSizeDidChangeForChildContentContainer` call.
**Solution:**
Have `preferredContentSize` only called in `cacheLayoutCalculations`. The other unneeded `preferredContentSize` calls take their value either from another class that has already calculated the `preferredContentSize`, or within its own class as a property which caches the latest `preferredContentSize`.
**Related Bugs**
Closes#5715
{MDC iOS} No longer using `-init` for Color Scheme.
Based on the discussions in go/mdc-ios-theming, we should not use the `-init` default initializer. Instead, we should use an explicit set of defaults.
Search regex: '\[\[MDCSemanticColorScheme alloc\] init\]'
**Context:**
Clients need a way to know the content inset of the drawer to be able to lay out their content appropriately.
**The Problem:**
Because things like the status bar, safe area, and the top handle take up more space at the top of the drawer, the content that is laid out initially will be clipped if not able to move the content appropriately as the drawer is dragged.
**The Fix:**
Add an MDCBottomDrawerViewControllerDelegate that listens to topInset changes as the drawer is dragged and provides the top inset in which the content should be laid out below.
**Testing:**
Unit Test + Tested on an iPhone X and iPhone 7 on all examples, portrait and landscape.
**Context:**
The navigation drawer's top handle should have an API to be able to customize its color.
**The Problem:**
Currently our top handle only has a default color set and can't have clients customize its color.
**The Fix:**
Provide an API to MDCBottomDrawerViewController to set the handle's background color.
**Testing:**
Unit Test + Tested on an iPhone X and iPhone 7 on all examples, portrait and landscape.
**Screenshot**
**Context:**
Clients need the ability to dynamically size their navigation drawer content and have the drawer work appropriately and correctly.
**The Problem:**
Currently we have no mechanism where we let the drawer know that the size of the content has changed and the internal calculations need to be re-calculated and re-applied.
Also, before we were partially listening to the `preferredContentSize` by asking if it has changed every so often using the conditional in the `contentHeightSurplus` getter. Some clients can have a very calculations heavy `preferredContentSize`, which will cause the whole drawer mechanism to lag.
**The Fix:**
Because the `contentViewController` and the `headerViewController` are child view controllers of `MDCBottomDrawerContainerViewController` , we can listen to `preferredContentSizeDidChangeForChildContentContainer` and reset the previously calculated variables and relayout the drawer.
**Testing:**
Unit Test + Tested on an iPhone X and iPhone 7 on all examples, portrait and landscape. A dragons example has been created exactly for the testing of the dynamically changing content size here: #5545
**Related Bugs:**
Closes#5514
**Context:**
The Navigation Drawer should have an affordance to show scrollability in a shape of a top handle.
**The Problem:**
Currently we have no top handle in our drawer to show scrollability.
**The Fix:**
In this PR we are adding a top handle to our drawer. the top handle is hidden by default. when the top handle isn't hidden, it is visible when there is more scrolling to perform for the drawer, and then it fades away as the drawer reaches its full height, or when it goes to full screen.
**Testing:**
Unit Tests + Tested on an iPhone X and iPhone 7 on all examples, portrait and landscape.
**Related Bugs:**
Closes#5515
**Screenshot**
**Video of transition**
**Context:**
Some clients were not aware that their content's scroll view needs to be disabled so the content will not start scrolling while dragging the drawer.
**The Problem:**
Clients need to explicitly set their tracking scroll view scrolling to disabled manually.
**The Fix:**
If a tracking scroll view is provided, set the scrolling to disabled automatically and therefore cause less client confusion
**Testing:**
Unit Test + Tested on an iPhone X on all examples.
### Context
In order to support a fully themable NavigationDrawer we need to be able to set the _scrimColor_ to a custom color. These changes add a property to be able to do so. If the _scrimColor_ isn't set the the `scrimView` in the `MDCBottomNavigationPresentationController` defaults to `[UIColor colorWithWhite:0 alpha:0.32];`.
### Related bug
b/117274465
### Screenshots
| Before | After |
| - | - |
|||
**_Code snippet for after screenshot_**
```swift
bottomDrawerViewController.scrimColor = UIColor.blue.withAlphaComponent(0.5)
```
Context:
This change opens up an API to the nav drawer to allow clients to round the top corners using the state system. allowing them to define what corner radius will the top corners have based on the state the drawer is in.
The Problem:
There was no way for users to customize and set the top corners' radius of the drawer.
The Fix:
We now have an API open that allows users to set the corner radius using the drawer's state system. The corner radius logic was moved to the MDCBottomDrawerViewController because that logic isn't part of the drawer scrolling mechanism and shouldn't sit in MDCBottomDrawerContainerViewController if not necessary. To achieve the desired outcome we exposed internally the bottomDrawerTopTransitionRatio:transitionRatio API to the MDCBottomDrawerViewController so it can animate the transition between corner radius shapes smoothly.
Testing:
Unit Tests + Tested on an iPhone X and iPhone 7 with smaller and bigger preferredContentSize to imitate different states. Tested on Portrait and Landscape on all examples.
Related Bugs:
Closes#5516
