This delegate method allows clients to have one ripple touch controller control multiple ripple views. Also gives them more flexibility on the creation and reusing of ripple views.
PiperOrigin-RevId: 317614179
Voice Over and Switch Control users can activate the Card to show Ripple.
The card has an accessibility label and an accessibility trait to indicate that it is interactive.
Closes#8914
All views in example are accessible with Voice Over and can be activated.
All views have a relevant accessibility label and the appropriate traits.
Closes#8913
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.
We need to add @objc annotations to the containerScheme instances in our Swift examples, because we moved to Swift 4.2, the respondsToSelector won't find the setContainerScheme: setter otherwise.
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.
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:
In some cases because the Ripple handles touches to figure out when the touch is moved in and out of bounds, or if it is cancelled or ended, it will consume the touch and not allow the superview or other subviews receive the touch.
Therefore, I have moved away from the approach of having the stateful ripple view receive any ownership of the touch by setting pointInside for it to always be NO. However, to be able to have stateful ripple follow material guidelines, I have put new guidance to views adding the ripple view as a subview to pass on the standard touches to the ripple view to have it work as intended.
Documentation in our GitHub on how to integrate it correctly will be added as a follow up. Documentation in the header has been fully fleshed out and added in this PR.
The example for stateful ripple incorporates these updates and works as intended.
As per our discussion, design doc, and design review meeting, provided is the stateful ripple implementation to be reviewed and added to our Ripple beta component.
Also included is an example showcasing the stateful ripple as part of the acceptance criteria.
Design doc: go/state-system-ios
Corresponding API PR that was approved: #6490Resolves#6562
Please see below gif showcasing the example:
For our Ink successor Ripple, which is currently a Beta component, we want to initially clean the implementation so it doesn't consist any notion of state and be equivalent to our Ink component in terms of API and feature set. Further additions will be reviewed and discussed as follow ups with the team.
This PR includes the ripple implementation that is up to date with Material design and motion guidelines.
A ripple by definition is a visual form of feedback for touch events providing users a clear signal that an element is being touched. The ripple effect is a core functionality for components such as buttons, cells, cards, etc.
This will eventually succeed the outdated Ink component, and is currently being added under MaterialComponentsBeta.
There are unit tests and an example included to this PR.
The full design doc can be found here: go/ripple-ios-revisited
