1. Adds a new delegate method `chipFieldShouldEndEditing` to match `chipFieldShouldBeginEditing`
2. Moved the call to the chip field delegate for `chipFieldDidBeginEditing` and `chipFieldDidEndEditing` so they are fired at the correct time.
I noticed that the UITextFieldDelegate method `textFieldShouldBeginEditing` can be called without actually becoming the first responder if the previous first responder doesn't resign it. That meant that the chip field would still claim to have begun editing even if it hadn't.
PiperOrigin-RevId: 367240207
This fixes an issue where an MDCChipField height change triggered by text input would not inform the delegate of the height change. Because we're now sending the height changed message in layoutSubviews, we also need to remove the notifyDelegateIfSizeNeedsToBeUpdated method to avoid duplicate calls to chipFieldHeightDidChange:.
PiperOrigin-RevId: 307814300
Currently since we expose the `titleLabel` and `imageView` of the `MDCChipView` when properties that can result in changes in size occur clients need to call `invalidateIntrinsicContentSize` in order to get the chip to update it's layout. This should be handled on our end instead of requiring clients to force the chip to layout when these properties change we can do it for them in the component. This issue occurs when the client has set the `autoresizingMask` to `.flexibleWidth, .flexibHeight` and constrained the position of the chip as seen in the tests.
I added unit test here instead of snapshot test because `BOOL success = [view drawViewHierarchyInRect:view.bounds afterScreenUpdates:YES];` in the snapshot test forces the chip to relay itself out causing the test to look like they are passing when they really aren't.
An alternative approach here would be to subclass UIImageView and UILabel and when the respective properties are set we can `invalidateIntrinsicContentSize` on the chip but I felt this case was better suited for KVO so we don't have to maintain these subclasses.
PiperOrigin-RevId: 302049886
Updates calculation of text field frame in MDCChipField.
Previously, the text field's frame was always the full width of its parent MDCChipField, with the left inset being provided by textInsets:withSizeThatFitsWidthHint:. This change updates the left inset to be constant, and updates the text field frame's width to fit the available space to the side of the chips if the text field's text is short enough.
This is a partial roll-forward of https://github.com/material-components/material-components-ios/pull/9828. The primary change is that the default minimum text field width has been updated to match the minimum HIG-recommended touch target size.
Pre-work for #9006
* [Chips] Add MDCChipField snapshot tests verifying text field placement
* clang
* Add calls to sizeToFit to capture overall chip field size
* Cast doubles to CGFloats
Reverts 04567ba1653cb61927117160c3e8fd37e186d4b9 and 8b7c2b696c1f1ea212817f38b75d47825f3deb39
This change is getting rolled back because, when adding chips programatically, the MDCChipField grows taller than it should. After rollback, I'll add snapshot and/or unit tests to capture the current behavior and attempt to fix the issue then.
Reopens#9006
* [Chips] Resize MDCChipField's textField frame instead of using left insets to align with chips
* Update tests to reflect text field frame editing (instead of placeholder frame editing)
* clang
Currently, the Chips component uses the `hitAreaInsets` API to allow an increase of the touch target of the view. However, when using MDCChipCollectionViewCell, setting the `hitAreaInsets` does not work, because there is no pointInside method to increase the tap target for the cell itself, which is responsible for the touches. This PR adds the same logic to the chip cell, borrowing the value of the hitAreaInsets from the chip view.
Tested in catalog with iOS 13 and iPhone Max Pro simulator and added unit tests.
Closes#9276
Adds extra tests for `imagePadding` focused on when no image is visible or
when only `selectedImage` is visible.
Preparation to roll-forward #9267
Part of #9250
Adds more snapshot tests to capture the behavior of Chips when a
`selectedImageView.image` is set. An upcoming change will correct the layout
of subviews when `imagePadding` is used, and these tests capture errors that
take place when a `selectedImageView.image` is set.
Preparation for #9250
This is a roll-forward of #9266
Adds several new snapshot tests intended to evaluate the following APIs:
* `- contentPadding`
* `- titlePadding`
* `- imagePadding`
* `- accessoryPadding`
Confirms bugs found as part of #7940
This is a roll-forward of #9252
Corrects the behavior of `imagePadding` in two significant ways:
* Previously, the union of the frames of `selectedImageView` and `imageView`
were used to determine the position of the `titleLabel`. However, since
`selectedImageView` is documented as not having an effect on
`MDCChipView` unless it is set and the Chip is selected, it should not have
any effect on the frame calculations when unselected or unset.
* `imagePadding` is now only applied if either `selectedImageView` or
`imageView` in the Chip. Previously, `imagePadding` would have been
applied even without an image present.
Closes#9250
Adds more snapshot tests to capture the behavior of Chips when a
`selectedImageView.image` is set. An upcoming change will correct the layout
of subviews when `imagePadding` is used, and these tests capture errors that
take place when a `selectedImageView.image` is set.
Preparation for #9250
Adds several new snapshot tests intended to evaluate the following APIs:
* `- contentPadding`
* `- titlePadding`
* `- imagePadding`
* `- accessoryPadding`
Confirms bugs found as part of #7940
The accessory view's frame was incorrectly calculated by ignoring its `.left`
padding value. This would result in the padding being added twice when the
Chip was sized and laid-out.
Preparation for #7940
