Skip to content
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

Merged

Conversation

nishant-karajgikar
Copy link
Contributor

@nishant-karajgikar nishant-karajgikar commented Jun 24, 2020

This diff updates the various categories in the FeedbackType enum and introduces infrastructural models ( viz. FeedbackSubType) to build a granular feedback workflow.

Simulator Screen Shot - iPhone 8 Plus - 2020-06-24 at 16 35 31

@nishant-karajgikar nishant-karajgikar changed the title Updates FeedbackType and introduces FeedbackSubTypes [Feedback][Part 1]Updates FeedbackType and introduces FeedbackSubTypes Jun 24, 2020
@nishant-karajgikar nishant-karajgikar changed the title [Feedback][Part 1]Updates FeedbackType and introduces FeedbackSubTypes [Feedback][Part 1] Updates FeedbackType and introduces FeedbackSubType Jun 24, 2020
@nishant-karajgikar nishant-karajgikar self-assigned this Jun 24, 2020
Copy link
Contributor

@1ec5 1ec5 left a 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).

Comment on lines 12 to 13
/// Indicates an incorrect visual artifact.
case incorrectVisual
Copy link
Contributor

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

Copy link
Contributor Author

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.

}

/// Returns a corresponding list of `FeedbackSubType`s for a given `FeedbackType`
public var subtypes: [FeedbackSubType] {
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Comment on lines +13 to +15
"properties" : {
"preserves-vector-representation" : true
}
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, If i do this the icons seem to disappear. Example:

Simulator Screen Shot - iPhone 8 Plus - 2020-06-24 at 22 20 39

(I've left Route Preview as default in order to show the difference)

Copy link
Contributor

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:

I think we can simply remove that line; the view controller will inherit the application’s tint color.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, i think these images aren't imported correctly as template images. I see this if I remove that line and make the change to "Render as: template":

Simulator Screen Shot - iPhone SE (2nd generation) - 2020-06-29 at 10 50 56

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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.

@nishant-karajgikar
Copy link
Contributor Author

Also delete the existing feedback icons from the asset catalog (except for “feedback”, which is for the feedback button).

Addressed this is in a separate PR #2421

@nishant-karajgikar
Copy link
Contributor Author

@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
Copy link
Contributor

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:

Suggested change
/// Enum denoting the subtypes of the `Incorrect Visual` top-level category
/// Enum denoting the subtypes of `FeedbackType.incorrectVisual(subtype:)`.

(Ditto for the other enumerations.)

/// Incorrect Visual Subtypes
/// Enum denoting the subtypes of the `Incorrect Visual` top-level category
public enum IncorrectVisualSubtype: String {
case none
Copy link
Contributor

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?)

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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 {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

MapboxCoreNavigation/Feedback.swift Show resolved Hide resolved
Copy link
Contributor

@1ec5 1ec5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes look good overall. #2420, #2421, and #2429 continue the work on this feature. #2433 tracks correcting the appearance of the feedback icons.

Remember to update the changelog to note any public API changes.

Comment on lines +54 to +58
/// 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)
}
Copy link
Contributor

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.

Copy link
Contributor

@1ec5 1ec5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@nishant-karajgikar nishant-karajgikar changed the base branch from master to release-v1.0-pre-registry July 1, 2020 20:40
@1ec5
Copy link
Contributor

1ec5 commented Jul 2, 2020

CarPlayManagerTests.testManagerTellsDelegateWhenNavigationStartsAndEndsDueToArrival() seems to be crashing intermittently. Not immediately actionable here but something to watch out for going forward as we upgrade MapboxNavigationNative further.

@1ec5 1ec5 added this to the v1.0.0 milestone Jul 2, 2020
@nishant-karajgikar nishant-karajgikar merged commit 1873c47 into release-v1.0-pre-registry Jul 2, 2020
@nishant-karajgikar nishant-karajgikar deleted the nishantk/feedbackOverhaul branch July 2, 2020 17:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants