Prior to this change, MDCChipField's chips would respond to tap gestures by showing a highlight state but the chips would not become selected. This meant that it was not possible to tap a chip and then delete it by pressing the backspace key, as is the expected behavior.
This change introduces a tap gesture onto each chip view that is added to the field. When a chip view is tapped, the chip view's selection state is toggled.
After this change, the user will now be able to select one or more chips and delete them by pressing the backspace button.
PiperOrigin-RevId: 626041379
When entering text into a chip field, the text field is expected to reflow to the next line if there is not enough space on the current line for the text field's content to be seen. Similarly, if the text field's content shrinks such that it can again fit on the previous line, then the text field is expected to move back to the previous line. This effect provides a sense of object persistence between the text field and the chips it creates.
Prior to this CL, the text field would not consistently reflow to the next line once it ran out of space, causing the text field to stay at an unreasonably narrow width. This made it difficult to see the full contents of the text field and to select text within it.
The root problem was that the logic for determining when a reflow should occur relied on assuming that the text field and chip frames had the same mid-y point. This assumption isn't always a given, so the logic was incorrectly concluding that the text field was always "on the next line".
This CL introduces a change that widens the check for "on the same line" by checking if the text field's mid-y point is contained within the chips' min/max y values.
After this CL, the text field correctly moves to and from the next line as text is entered.
PiperOrigin-RevId: 625687941
We will likely continue to use a component for Chips because they will be shorter than the 44dp that UIButton easily allows.
PiperOrigin-RevId: 485883651
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
