[TextFields] Updates to SimpleTextFIeld and InputChipView prototype
This PR contains a lot of updates to SimpleTextField. Some of these updates are for little things I noticed I got wrong after looking at the guidelines a bit more. The more substantial changes introduced here, however, are related to feedback given in the design doc overview meeting in January. As a reminder, the two takeaways from that meeting were:
1. SimpleTextField shouldn't depend on MDCContainerScheme
2. The styles should not be represented as enum cases. Instead, they should be objects.
These changes address those pieces of feedback. While I still need to get around to updating the design doc to reflect the changes, I don't see the harm in merging the updates into their home in a MaterialComponentsExamples experimental directory.
This PR also contains changes that are not directly related to SimpleTextField!
Late last year, when we had the week of free time to do whatever we wanted, I began thinking about incorporating chips into SimpleTextFields. Not far into it I decided that any view implementing input chip functionality should be its own view, i.e. it shouldn't be stuffed in a UITextField, which carries inheritance-related burden. I started work on such a view in January, and briefly used it during the SimpleTextField design doc overview meeting to demonstrate how SimpleTextField styling could be generalized across views.
Following that meeting, and following the refactoring work to address feedback on SimpleTextFields, I updated the InputChipView to see how extensible my "container style as object" approach was. I think the work here, while definitely not a finished product, demonstrates that it's fairly usable. MDCSimpleTextField (I added an MDC) and InputChipView (no MDC) both conform to a protocol called MDCContainedInputView. That protocol declares a property for objects conforming to MDCContainerStyling. There are a few other classes and protocols in there, but I will write or talk more about those in a different setting. The key here is that I think it all might work, based off these changes. There are still some loose ends, but they can be taken care of. They _will_ be taken care of if the team decides to take this direction. They maybe won't if we decide to continue investing in MDCTextFields for all of our user input needs. If we do end up deciding to bring all this into the codebase I want the next addition to this family of contained input views to be a subclass of UITextView, for multiline text input.
This gif shows the updated MDCSimpleTextField styled as an "outlined" text field:
This gif shows the updated MDCSimpleTextField styled as a "filled" text field:
This gif shows the updated InputChipView styled as an "outlined" input chip view whose chips do not wrap:
This gif shows the updated InputChipView styled as an "outlined" input chip view whose chips wrap:
This gif shows the updated InputChipView styled as a "filled" input chip view whose chips do not wrap:
This gif shows the updated InputChipView styled as a "filled" input chip view whose chips wrap:
Removes the need to copy-paste stanzas from other files anymore as we'll rely on #4478 to generate the correct stanza for us instead.
This was an automated change generated by running a find-and-replace regular expression:
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
// Copyright $1-present the Material Components for iOS authors. All Rights Reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
```
We can now make use of @available throughout our codebase.
We support Xcode 9 and up, which includes the iOS 11 SDK. This means we can remove any guards for SDKs prior to iOS 11.
This was cleaned up by running a global find-and-replace with the following regular expression:
```
Find:#if defined\(__IPHONE_11_0\) && \(__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_11_0\)\n(.+if \(@available\(iOS 11.0, \*\)\) \{(?:.|\n)*?)(?:#else(?:.|\n)*?)?\n#endif
Replace:$1
```
With some additional cleanup for stragglers that didn't match this pattern. Note that else clauses were intentionally dropped.
Closes https://github.com/material-components/material-components-ios/issues/4909
Adding textInputFont and TextInputFontDefault properties to inputController was breaking many client who used to set the font straight to textInput font property.
The reason behind adding this property was to fully support dynamic types.
Reverting this change will break dynamic types support for textfields.
Pivotal issue to address the work needed to add this property: #156518577
* Extracting Accessibility out of FeatureHighlightViewController to a mutator.
Tests added.
Example updated.
* Revert "Extracting Accessibility out of FeatureHighlightViewController to a mutator."
This reverts commit 0b5433ebf86366087b240c4dc4992a0603fa73e0.
* Adding Font themer to TextFields.
* extra lf.
* dealing with warnings.
* Fixing unit tests.
* commenting out low priority set up for bounds
* commenting out tests to see if tests would fail.
* tests are back, scale could have been zero.
* temp fix in case the fonts are zero.
* check for default inside setter.
* fix compliing mistakes.
* add documentation for the change.
* Example of dynamic size with different fonts.
* added support for dynamic type with custom fonts.
* fixed the top overlapping issue
* Replied to comment and fixed the issues.
* Adding Text Input property to InputController
Changing the value of mdc_adjustsFontForContentSizeCategory should not effect the actual controller fonts that are set by user but only the properties of the actual textfield. In order to do that I moved the resizing of fonts away from the properties of InputController and into update layout.
* Fixing the comment. Changing font scheme to not accept nullable controllers.
* change documentation.
