Definitions:
- Headless layer: a CALayer without a delegate.
- Mounted layer: a CALayer that has been flushed to the render server either via a runloop pump or via `[CATransaction flush]`.
Context:
MDCShadowLayer includes some logic for animating shadowPath changes alongside corresponding bounds animations. The intent is that, if `shadowPath` is changed then it attempts to inherit any animation traits from existing bounds-related animations, if they exist. This behavior was added in https://github.com/material-components/material-components-ios/pull/2523. This behavior enables changes to shadowPath (which are not animatable by UIView-based animations) to inherit existing UIView-based animations.
Prior to this change, only bounds.size would be inspected for this piggy-backing behavior. While this works for UIView-based animations, which decompose `.frame` and `.bounds` animations into `bounds.size` and `bounds.origin`, this does not work for headless layers which directly animate the `bounds` property. E.g. the following snippet would piggy back as expected:
```objc
[UIView animateWithDuration:0.1 animations:^{
someView.frame = CGRectMake(0, 0, 100, 50);
someView.layer.shadowPath = [UIBezierPath bezierPathWithRect:someView.bounds].CGPath;
}];
```
But the following would not:
```objc
[CATransaction begin];
[CATransaction setAnimationDuration:0.5];
shadowLayer.bounds = CGRectMake(0, 0, 100, 50);
shadowLayer.shadowPath = [UIBezierPath bezierPathWithRect:shadowLayer.bounds].CGPath;
[CATransaction commit];
```
After this change, MDCShadowLayer will check for animations to `bounds` as well, increasing the likelihood that the shadowPath is able to piggy-back existing animations.
This change is part of addressing https://github.com/material-components/material-components-ios/issues/8644
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.
We have had errors when generating the docs using jazzy specifically around components giving a fatal error around not finding imports when depending on other components. This is because each component for jazzy is isolated and on its own unless we provide the framework root. This caused our website generator to crash each time and fail to generate a new website.
This should resolve this problem.
QA=
Before the fix when running the website generator we got these errors:
```
/material-components-ios/components/BottomAppBar/src/MDCBottomAppBarView.h:17:9: fatal error: 'MaterialButtons.h' file not found
building site
building search index
^C/Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge/lexer.rb:458:in `load': Interrupt
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge/lexer.rb:458:in `load_lexer'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:50:in `block in <top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:49:in `each'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:49:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/jazzy_markdown.rb:2:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/jazzy_markdown.rb:2:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/doc.rb:7:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/doc.rb:7:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/config.rb:5:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/config.rb:5:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy.rb:1:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy.rb:1:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/bin/jazzy:13:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/bin/jazzy:13:in `<top (required)>'
from /usr/local/bin/jazzy:22:in `load'
from /usr/local/bin/jazzy:22:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `load'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `kernel_load'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:28:in `run'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:463:in `exec'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:27:in `dispatch'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:18:in `start'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/exe/bundle:30:in `block in <top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/exe/bundle:22:in `<top (required)>'
from /usr/local/bin/bundle:22:in `load'
from /usr/local/bin/bundle:22:in `<main>'
/material-components-site-generator/scripts/lib/reporter.js:36
throw e;
^
Error: Command failed: bundle exec jazzy --output "/material-components-site-generator/.stage/ios/catalog/bottomnavigation/api-docs/" --theme "/material-components-site-generator/ios-api-docs-src/theme" --head '/components' --use-safe-filenames
at checkExecSyncError (child_process.js:601:13)
at execSync (child_process.js:641:13)
at JazzyApiGenerator.build (/material-components-site-generator/scripts/lib/jazzy-api-generator.js:34:5)
at PlatformSite.generateApiDocs (/material-components-site-generator/scripts/lib/platform-site.js:212:17)
at platformSites.forEach (/material-components-site-generator/scripts/build:86:14)
at Array.forEach (<anonymous>)
at reporter.step (/material-components-site-generator/scripts/build:85:21)
at Reporter.step (/material-components-site-generator/scripts/lib/reporter.js:32:22)
at Object.<anonymous> (/material-components-site-generator/scripts/build:84:14)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
at startup (bootstrap_node.js:191:16)
at bootstrap_node.js:612:3
```
Now we no longer get fatal errors or crash when running the script.
This is the first part of the migration of moving the Shape libraries away from the private/ folder.
Tracking bug, progress and more details can be found here: #6494
"Because Shapes and ShapeLibrary have been used in production and are an integral part of the shape scheme and theming. Moreover, with to stop the confusion of clients that the library should not be imported as it is under private, we want to migrate the Shape libs to be under components/ instead of components/private.
The migration will be a 7 step migration to not break clients internally.
1. move the folders to the new directory.
2. Make the old component's BUILD and Podspec targets depend on the new component (and nothing else).
3. Delete all implementation files from the old component.
4. Replace the contents of the old component's headers with import statements to the new component's header. If the new component has headers that match the old component's, then the new component's headers will need to be named uniquely for a period of time to allow clients to migrate over.
5. Once all clients have migrated from the old component, delete the old component. This is a breaking change.
6. If you had to create temporary header names in the new component, then in a separate release add the new headers that you want the new component to use. Move the content of the old headers into the new headers and replace the old headers with an import of the new headers. Migrate clients to the desired headers.
7. Once all clients have moved off of the old headers, delete the old headers.
Passes bazel build and pod build locally.
This change was automatically generated by running a find replace of the following strings:
```
mdc_unit_test_suite(
mdc_unit_test_suite(
name = "unit_tests",
```
And then running buildifier to enforce style:
find . -name BUILD | xargs ~/buildifier
Kokoro's Bazel version has been increased from 0.11.0 to 0.20.0
As part of this change, the `.kokoro` bazel header rewrite phase's rewrites for MDF libraries has been made less generic because MDFInternationalization can now be imported using framework-style imports as expected. MDFTextAccessibility does not yet have this functionality, so we still need to rewrite it.
Version changes in the bazel workspace:
- bazelbuild/rules_apple has been increased from 0.3.0 to 0.9.0
- bazel_skylib has been increased from 0.2.0 to 0.6.0
- bazelbuild/rules_swift has been added at 0.4.0
- xctestrunner has been increased from 0.2.1 to 0.2.5
- material_internationalization_ios has been increased from v1.0.4 to v2.0.1
- material_text_accessibility_ios has been increased from fd570d71ae0124c75ad5af00e6b8b4b1668d5e40 to v2.0.0
- motion_interchange_objc has been increased from v1.6.0 to v2.0.0
- motion_animator_objc has been increased from v2.5.0 to v3.0.0
- motion_transitioning_objc has been increased from v5.0.0 to v6.0.0
- Swift version has been pinned to 3 for all swift libraries.
buildifier was ran on all affected build targets.
This unblocks https://github.com/material-components/material-components-ios/pull/5550.
This is an automated change generated by running the following command:
find . -name BUILD | xargs buildifier
buildifier can be installed from https://github.com/bazelbuild/buildtools
This change formats all of our BUILD files with the buildifier formatter in preparation for us having a BUILD format linter as part of our presubmits and so that we can cleanly run buildozer commands against the codebase.
Replacing all non-integral, single-precision floating point literals with double-precision values explicitly cast to CGFloat. For example, `0.1f` should become `(CGFloat)0.1`.
Regex used:
```
([0-9]*\.)([0-9]*?)([1-9]+)([0-9]*?)[fF]
```
PiperOrigin-RevId: 220683126
### Context
A client is wanting to animate the corner radius of a view that has a `MDCShadowLayer` backing layer. This currently doesn't render correctly. The work done in #5398 still does not support animating the corner radius. #5398 additionally doesn't animate the `shadowPath` property so it still won't work properly. We set the properties in the `CATransaction completionBlock` because this prevents the layer from snapping back to it's original state after the animation completes. If a client desires to use a `CATransaction` wrapper around this animation they can do so as outlined [here](https://developer.apple.com/documentation/quartzcore/catransaction).
### The problem
Animating corner radius changes in a CAAnimation don't render
### The fix
Add an API to allow clients to animate corner radius changes for MDCShadowLayer.
### Alternatives
1. Alternatives to adding a new API would be to have the a client use our private API which isn't desirable and not future proof as discussed in #5566.
2. Add an API `- (CAGroupAnimation *)animateCornerRadius:(CGFloat)cornerRadius;` that would return all 5 of the animations and clients could set the duration and timingFunction themselves but this doesn't allow for the layers to stay animated after completion. If we want the layer to be animated after completion we could use `kCAFillModeForwards` and `removeOnCompletion = NO` but that would prevent use from animating back to the original state.
### Videos
| Before | After |
| - | - |
|||
| Alternative 2 | Without corner radius |
| - | - |
|||
### Bugs remaining
1. Set the MDShadowLayer cornerRadius to 0.
2. Call the new API with a duration of 5 seconds and a cornerRadius of 10.
3. Before that animation completes call the API again with a cornerRadius of 0.
#### Expected behavior
The first animation would complete and then the second animation would start.
#### Actual behavior
The animation jumps to 10 and then animates back to 0.
**_note_** This could be avoided if we added a property `BOOL` called `_isAnimating` and if that is set to `YES` then we would stash the next animation. This isn't added because most animations will be too fast for a user to tap that fast.
### Tested
cl/219964460
<h3>
```diff
- Warning - This has been attempted 3 times
```
</h3>
### Context
Clients may want to set the corner radius of a UIView that they have overridden the layerClass on to use MDCShadowLayer. Currently if the shadow layer's corner radius changes those changes are not rendered (see Shadow Corner Radius example in MDCDragons). This has been attempted in [this PR](https://github.com/material-components/material-components-ios/pull/4921) and [this PR](https://github.com/material-components/material-components-ios/pull/5224) both had to be rolled back. This is a similar change to #4921 except this change does NOT mark `shadowPathIsInvalid` or call `setNeedsLayout`. This differs from #5224 in that it doesn't set the `shadowPath`'s for the sublayers or set `shadowPathIsInvalid`.
### The problem
Corner radius changes aren't rendered when using MDCShadowLayer.
### The fix
Set the corner radius on the layer and sublayers and update the mask for the sublayers.
### Additional notes
A global presubmit has been run and succeeded.
Internal CL to test: cl/216562497
### Alternatives
@andrewoverton Suggest
```objectivec
-(void)setCornerRadius:(CGFloat)cornerRadius {
[super setCornerRadius:cornerRadius];
[self layoutSublayers];
}
```
### Videos
| Before | After |
| - | - |
|||
