Instead of having separate `/beta` file paths for beta code, the beta files
can be excluded from CocoaPods. Also adding targets to bazel since it was trying to compile all of the source files (and failing).
Part of #4160
This is the first part of the migration of moving the Shape libraries away from the private/ folder.
Tracking bug, progress and more details can be found here: #6494
"Because Shapes and ShapeLibrary have been used in production and are an integral part of the shape scheme and theming. Moreover, with to stop the confusion of clients that the library should not be imported as it is under private, we want to migrate the Shape libs to be under components/ instead of components/private.
The migration will be a 7 step migration to not break clients internally.
1. move the folders to the new directory.
2. Make the old component's BUILD and Podspec targets depend on the new component (and nothing else).
3. Delete all implementation files from the old component.
4. Replace the contents of the old component's headers with import statements to the new component's header. If the new component has headers that match the old component's, then the new component's headers will need to be named uniquely for a period of time to allow clients to migrate over.
5. Once all clients have migrated from the old component, delete the old component. This is a breaking change.
6. If you had to create temporary header names in the new component, then in a separate release add the new headers that you want the new component to use. Move the content of the old headers into the new headers and replace the old headers with an import of the new headers. Migrate clients to the desired headers.
7. Once all clients have moved off of the old headers, delete the old headers.
Passes bazel build and pod build locally.
# Original PR description:
On Cocoapods version 1.6.0 beta 2 we get an error on pod install because certain test targets don't have any sources to compile. This PR adds some skeleton unit test source files to get that working. Is everyone okay with these (for now) basically empty files?
Closes#5825
# FInal PR description:
The original aim of this PR was to get the project working with the Cocoapods 1.6 beta.
I initially didn't know where to begin getting it to work, so I used `pod lib lint` to get answers. `pod lib lint` had issues with the following things:
1. test_specs not having any sources to compile. This was due to our pattern of putting unit test test_specs inside of parent test_specs that didn't have anything else.
To address this I did two things. First, I moved away from the nested test_spec pattern. Now, instead of "Subspec/tests/unit_tests" it's "Subspec/UnitTests". This is more in line with the style Cocoapods uses [here](http://blog.cocoapods.org/CocoaPods-1.6.0-beta/). Secondly, I added some dummy files for things like UIMetrics and MaterialMath.
2. Importing headers across modules without using framework style imports.
I added framework style imports. This required some additional rewrite rules in the kokoro script.
3. Dependencies across subspecs being implicit.
I made them explicit by adding dependency statements to the podspecs where needed.
`pod lib lint` didn't take issue with this, but I also saw that `MaterialComponents` was depending on `MaterialComponentsBeta` in various places. For example, all the theming extensions were in beta, but the tests for them weren't. I moved the tests to test_specs within the beta extensions. This required some directory structure changes. These changes then required some BUILD file changes. Making BUILD file changes made me realize that some swift unit tests weren't being accounted for by bazel. I took care of this too.
This PR also fixes some swift debugging stuff--"po" statements that weren't working before now do. I didn't rigorously verify this, but I also think this PR will lead to faster clean build times? It kinda seemed like it was while I was working on it.
### Context
As the team pivots to using theming within extensions we continue this work with Chips.
### The problem
We currently do not theme chips using a theming extension
### The fix
* Add theming extension for MDCChipView
* Write unit tests for new extension
In follow-up PRs, I will update the existing examples to utilize the new extension and write snapshot tests as well.
### Bug
Part of #6083
This reverts commit fdaf872c605cab44a4579cb8b7f0ea168c445318. The
container scheme import is missing in a Swift example.
```
material_components_ios/components/Cards/examples/EditReorderCollectionViewController.swift:38:24 use of undeclared type 'MDCContainerScheming'
var containerScheme: MDCContainerScheming {
^~~~~~~~~~~~~~~~~~~~
```
Reopens#6030
This is an automated change generated by replacing all instances of MaterialComponentsAlpha with MaterialComponentsBeta. This is not a breaking change because changes to Alpha/Beta components (including renaming them) are not considered breaking.
The MaterialComponentsAlpha podspec was mistakenly named Alpha, when what we meant was more close to Beta. The distinction is that Alpha components are not expected to be used by clients, while Beta components are.
### Context
All of our theming targets should be `MDC<#Component>+Theming` but all files should be `MDC<#Component>+MaterialTheming.m/h`. We got out of sync and caught this early.
### The problem
Our targets and file names weren't correct in some cases
### The fix
Update our targets and files to be what we have decided as a team.
### 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
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 |
| - | - |
|||
This change makes use of MDCContainerScheme to provide a single theming-related API for ButtonBar.
Includes example updates unit tests.
This change is the first in a series of changes that will be required to add Theming extension support to AppBar:
- [x] ButtonBar
- [ ] NavigationBar
- [ ] HeaderStackView
- [ ] FlexibleHeader
- [ ] AppBar
### The problem
We currently do not have UI tests on a component level. Integrating snapshot tests would allow us to have peace of mind with each PR that it isn't going to introduce any changes to the UI unless its intended to.
### The solution
* Integrate `ios-snapshot-test-case` pod to handle generating and diffing images of components.
* Integrate `git-lfs` to handle storage of the goldens.
This PR creates one test to showcase the ability to do snapshot tests. Upon merging this PR, you must install git-lfs in order to properly have the images pulled down. The 3 steps to do this:
1. `brew install git-lfs`
2. `git lfs install`
3. `git lfs pull`
Additionally, the golden is generated using an iOS 11 simulator at 2x scale so that the kokoro jobs are happy.
### Related bugs
Closes#5740
### Context
As the team pivots to using theming within extensions we have started off with buttons as a test run. This will be part fo the work with buttons only addressing the contained button type. This adds a new method to MDCButton - `applyContainedThemeWithScheme:(id<MDCContainerScheming>)scheme`
### The problem
We currently do not theme buttons the way the team has decided to theme them
### The fix
This themes Contained buttons with the new style we have all agreed on.
### Remaining Work
Theming for Text and Outlined buttons in this new style.
**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**
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
Adding semantic emphasis to Dialog actions which allows conditional theming of buttons. The MDCDailogScheme now has a button scheme which can be used to theme buttons according to their action's assigned emphasis.
Issue: b/117608629
Design Review document (go/gmdc-ios-dialogs-design-doc).
