This PR graduates ContainerScheme to ready.
This includes updating the podspecs, podfile, all the import statements related to ContainerScheme, updating .kokoro rewrite rules, and finally the readme to not have ContainerScheme regarded to as being in beta.
Ran locally kokoro with -b bazel successfully.
Resolves#6732
The Tabs badge default text has a contrast ratio of around 4:1. For WCAG
AA-level text, we should have 4.5:1 for small text like this. Changing
to Material Red #700 increases contrast to 5:1. Material Red #600 only
provides 4.4:1 against white.
Part of #6981
Increasing text contrast for the Bottom Navigation badge. It's currently
4:1 but WCAG AA requires 4.5:1. Material Red 700 provides 5:1. Material
Red #600 only provides 4.4:1 against white.
Part of #6981
Following updating the docs in #6996 and adding additional tests #6992 for the Ripple:
In this PR I am officially graduating Ripple to ready.
These are the steps taken to do so:
1. Update docs to not show Beta anymore.
2. Move Ripple from the Beta podspec to the main podspec.
3. Removal of MDCCard+Private, MDCCard+Ripple, MDCCardCollectionCell+Private, MDCCardCollectionCell+Ripple, as they were used as connectors between Ripple being a beta component and Card being a ready component.
4. Moving the relevant code in the above files into the Card implementation.
5. Modifying the property `enableBetaBehavior` for Cards to `enableRippleBehavior` as it is no longer a beta behavior.
Tested to see all the examples work well for Cards and CardCollectionCells.
Closes#6941
**Overview**
This PR integrates the new Ripple component and its state support into our existing Cards and CardCells components. It does so in an opt in form, where you must have MaterialComponentsBeta installed for one to have Cards use the new behavior. The PR also includes 2 examples showcasing the new behavior with MDCCard and MDCCardCollectionCell.
**Resolves**: #6463
**Acceptance Criteria:**
* The Cards have an opt in property (as ripple is in beta) to be able to activate the ripple and its states support in Cards. It will fallback to the existing (legacy) implementation by default.
* An MDC example that showcases the work for Cards.
* Interaction and animation with the card should follow the guidelines from the updated cards design doc.
**Implementation Explained**
This is a pioneer PR, trying to converge a beta component into a ready component. To do so we had to have our Card component not be aware of the existence of the beta component Ripple, but we needed the Ripple component to be able to plug in to the Card component.
To achieve this I created a few different things:
1. A ripple delegate that plugs into MDCCard and MDCCardCollectionCell that consists of methods that should be invoked in the component where the Ripple work needs to be inserted. A check for the existence of the delegate and the corresponding delegate method is checked in the Card component before invoked. This allows us to identify if Ripple should be used or not.
2. A MDCCard+Private and MDCCardCollectionCell+Private categories that expose the RippleView property in the implementation files of the Card component, and also exposing other methods that the Ripple integration needs to invoke but aren't exposed in the original Card header files.
3. An MDCCard+Ripple and MDCCardCollectionCell+Ripple categories under beta, that implement the delegate introduced in 1. and have knowledge and access to the beta component Ripple. This is where the actual implementation of the ripple integration sits.
4. Lastly, we need a way to set card.rippleDelegate = self for the +Ripple categories. However, there are a few issues in achieving this. If we create a BOOL property like `shouldIntegrateRipple`, we would need to be able to switch the state from `YES` to `NO` and back correctly. The state is very complicated when you have states, ripple vs ink, etc. Therefore the best way to do this is not to allow users to trigger a BOOL, but to have a separate initializer for `initWithRipple`. However, CardCollectionCells are reused and the dequeue method calls `initWithFrame` and we can't ask it to invoke `initWithRippleandFrame` instead. Therefore, I added performSelector logic in the init methods of the Card component that checks to see if the Cards+Ripple category is apparent (meaning Beta is integrated in the framework), and if so initializes the Ripple. Happy to find alternatives if better ones are offered.
**GIFs before and after**
Before:
After:
This is the second part of the migration of moving the Shape libraries away from the private/ folder. Continuation to PR: #6495
**This is a breaking change**
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.
**We have completed steps 1 to 4, This PR concludes step 5**
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.
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.
