* Adds variable height to Snackbars (up to 50% of screen height).
* Adds support for scrolling content when content is too large to fit in the available height.
PiperOrigin-RevId: 395705280
Context
-------
Prior to this PR we were unable to build our Swift source code as part of the Bazel toolchain because our source supports CocoaPods-style framework imports out of the box. E.g.:
```swift
import MaterialComponents.MaterialAppBar
```
Supporting CocoaPods imports enables us to use a pure open source workflow with our code that ensures we're using and validating the latest community technologies (including CocoaPods and native Xcode build systems). Changing our source to Bazel-first was explored as an option for this PR, but was rejected in service to maintaining our CocoaPods support.
The way we solved this import problem before this PR was to perform a global rewrite of import statements prior to invoking any `bazel` commands. This rewrite phase happened as part of the `.kokoro` script. This meant that the only way to run `bazel` commands on our repo was through the `.kokoro` bootstrap script.
This change does not yet entirely remove our need for the `.kokoro` bootstrap script, but it does remove the need for it to rewrite Swift imports. This change is one part of #5491.
The change
----------
This change introduces a new drop-in replacement for swift_library called `_mdc_cocoapods_compatible_swift_library` (for private use within the `material_components_ios.bzl` file) and `mdc_swift_library` for use in all BUILD files. `_mdc_cocoapods_compatible_swift_library` is made use of by several `mdc_` rules, including the new `mdc_swift_library` rule which should now be used instead of `swift_library` throughout our repo.
The new rule's implementation is documented in the source.
The impact
----------
Prior to this change, running the following command:
```
bazel build //components/Typography:SwiftExamples
```
Would result in the following error:
```
components/Typography/examples/TypographyFontListExample.swift:15:8: error: no such module 'MaterialComponents.MaterialTypography'
import MaterialComponents.MaterialTypography
```
After this change, running that same command will give the following successful result:
```
INFO: Invocation ID: 324c8887-d733-42ce-be06-20d9823bf718
INFO: Build options have changed, discarding analysis cache.
INFO: Analysed target //components/Typography:SwiftExamples (3 packages loaded, 365 targets configured).
INFO: Found 1 target...
Target //components/Typography:SwiftExamples up-to-date:
bazel-bin/components/Typography/libSwiftExamples.a
bazel-bin/components/Typography/components_Typography_SwiftExamples.swiftdoc
bazel-bin/components/Typography/components_Typography_SwiftExamples.swiftmodule
INFO: Elapsed time: 4.299s, Critical Path: 4.01s
INFO: 2 processes: 2 darwin-sandbox.
INFO: Build completed successfully, 3 total actions
```
Note that as a result of this change, build output for the transformed src will point to the generated source files rather than the original source files. E.g.:
```
ERROR: /Users/featherless/workbench/material-components-ios/components/Typography/BUILD:55:1: SwiftCompile components/Typography/components_Typography_SwiftExamples.swiftmodule failed (Exit 1) bazel_xcode_wrapper failed: error executing command bazel-out/host/bin/external/build_bazel_rules_swift/tools/wrappers/bazel_xcode_wrapper bazel-out/host/bin/external/build_bazel_rules_swift/tools/wrappers/swift_wrapper /usr/bin/xcrun swiftc ... (remaining 3 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
bazel-out/darwin-fastbuild/genfiles/components/Typography/examples/TypographyFontListExample.bazel_imports.swift:20:1: error: expressions are not allowed at the top level
typo
^
bazel-out/darwin-fastbuild/genfiles/components/Typography/examples/TypographyFontListExample.bazel_imports.swift:20:1: error: use of unresolved identifier 'typo'
typo
^~~~
```
This is the downside to this change, but it only materially impacts eng workflows if we start using Bazel to generate Xcode projects. As command line output, it's fairly straightforward to transform the path to the correct original source path. If we do someday move to a Bazel-generated Xcode project workflow, then we should also revisit our assumption that our source should support CocoaPods out of the box. As noted at the beginning of this PR, however, this consideration is deemed out of scope for this PR.
This PR adds initial support for multi-line helper and error text.
It is important to note that this support is **opt-in**. This means that you will only get multi-line support if you change the leadingUnderlineLabel to have numberOfLines = 0 (or > 1) and change the label's break mode to be word wrapping.
This is why the snapshots that didn't have a change in their testing setup (to have this setup), stayed unchanged.
There were 2 issues that surfaced when trying to deal with this:
1. The calculation of the bottom inset for the labels was always calculated as if there is only 1 line. So I needed to add a calculation for the amount of lines there actually were.
2. To calculate the number of lines we need to know the width of the textfield. Because the snapshot tests were using `sizeThatFits:size` to take the snapshot tests, but the intrinsicContentSize didn't get the width, it calculated as if the textfield's width is 0, which led to the number of lines calculation to be off. Therefore, when sizeThatFits is invoked, we capture the width hint set by sizeThatFits and pass it on to the underline label so it is aware on how wide it should be when calculating how much height to provide for the label.
Substantially eases the work needed for #2153Closes#5762
Adds a flow to get snapshot tests for iOS13.
Snapshot tests that want to be run on iOS13 can and should call `- (void)snapshotVerifyViewForIOS13:(UIView *)view`.
This flow makes it that we don't duplicate all our snapshot tests for another device, and allows only specific tests to run on iOS13.
This change splits out the implementation-specific files (required for
writing a Snapshot test case) from the supplemental files (conveniences
for making the test cases easier to write). This work is part of #7253.
Closes#7354
Adding multiple test image styles so snapshot tests can use different
image patterns rather than image sizes to determine if a rendered image
has changed.
Initially this PR was supposed to consist of a revert of #6619 (which reverted #6611) with some small tweaks to fix whatever was wrong in #6611. It turned into something else! I had a hard time figuring out a way to both run MDCDragons/MDCCatalog with ⌘R _and_ run snapshot tests within either of the two apps' schemes. The only way I was able to manage it was by abandoning our convention for podspecs (only for snapshot tests), which relies heavily on nested subspecs and test_specs. In its place, I wrote a probably not very idiomatic ruby module that aims to allow for all snapshot testing source files to funnel into a single unit test target but still give us some flexibility in how we configure snapshot tests on a per component basis.
Closes#6700.
Snapshot tests stopped running after https://github.com/material-components/material-components-ios/pull/6580. I think this PR fixes it.
Cocoapods 1.6.0 creates a selected "white lego" test target for each unit test `test_spec` in a podspec. However, it did not do so for our snapshot tests. Instead, it created a single unselectable `MaterialComponentSnapshotTests` build target with the red and white target icon.
I moved the snapshot testing related files like `MaterialSnapshot.h` to a regular `subspec`, as opposed to a `test_spec`. After this change, Cocoapods 1.6.0 created selected "white lego" snapshot testing targets, just like with the unit tests. I guess it's bad to have test_specs within subspecs that don't have any source files?
EDIT: What I described above was only the beginning. I had to do a lot more to get everything working. Because Cocoapods 1.6.0 makes each `test_spec` into its own test target I had to create additional Swift dummy files to evade the [-lswiftSwiftOnoneSupport](https://github.com/material-components/material-components-ios/blob/develop/components/Cards/tests/snapshot/Dummy.swift#L17) linker error that Rami discovered when first adding Snapshot testing. I also had to add these Swift files to BUILD files. We might be able to get rid of these if we only depend on `iOSSnapshotTestCase/Core` (which is the same thing as `iOSSnapshotTestCase` but without Swift support) and commit to writing only Obj-C snapshot tests.
I also had to add two Objective-C dummy source files at the top level of the `MaterialComponentsSnapshotTests` podspec, and to the `private/Snapshot` BUILD file. I don't know why these source files were required. I arrived at this after much trial and error, which is not ideal. I want to try to get rid of them if possible, but I think they should go in for now, just so we can get this stuff working again.
Lastly, I had to disable bitcode everywhere. For some reason, the fact that `iOSSnapshotTestCase` explicitly disables bitcode is now a problem for us, where it wasn't before. From what I read on various blog posts, if an app target's dependency explicitly disables bitcode, an app target cannot enable it. Again, I don't know why this is only now a problem. This change on my part is the result of reading linker error messages and taking their advice. Right now I'm just disabling it everywhere in the `post_install`. We might be able to get away with only disabling it in MDCDragons and MDCDragons and just committing that to version control. I plan to look into that after this gets merged in.
I'm hoping that some of the changes in this PR can be undone at a later date, preferably soon. There is a chance that only depending on `iOSSnapshotTestCase/Core` and removing our snapshot tests from the Dragons and Catalog schemes and putting them in their own app target _could_ go a long way towards doing this.
Closes#6609
Creating a BUILD file and public "Snapshot" target for clients to depend on.
The primary use of this target will be in material_components_ios.bzl to
generate snapshot build rules.
Closes#6230
Snapshot test targets built with bazel will require a test host. Rather
than compiling/launching the entire catalog, a simple test host can be
used. The test host has no actual functionality other than to respond to
UIApplicationDelegate.
Part of #6287
### Context
In working on #6137 I noticed snapshot test helpers were in the private directory but weren't in a _src_ folder. This doesn't align with any of our other components in the _private_ folder.
### The problem
Snapshot test helpers weren't in a _src_ folder.
### The fix
Move the files into _src_.
### Additional notes
I have removed the BUILD file as we will need to add a BUILD file to [ios-snapshot-test-case](https://github.com/uber/ios-snapshot-test-case) before we can add a BUILD file.
### Changes
With the addition of #6057 we now have a category with an improved API to add a background view to the view you wish to snapshot. This change migrates the existing snapshot tests to this new API and removes the old one.
### Bugs
Closes#5942
### The Problem
The current infrastructure for snapshot tests assumes the developer wants to embed their view with 10 points of padding on all sides but this won't always be the case.
### The Solution
Create a UIView category to handle adding the background view and additionally expose an API in the snapshot base class to optionally allow the developer to specify their own custom insets like so:
```objc
[self mdc_addBackgroundViewWithInsets:UIEdgeInsetsMake(10, 10, 10, 10)]
```
A follow-up PR will move our snapshot tests over to this new category.
### Bugs
Part of #5942
Some snapshot tests are flaky (which is a bug). Allow those tests to
allow some small percentage of pixels to change to eliminate the flake
while still detecting larger changes.
Caused by #5970
Instead of implicitly verifying the snapshotted view in the test class
`-tearDown` method, it is clearer to readers if each test explicitly
performs the verification.
Closes#5941
This change simplifies the way a developer would have to write a snapshot test. The logic to verify the view is in the tearDown and will enforce the developer to write the test correctly.
* Snapshot Testing Proof of Concept (#5754)
### The problem
We currently do not have UI tests on a component level. Integrating snapshot tests would allow us to have peace of mind with each PR that it isn't going to introduce any changes to the UI unless its intended to.
### The solution
* Integrate `ios-snapshot-test-case` pod to handle generating and diffing images of components.
* Integrate `git-lfs` to handle storage of the goldens.
This PR creates one test to showcase the ability to do snapshot tests. Upon merging this PR, you must install git-lfs in order to properly have the images pulled down. The 3 steps to do this:
1. `brew install git-lfs`
2. `git lfs install`
3. `git lfs pull`
Additionally, the golden is generated using an iOS 11 simulator at 2x scale so that the kokoro jobs are happy.
### Related bugs
Closes#5740
### Difference from #5754
**Note:** This is a re-revert of #5754 that aims to fix issues with Travis CI by ensuring the snapshot test only runs on a single iOS version. I've opened #5888 to expand on this in the future. A few things changed in the approach in this PR:
* We only run the snapshot test for iOS 11.2.0 until we can have an elegant solution for supporting multiple OS''s (see #5888)
* The snapshot tests now live in their own test target to avoid issues with having to require an App host for all tests.
* Additionally, a dummy swift file was required for compilation of this new test target (see https://forums.developer.apple.com/thread/88451 for context)
