-
Notifications
You must be signed in to change notification settings - Fork 89
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
Improve route response decoding. #446
Conversation
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.
Suggested changelog entry:
- Fixed an issue where waypoints in a
RouteResponse
did not persist theWaypoint.targetCoordinate
,Waypoint.heading
,Waypoint.headingAccuracy
, andWaypoint.allowsArrivingOnOppositeSide
properties from the initialRouteOptions
object.
} | ||
|
||
return "" | ||
}).joined(separator: "\n") |
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.
Not bad. What do you think about further customizing the Quick Look implementation of this type to show the target coordinate when present instead of the main coordinate?
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.
Interestingly debugQuickLookObject
doesn't work for me in Swift, when using Objective-C it works as expected. Will add targetCoordinate ?? coordinate
though.
waypoint.separatesLegs = waypointInOptions.separatesLegs | ||
waypoint.allowsArrivingOnOppositeSide = waypointInOptions.allowsArrivingOnOppositeSide |
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.
Aside from the tests below, what would be a good way to prevent a future option from getting overlooked this way? How about copying the waypointInOptions and overwriting the fewer properties that are available in the decodedWaypoint. This could be good fodder for tail work; not essential for this 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.
Then again, #388 would make a finer distinction between a requested waypoint and a received waypoint, such that the developer would be responsible for keeping track of the requested waypoints’ details separately, mirroring the API response format. But until that change lands someday, this is a good change to have for consistency.
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 was thinking about using a copy of waypointInOptions
and assigning only minimum number of essential properties, but public let coordinate: CLLocationCoordinate2D
prevents me from assigning it from decodedWaypoint
. I'm not sure why coordinate is declared as let
whereas others use var
, but if that's okay to make coordinate var as well it'd make it possible.
Closing #445.