This PR is the last step in graduating the Navigation Drawer component from Beta to Ready.
We have resolved all the outstanding issues in the Navigation Drawer Project here: https://github.com/material-components/material-components-ios/projects/85 and hotlist: 1230549 .
The only outstanding issue is the unit tests ( #5466 , #5465 ) which were approved and are pending due to GitHub issues causing CI not to run.
We are essentially migrating here the NavigationDrawer component from the MaterialComponentsAlpha podspec to the MaterialComponents podspec so it can be used publicly using the normal means of installing our Pod.
This PR is blocked and can land once #5466 and #5465 land.
Closes#5333
### The problem
BottomDrawer previously had no color themer support
### The fix
This change adds a color themer for BottomDrawer. Additionally this adds unit tests and updates the example to use the color themer. The guidelines indicate the content and header should utilize the semantic surface color, so that is what the themer applies to the BottomDrawer.
**Note:** The drawer should be configured with its header and content ViewControllers before applying the theme.
### Related issues
Closes#4910
### Code snippet
#### Swift
```
let bottomDrawerViewController = MDCBottomDrawerViewController()
bottomDrawerViewController.contentViewController = contentViewController
bottomDrawerViewController.headerViewController = headerViewController
MDCBottomDrawerColorThemer.applySemanticColorScheme(colorScheme,
toBottomDrawer: bottomDrawerViewController)
```
#### ObjC
```
MDCBottomDrawerViewController *bottomDrawer = [[MDCBottomDrawerViewController alloc] init];
bottomDrawer.contentViewController = contentViewController
bottomDrawer.headerViewController = headerViewController
[MDCBottomDrawerColorThemer applySemanticColorScheme:self.colorScheme
toBottomDrawer:bottomDrawer];
```
### Context
In #5345 the podspec is wrong, it depends on the system schemes instead of the other themers.
### The fix
Update the podspec to match other components and depend on other subspecs instead of schemes.
### Context
On of the requirements for new components is to have a _themer_ that applies the typography and color schemes as well as any other properties that are needed to the component.
### The problem
Action sheet didn't have one it just had a color and typography themer that were separate.
### The fix
This PR adds a component themer that applies the typography and color schemes to the component.
### The problem
ActionSheet previously didn't have a color themer at all.
### The fix
This adds a color themer to ActionSheet, as well as test to test these use cases
### Related issues
#5039
### Code snippet
#### Swift
```
let actionSheet = MDCActionSheetController()
MDCActionSheetColorThemer.applySemanticColorScheme(colorScheme, to: actionSheet)
```
#### ObjC
```
MDCActionSheetController *actionSheet = [[MDCActionSheetController alloc] init];
[MDCActionSheetColorThemer applySemanticColorScheme:self.colorScheme
toActionSheetController:actionSheet];
```
### Screenshots
| Before | After |
| ------ | ----- |
|||
_Screenshot generated with_
```
self.colorScheme.surfaceColor = .yellow
self.colorScheme.onSurfaceColor = .magenta
```
See docs for test_spec here: https://blog.cocoapods.org/CocoaPods-1.3.0/
test_spec is an official CocoaPods mechanism for associating tests with a component. tests_spec has several advantages over our prior "tests as a podspec" hack:
- We can finally run individual tests from Xcode's inline green "test" button that shows up alongside each test in the editor.
- Tests can import private header files from components from .h files in the test target (because tests are no longer treated as frameworks). We were not previously able to do this, making it impossible to create .h/.m files that were shared across multiple test .m files.
- We no longer need MDCUnitTests - everything lives in the MDCCatalog target.
- The tests/ folder now appears as a sub-group for each component in the MaterialComponents development pod group. This will have a big impact on day-to-day workflow. Previously our tests lived in a sibling group to our components, making it somewhat difficult to navigate back-and-forth in Xcode.
- pod lib lint is now able to run our unit tests.
- Our tests can now explicitly declare their dependencies.
Some caveats:
- Each component now needs a test_spec subspec definition. This is a minor detail and one that doesn't add much extra work when creating a new component (we continue to just copy the existing templates).
- When adding a new test_spec, we also need to add the test_spec to our MDCCatalog Podfile under the `:testspecs` list. This is a bit annoying, but only happens when new components are created (very infrequent). This is a good case of the cost here being outweighed by the benefits above (which affect our daily workflow).
## Screenshot
<img width="405" alt="screen shot 2018-09-22 at 9 40 17 pm" src="https://user-images.githubusercontent.com/45670/45920647-33f4c180-beb0-11e8-94bc-88f3450c9e0a.png">
Adding the navigation drawer component that adds a presentation controller for showing UIViewControllers as a bottom drawer.
History of the component (last CL submitted for it): cl/209765207
Design doc: go/mdc-ios-navigation-drawer
This component will be the first alpha component in this repo, this means that it can still change and will not be included as part of the podspec at first.
The intent of the Alpha program is to provide a place for component code to land that may not be fully ready for production, but for which we still want active collaboration with the team and potentially some early adoption with select clients.
Any new component that we implement will first land in the MaterialComponentsAlpha.podspec as a subspec, similar to how components are defined in the MaterialComponents.podspec.
Alpha components will appear in MDCCatalog and MDCDragons along with all of their examples and unit tests after a `pod install`. From the point of view of our catalogs, these components are just like any other.
From the point of view of the public, Alpha components are not made available as part of our published pod. External clients that wish to use an Alpha component in their app will need to manually clone the repo and add the code to their project. This is by design.
Alpha components are not subject to our deprecation policy and we will not provide behavioral flags for gradual migration of runtime behaviors.
Changes to Alpha components will have **no** effect on our release version numbers.
Once a component is ready for general production use, we will graduate the component to the MaterialComponents.podspec. At this point the component will be subject to all of the processes and expectations that any other production component.
