This change is a slight alteration to the change introduced in cl/347036858 this moves the added code to the bottom of the method so as to not interfere with the recursive call.
BEGIN_PUBLIC
Made a slight change to move adding `presentingViewYOffset' to `_contentHeightSurplus` to the end of the method. This was added in a previous change but didn't take into account the possibility of an infinite recursive loop. This movement should prevent that while also updating `_contentHeightSurplus` to the proper value. This should also fix the bug brought up in b/176122058
END_PUBLIC
PiperOrigin-RevId: 351455638
BEGIN_PUBLIC
Updated the `contentHeightSurplus` method to add in an additional value of `presentingViewYOffset'. In the current iteration the `presentingViewYOffset' gets cancelled out by being included in both `scrollingDistance` and `containerHeight`. This change will take that offset back in to account and resolves a UX bug that we're currently seeing devices with smaller screen sizes using the PageSheet presentation style (b/173830907).
END_PUBLIC
PiperOrigin-RevId: 347036858
Cause:
The variable dismissOnBackgroundTap should be used to determine whether gesture recognizer is added to the presentation view controller. When the check was removed, gesture recognizer is interfering and touchesended is not propagated.
Fix:
Add back the check and add tap gesture recognizer only when dismissOnBackgroundTap is set to true.
PiperOrigin-RevId: 336292017
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\]'
