When a bar button item with a custom view is provided to the button bar, the custom view is used in place of an MDCButton instance. 6ec9f334f0e093e1d2bf04165895ca725455150e introduced a change that unconditionally called a UIButton API on the views when the tintColor was changed, resulting in a crash when a custom view was used.
This change adds a test that, prior to this fix in this change, crashed, but after the fix included in this change now passes.
Upon inspection of the culprit code, it was revealed that image and title similarly could result in crashes, so those crashes have been fixed as part of this change as well.
Closes https://github.com/material-components/material-components-ios/issues/9760
Prior to this change, UIBarButtonItem's tintColor property would not change the title color of the corresponding button. This differs from the UIKit behavior, which does result in the title color being changed.
After this change, changing a UIBarButtonItem's tintColor will result in the corresponding button's title color being updated as well.
PiperOrigin-RevId: 293848033
Prior to this change, UIBarButtonItem's tintColor property would not change the title color of the corresponding button. This differs from the UIKit behavior, which does result in the title color being changed.
After this change, changing a UIBarButtonItem's tintColor will result in the corresponding button's title color being updated as well.
PiperOrigin-RevId: 293583337
The `titleFontForState:` API did not correctly reflect the rendered font
when no explicit fonts were set via the MDCButton APIs. As a result,
calling `updateTitleFont` internally could result in a different font
being returned than what was displayed.
Moving the "fall back" and Dynamic Type behavior into the
`titleFontForState:` method allows more consistent behavior (reduces the
risk of deviations) and corrects the APIs to reflect what is rendered.
This change should result in no visible changes to clients (the rendered
fonts should remain the same), but will result in non-`nil` results
being returned from `titleFontForState:` to correctly reflect the
rendered font for a given state.
Part of #7492
This API will allow clients to present overlay views that point to views in an MDCButtonBar.
Expected usage:
```swift
@objc func didTapButton(_ item: UIBarButtonItem) {
let rect = buttonBar.rect(for: item, in: view)
// Present an overlay pointing at `rect`
}
```
Closes https://github.com/material-components/material-components-ios/issues/7248
This PR graduates ContainerScheme to ready.
This includes updating the podspecs, podfile, all the import statements related to ContainerScheme, updating .kokoro rewrite rules, and finally the readme to not have ContainerScheme regarded to as being in beta.
Ran locally kokoro with -b bazel successfully.
Resolves#6732
Sets up MDC iOS to allow each component to export "Test fakes" and test data for use by other components when performing tests. The initial commit includes "test data" for MDCTypographyScheme that uses non-default values for each UIFont.
Contributors writing tests, particularly those that use shared components like schemes, can do so more quickly by accessing test data and test fakes directly from the component rather than having to write custom objects for each test.
**Bonus**
The new typography data has already confirmed the Dialogs bug #6637, which would have been discovered sooner if we didn't rely on the typographic defaults that already matched component defaults.
## Typical Usage
### Build/dependency management systems
**bazel BUILD files:**
```
deps = [
"//components/schemes/Typography:TestingSupport",
],
```
**CocoaPods Podspec files:**
```ruby
component.dependency "MaterialComponentsTestingSupport/schemes/Typography"
```
### Source includes
**Swift**
```swift
import MaterialComponentsTestingSupport.MaterialTypographyScheme_TestingSupport
```
**Objective-C**
```objc
#import <MaterialComponentsTestingSupporrt/MaterialTypographyScheme+TestingSupport.h>
```
# Original PR description:
On Cocoapods version 1.6.0 beta 2 we get an error on pod install because certain test targets don't have any sources to compile. This PR adds some skeleton unit test source files to get that working. Is everyone okay with these (for now) basically empty files?
Closes#5825
# FInal PR description:
The original aim of this PR was to get the project working with the Cocoapods 1.6 beta.
I initially didn't know where to begin getting it to work, so I used `pod lib lint` to get answers. `pod lib lint` had issues with the following things:
1. test_specs not having any sources to compile. This was due to our pattern of putting unit test test_specs inside of parent test_specs that didn't have anything else.
To address this I did two things. First, I moved away from the nested test_spec pattern. Now, instead of "Subspec/tests/unit_tests" it's "Subspec/UnitTests". This is more in line with the style Cocoapods uses [here](http://blog.cocoapods.org/CocoaPods-1.6.0-beta/). Secondly, I added some dummy files for things like UIMetrics and MaterialMath.
2. Importing headers across modules without using framework style imports.
I added framework style imports. This required some additional rewrite rules in the kokoro script.
3. Dependencies across subspecs being implicit.
I made them explicit by adding dependency statements to the podspecs where needed.
`pod lib lint` didn't take issue with this, but I also saw that `MaterialComponents` was depending on `MaterialComponentsBeta` in various places. For example, all the theming extensions were in beta, but the tests for them weren't. I moved the tests to test_specs within the beta extensions. This required some directory structure changes. These changes then required some BUILD file changes. Making BUILD file changes made me realize that some swift unit tests weren't being accounted for by bazel. I took care of this too.
This PR also fixes some swift debugging stuff--"po" statements that weren't working before now do. I didn't rigorously verify this, but I also think this PR will lead to faster clean build times? It kinda seemed like it was while I was working on it.
This is an automated change generated by replacing all instances of MaterialComponentsAlpha with MaterialComponentsBeta. This is not a breaking change because changes to Alpha/Beta components (including renaming them) are not considered breaking.
The MaterialComponentsAlpha podspec was mistakenly named Alpha, when what we meant was more close to Beta. The distinction is that Alpha components are not expected to be used by clients, while Beta components are.
This change makes use of MDCContainerScheme to provide a single theming-related API for ButtonBar.
Includes example updates unit tests.
This change is the first in a series of changes that will be required to add Theming extension support to AppBar:
- [x] ButtonBar
- [ ] NavigationBar
- [ ] HeaderStackView
- [ ] FlexibleHeader
- [ ] AppBar
This will allow the owner of a button bar to react to changes in the button bar's intrinsic size.
We need to add this delegate because I'm not aware of an equivalent UIKit mechanism that works with views that aren't using auto layout (the MDCNavigationBar uses manual layout).
In a follow-up change, MDCNavigationBar will implement this delegate and update the layout of its left/right button bars as a result.
Part of https://github.com/material-components/material-components-ios/issues/1717
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.
```
Button frames need to be updated after the font changes because their frames are not dynamically updated in any layoutSubviews pass.
It may be sensible to update layoutSubviews to do the frame calculations in a follow-up change, but this has the potential to be a behaviorally-breaking change so I've filed a follow-up story: https://www.pivotaltracker.com/story/show/156930078
