Also add visibleAreaInset API to the FAB typical example now that the conflict between visibleAreaInsets and shapeGenerator is resolved.
PiperOrigin-RevId: 315233817
This API allows clients to inset the visible content and allow it to be smaller than the frame.
In turn, clients can have a touch target that is bigger than the visible content.
PiperOrigin-RevId: 313556504
Note: MDCButton does not enable pointer interactivity by default.
This also adds an example to demonstrate MDCButtons with the default UIPointerInteraction enabled. The example exposes an issue with MDCFloatButton's collapse/expand animations (b/153666859), which will be addressed in a future CL.
PiperOrigin-RevId: 305872547
Two examples were using non-static storage for effectively static consts, causing the symbols to be available available across compilation units and resulting in linker errors when the symbols happen to collide across compilation units.
PiperOrigin-RevId: 305337107
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
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.
This is the third and last part of the migration of moving the Shape libraries away from the private/ folder. Continuation to PR: #6664 and #6495
Tracking bug, progress and more details can be found here: #6494
This resolves#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 6, This PR concludes step 7 and the entire migration**
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.
## Introduction
Before we move container scheme to ready we need to have both the `colorScheme` and `typographyScheme` nonnull. By making colorScheme and typographyScheme of MDCContainerScheming nonnull, clients will reduce the amount of conditional checks required in their apps and reduce a category of potential errors (accidentally passing nil to a nonnull parameter).
## The problem
Both `colorScheme` and `typographyScheme` were nullable in the container scheme making it harder for clients to use the container scheme throughout their app on non Material UIElements, i.e. UIView.backgroundColor
## The fix
Make both of these properties nonnull.
## Additional work
- [x] I had to update the swift examples to not be optional and I additionally removed the nil checks from the ObjC examples.
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.
## Related links
* Related bug: #6441
* Theming extensions: [Buttons+Theming](https://github.com/material-components/material-components-ios/tree/develop/components/Buttons/src/Theming)
## Introduction
The team is pivoting to using theming extensions so our examples should reflect the current best practices when using our APIs.
## The problem
We are using _Themers_ in some instances and some instances used a work around for the container scheme. In #6458 we added a Catalog wide container scheme.
## The fix
Remove _Themers_ for _Theming extensions_ and remove the workarounds for not having a catalog wide container scheme.
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.
