-
Notifications
You must be signed in to change notification settings - Fork 314
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
[Guidance Cards][Part 1] Making Guidance Cards controls stylable #2401
Conversation
cecfd88
to
c47b8e8
Compare
This CI failure seems to be an unrelated bug - #2394 |
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.
This generally looks good to me. I can't check it out with Apex at the moment due to version conflicts with all the changes to MapboxDirections & MapboxNavigation, but I will try it as soon as I can.
For now, I would ask if testing has been done to verify that setting a custom value for these colors does indeed change them, and if the rendering responds correctly to Dark/Light mode changes for color assets. If those have been checked then I am ok with this being merged.
@@ -66,6 +66,9 @@ public class InstructionsCardContainerView: UIView { | |||
private var secondaryChildren: [UIView] { | |||
return [lanesView, nextBannerView] | |||
} | |||
|
|||
@objc dynamic public var customBackgroundColor: UIColor = #colorLiteral(red: 1.0, green: 1.0, blue: 1.0, alpha: 1.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.
What is this customBackgroundColor used for?
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 previous InstructionsCardStyle protocol called this option backgroundColor
; it controlled the normal background of an unhighlighted card. Did we end up calling it something different to avoid dealing with property overloading in a subclass? I’m not sure this property works; setGradientLayer(for:)
still calls backgroundColor
on the style:
let backgroundColor = style.backgroundColor |
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.
Ah, never mind, #2402 takes care of using customBackgroundColor
. If overloading backgroundColor
is a problem, then I think normalBackgroundColor
would be more intuitive in conjunction with the other highlightedBackgroundColor
property.
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.
#2402 has been merged into this PR, so the property is now used. I think it would be great if we could take care of renaming the property to normalBackgroundColor
before merging.
c47b8e8
to
d0536ea
Compare
@@ -66,6 +66,9 @@ public class InstructionsCardContainerView: UIView { | |||
private var secondaryChildren: [UIView] { | |||
return [lanesView, nextBannerView] | |||
} | |||
|
|||
@objc dynamic public var customBackgroundColor: UIColor = #colorLiteral(red: 1.0, green: 1.0, blue: 1.0, alpha: 1.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.
The previous InstructionsCardStyle protocol called this option backgroundColor
; it controlled the normal background of an unhighlighted card. Did we end up calling it something different to avoid dealing with property overloading in a subclass? I’m not sure this property works; setGradientLayer(for:)
still calls backgroundColor
on the style:
let backgroundColor = style.backgroundColor |
@@ -47,7 +47,7 @@ public extension InstructionsCardContainerViewDelegate { | |||
} | |||
|
|||
/// :nodoc: |
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.
We’re going to need documentation for this class and its properties as we turn guidance cards into an officially supported feature.
…nce Card styling.
…13.5 since iPhone 6 Plus is not supported in that OS but we test for it in CI.
…arance proxy based styling of Guidance Cards.
[Guidance Cards][Part 4] Remove InstructionsCardStyle class
[Guidance Cards][Part 2]Defer to UIAppearance proxy for color/font literals
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.
Looks good, other than renaming customBackgroundColor
to normalBackgroundColor
. We’ll also need to track removing the :nodoc:
s and formally documenting the new API as tail work.
@@ -66,6 +66,9 @@ public class InstructionsCardContainerView: UIView { | |||
private var secondaryChildren: [UIView] { | |||
return [lanesView, nextBannerView] | |||
} | |||
|
|||
@objc dynamic public var customBackgroundColor: UIColor = #colorLiteral(red: 1.0, green: 1.0, blue: 1.0, alpha: 1.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.
#2402 has been merged into this PR, so the property is now used. I think it would be great if we could take care of renaming the property to normalBackgroundColor
before merging.
This PR begins adding support for styling the various labels, controls and views in the guidance card framework.
It does NOT hook up this new styling logic to the Guidance Cards framework (yet). That will be tackled in a follow up PR.
Because guidance cards are highlight-able, this PR adds highlight states to the various labels/controls.