-
Notifications
You must be signed in to change notification settings - Fork 310
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
[Feedback][Part 1] Updates FeedbackType
and introduces FeedbackSubType
#2419
[Feedback][Part 1] Updates FeedbackType
and introduces FeedbackSubType
#2419
Conversation
FeedbackType
and introduces FeedbackSubType
sFeedbackType
and introduces FeedbackSubType
s
FeedbackType
and introduces FeedbackSubType
sFeedbackType
and introduces FeedbackSubType
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.
Since some of these enumerations and such are publicly documented, remember to mention any changes we end up making in the changelog.
Also delete the existing feedback icons from the asset catalog (except for “feedback”, which is for the feedback button).
MapboxCoreNavigation/Feedback.swift
Outdated
/// Indicates an incorrect visual artifact. | ||
case incorrectVisual |
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 think this category is intended to include things like incorrect visual instructions, not just artifacts. But what we have from the specification is a really weird category name. Not sure if there’s a better thing to call it, at least programmatically where the specification doesn’t care what it’s called.
/cc @JunDai @abhishek1508
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've amended the comment for now. Once this lands on a decision, I'll come back and update this.
MapboxCoreNavigation/Feedback.swift
Outdated
} | ||
|
||
/// Returns a corresponding list of `FeedbackSubType`s for a given `FeedbackType` | ||
public var subtypes: [FeedbackSubType] { |
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.
FeedbackSubType is a separate enumeration that contains all the subtypes of all the types, undifferentiated. That means it’s possible for the developer to set a type of confusingAudio
but a subtype of routedDownAOneWay
, which would be an error on the server side. I think we’ll need either a separate enumeration of subtypes for each type, with each type case having an associated value for its subtype, or roll the whole shebang into a single enumeration, so that turnIconIncorrect
would live alongside incorrectVisual
in the same enumeration. I’m leaning towards the associated value approach because it enforces better type safety, but it would create some syntactic overhead in any situation where we need to process the feedback type.
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.
Gotcha, i didn't realize that developers would override this subtypes
field themselves. But it's a fair point. I'll move over to using the bespoke subtype enums for each top-level category.
|
||
public extension FeedbackType { | ||
|
||
// TODO: Localize these strings |
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.
To localize these strings, wrap each one in an NSLocalizedString(_:bundle:value:comment:)
, as with the original strings that are being deleted, then run scripts/extract_localizable.sh to update all the Localizable.strings files.
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.
Will be handling in this in a follow up PR.
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.
Flagged this as action item as part of #2429
"properties" : { | ||
"preserves-vector-representation" : true | ||
} |
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.
In the asset catalog, change “Render As” to from “Original Image” to “Template Image” so that the icons will adopt the application’s tint color automatically.
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.
The tint color has always been set to clear, bizarrely enough:
cell.imageView.tintColor = .clear |
I think we can simply remove that line; the view controller will inherit the application’s tint color.
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.
Added a note in the description of #2429 to handle this issue.
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 problem is that the glyphs within the circles are white instead of transparent. We’ll need to make them transparent so that the template image will show up correctly.
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.
#2433 tracks tail work around tint colors.
Addressed this is in a separate PR #2421 |
@1ec5 , I've made the changes we discussed in #2419 (comment) . Would love a review! |
/// Enum used to define the many `FeedbackSubType`s that may be nested under a given `FeedbackType` | ||
public enum FeedbackSubType: String { | ||
/// Incorrect Visual Subtypes | ||
/// Enum denoting the subtypes of the `Incorrect Visual` top-level category |
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 way jazzy should automatically link the symbol:
/// Enum denoting the subtypes of the `Incorrect Visual` top-level category | |
/// Enum denoting the subtypes of `FeedbackType.incorrectVisual(subtype:)`. |
(Ditto for the other enumerations.)
MapboxCoreNavigation/Feedback.swift
Outdated
/// Incorrect Visual Subtypes | ||
/// Enum denoting the subtypes of the `Incorrect Visual` top-level category | ||
public enum IncorrectVisualSubtype: String { | ||
case none |
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.
Instead of an explicit none
subtype, make the associated value optional when declaring the FeedbackType
case:
case incorrectVisual(subtype: IncorrectVisualSubtype?)
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'd considered this, but the call site looked a little weird ( .incorrectVisual(subtype: nil)
for example) to me. But i'm not strongly against this approach.
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.
If it looks too weird, we can make the argument optional with a default value of nil
.
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.
Addressed.
public enum FeedbackSubType: String { | ||
/// Incorrect Visual Subtypes | ||
/// Enum denoting the subtypes of the `Incorrect Visual` top-level category | ||
public enum IncorrectVisualSubtype: String { |
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.
To avoid cluttering the main namespace, consider moving these enumerations inside of FeedbackType
, so that it’s possible to refer to them as e.g. FeedbackType.IncorrectVisualSubtype
.
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've made more changes to the FeedbackType
enum and the subtype enums in #2429 . It would be easier to do this in that PR. I'll add a note.
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.
Added a note in description of #2429
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.
/// Generates a `FeedbackItem` for a given `FeedbackType` | ||
/// - Returns: A `FeedbackItem` model object used to render UI | ||
func generateFeedbackItem() -> FeedbackItem { | ||
return FeedbackItem(title: self.title, image: self.image, feedbackType: self) | ||
} |
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 would be a little cleaner as an initializer on FeedbackItem.
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!
5f14c24
to
e4662f7
Compare
|
This diff updates the various categories in the
FeedbackType
enum and introduces infrastructural models ( viz.FeedbackSubType
) to build a granular feedback workflow.