-
Notifications
You must be signed in to change notification settings - Fork 944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Buttons] Implement a color themer for an MDCFlatButton #3308
[Buttons] Implement a color themer for an MDCFlatButton #3308
Conversation
…ents-ios into flatButtonTheming
…ents-ios into flatButtonTheming
@@ -30,6 +30,14 @@ | |||
+ (void)applySemanticColorScheme:(nonnull id<MDCColorScheming>)colorScheme | |||
toButton:(nonnull MDCButton *)button; | |||
|
|||
/** | |||
Applies a color scheme to theme to a MDCFlatButton. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super-nit: Should be "an MDCFlatButton". Please don't fix unless you have other changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated and also other "a" -> "an" in the rest of the header for consistency.
/** | ||
Applies a color scheme to theme to a MDCFlatButton. | ||
|
||
@param colorScheme The color scheme to apply to MDCFlatButton. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Should be, "... to apply to @c flatButton." (referencing the other parameter).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated, and rest of header to comply with this.
Applies a color scheme to theme to a MDCFlatButton. | ||
|
||
@param colorScheme The color scheme to apply to MDCFlatButton. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LINT: Missing param for flatButton
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, updated
[flatButton setBackgroundColor:[colorScheme.primaryColor colorWithAlphaComponent:0.f] | ||
forState:UIControlStateHighlighted]; | ||
[flatButton setBackgroundColor:[colorScheme.primaryColor colorWithAlphaComponent:0.f] | ||
forState:UIControlStateSelected]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, but why use "primaryColor" with alpha 0 instead of UIColor.clearColor
or nil
? Also, can you not depend on the "fallback" behavior for the background color and only set the UIControlStateNormal
value? I'm curious about the result if another class sets a combination of the states (since they are an NSOption), like UIControlStateSelected | UIControlStateHighlighted
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 that these should likely just be clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, can you not depend on the "fallback" behavior for the background color and only set the UIControlStateNormal value?
There's some nuance here. I think the expectation of our themers is that they enforce a particular theme on a component. If someone else had modified any of these states prior to us applying the theme then presumably we'd want to blow away those modifications. This unfortunately may mean we have to iterate over every state combination...but I'm really unhappy about that as a solution as well. What do y'all think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to rely on fallback behavior - I think most clients will expect that. UIKit tends to document that same expectation. It's often worded like, "at a minimum set the title for the .normal
state." If we are going to pick out specific states (like .disabled
), there should be a difference between that state and .normal
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same approach in terms of the background color, but I wanted to follow the params doc guidelines and there they stated primaryColor + opacity of 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the reason I set all the states is because if a client changed the color of a state prior to the theming, the theming wont override that color to its rightful theming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The params doc unfortunately doesn't have any awareness of a "clear" color, so they specify colors in terms of color + opacity. This isn't a color that is intended to be mapped by the color system because the opacity is always going to be 0, so for our purposes I believe it's sufficient to use clearColor
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sgtm, will update accordingly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So should all of the states be added to the map instead of nilling-out and relying on the fallback? I'm curious because this affects how I write a lot of component/themer code in general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after speaking to both, have moved to a fallback to .normal approach with .normal and .disabled set in the themer.
XCTAssert( | ||
CGColorEqualToColor([button backgroundColorForState:UIControlStateDisabled].CGColor, | ||
[colorScheme.primaryColor colorWithAlphaComponent:0.f].CGColor)); | ||
XCTAssertEqual(button.disabledAlpha, 1.f); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use XCTAssertEqualWithAccuracy
for floating point comparison.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -43,6 +43,8 @@ - (MDCButton *)buildCustomStrokedButton { | |||
- (void)viewDidLoad { | |||
[super viewDidLoad]; | |||
|
|||
id<MDCColorScheming> colorScheme = [[MDCSemanticColorScheme alloc] init]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I typically expect protocols in the context of interfaces, methods and delegate.
It seems strange to have it as the sole reference to a concrete object.
Consider changing to:
MDCSemanticColorScheme *colorScheme = [[MDCSemanticColorScheme alloc] init];
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
[flatButton setTitleColor:colorScheme.primaryColor forState:UIControlStateNormal]; | ||
[flatButton setTitleColor:[colorScheme.onSurfaceColor colorWithAlphaComponent:0.26f] | ||
forState:UIControlStateDisabled]; | ||
flatButton.disabledAlpha = 1.f; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest two parts:
- Set only those states set by the target class. Nilling-out anything that should fall-back to
.normal
- Write unit tests to verify the behavior of all possible states.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated :) PTAL
Addition of a unit test, and updated example to use the new themer.
Pivotal: https://www.pivotaltracker.com/story/show/156640819