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

Make RouteOptions available on route response #122

Merged
merged 3 commits into from
Apr 13, 2017
Merged

Conversation

bsudekum
Copy link

Instead of returning the profile identifier on the route, this replaces it with the entire RouteOptions used to create the directions request.

/cc @frederoni @1ec5

@bsudekum bsudekum requested review from frederoni and 1ec5 April 13, 2017 16:44
@@ -26,12 +26,12 @@ open class Route: NSObject, NSSecureCoding {
- parameter waypoints: An array of waypoints that the route visits in chronological order.
- parameter profileIdentifier: The profile identifier used to request the routes.
Copy link
Contributor

Choose a reason for hiding this comment

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

This parameter has been replaced by routeOptions.

@@ -156,18 +156,16 @@ open class Route: NSObject, NSSecureCoding {
open let expectedTravelTime: TimeInterval

/**
A string specifying the primary mode of transportation for the route.

The value of this property is `MBDirectionsProfileIdentifierAutomobile`, `MBDirectionsProfileIdentifierAutomobileAvoidingTraffic`, `MBDirectionsProfileIdentifierCycling`, or `MBDirectionsProfileIdentifierWalking`, depending on the `profileIdentifier` property of the original `RouteOptions` object. This property reflects the primary mode of transportation used for the route. Individual steps along the route might use different modes of transportation as necessary.
Copy link
Contributor

Choose a reason for hiding this comment

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

Developers may not be aware of this nuance, so we might want to leave it in:

The route options object’s profileIdentifier property reflects the primary mode of transportation used for the route. Individual steps along the route might use different modes of transportation as necessary.

XCTAssertTrue(opts.includesSteps)
XCTAssertTrue(opts.includesAlternativeRoutes)
XCTAssertEqual(opts.routeShapeResolution, .full)

XCTAssertNotNil(route)
Copy link
Contributor

Choose a reason for hiding this comment

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

Move this assertion up above any assertions that depend on route being non-nil.

@@ -52,6 +52,13 @@ class V5Tests: XCTestCase {
XCTAssertEqual(task.state, .completed)
}

let opts = route!.routeOptions

XCTAssertEqual(opts.profileIdentifier, .automobile)
Copy link
Contributor

Choose a reason for hiding this comment

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

Might as well assert that route!.routeOptions is equal to options. That way we can be sure they’re literally the same object; no need to compare individual properties on them.

@bsudekum bsudekum merged commit 615be18 into master Apr 13, 2017
@bsudekum bsudekum deleted the routeoptions branch April 13, 2017 17:35
@1ec5 1ec5 added the backwards incompatible changes that break backwards compatibility of public API label Dec 18, 2018
@1ec5 1ec5 added this to the v0.9.0 milestone Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards incompatible changes that break backwards compatibility of public API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants