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
We need to add @objc annotations to colorScheme and typographyScheme instances in our Swift examples, because we moved to Swift 4.2, the respondsToSelector won't find `setColorScheme:` and `setTypographyScheme:` setters otherwise.
This is a follow up PR for #7166 adds @objc annotations to Swift catalogMetadata() methods, because the Swift 4 compiler no longer attempts to infer what methods should be visible to Objective-C. As a result of this change in the compiler, no Swift examples were showing up in Dragons after #7166. See this article: https://useyourloaf.com/blog/objc-warnings-upgrading-to-swift-4/ for additional context.
### 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:**
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:**
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.
