Skip to content

MapboxDirections.swift, iOS SDK v3.4.2#44

Closed
1ec5 wants to merge 4 commits into
masterfrom
1ec5-directions-swift-carthage
Closed

MapboxDirections.swift, iOS SDK v3.4.2#44
1ec5 wants to merge 4 commits into
masterfrom
1ec5-directions-swift-carthage

Conversation

@1ec5
Copy link
Copy Markdown
Contributor

@1ec5 1ec5 commented Feb 21, 2017

Upgraded MapboxDirections.swift to a Carthage-powered commit on master. Upgraded Mapbox iOS SDK to v3.4.1.

/cc @frederoni

1ec5 added 2 commits February 21, 2017 09:41
Only ignore CocoaPods files inside Example/.
Upgraded MapboxDirections.swift to a Carthage-powered commit on master. Upgraded Mapbox iOS SDK to v3.4.1.
@1ec5 1ec5 self-assigned this Feb 21, 2017
@1ec5 1ec5 requested a review from bsudekum February 21, 2017 17:44
Fixed CocoaPods warnings about SWIFT_VERSION being overridden.
@frederoni
Copy link
Copy Markdown
Contributor

This is already happening in #43

@1ec5
Copy link
Copy Markdown
Contributor Author

1ec5 commented Feb 21, 2017

Builds are failing because SWIFT_VERSION is unspecified for the Polyline target in the example workspace’s Pods project. CocoaPods is pulling in Polyline via the dependency declared in MapboxDirections.swift.podspec. I don’t know why CocoaPods is failing to notice the .swift-version file there that specifies Swift 3. In mapbox/mapbox-directions-swift#102, we had no problem with a similar setup: a CocoaPods Podfile (for the DirectionsExample project) that depended on a podspec in an otherwise Carthage-managed repository (MapboxDirections.swift), which in turn depended on a podspec in an otherwise Carthage-managed repository (Polyline). So I’m stumped as to why builds are failing here.

@1ec5
Copy link
Copy Markdown
Contributor Author

1ec5 commented Feb 21, 2017

I suspect we got lucky in mapbox/mapbox-directions-swift#102. Over here, there’s actually one additional level: a Podfile that depends on three levels of Carthage projects’ podspecs (MapboxNavigation, MapboxDirections, Polyline). Since this setup doesn’t seem to have a hope of passing, we’re going to move all the examples over to Carthage in #43.

@1ec5 1ec5 closed this Feb 21, 2017
@1ec5 1ec5 deleted the 1ec5-directions-swift-carthage branch February 21, 2017 19:37
wishtrip-dev pushed a commit to wishtrip-dev/mapbox-navigation-ios that referenced this pull request Feb 28, 2018
Rewrote the library to more closely parallel mapbox/MapboxGeocoder.swift#41 and mapbox/MapboxStatic.swift#19. Removed the class prefix from Swift but kept it for Objective-C. The goal is no longer to be a (poor) drop-in replacement for MapKit’s MKDirections API but rather to be as idiomatic as possible in Swift and Objective-C, with a priority on Swift. Symbols conform to platform naming conventions but in some cases eschew MapKit terminology in favor of Geocoding API terminology, so that api-documentation makes sense in the context of this library.

Removed the dependency on RequestKit. This library chooses reasonable default networking behavior; if you need anything more sophisticated, you can access the URL request information to use with a custom NSURLSession. Directions no longer needs to be strongly held in order for the request to finish. Instead, the request is made against the shared URL session; to use a custom URL session, make the request yourself using the URL returned by the URLForCalculatingDirections(options:) method. Removed the cancel() method; instead, directly cancel the NSURLSessionDataTask returned by calculateDirections(options:completionHandler:).

Added a shared (singleton) Directions object. Use the shared object if you’ve set your Mapbox access token in the MGLMapboxAccessToken key of your application’s Info.plist file. Otherwise, create a Directions object with the access token explicitly. A single directions object can handle multiple requests concurrently (since it just passes the requests off to the shared URL session).

Eliminated the separate APIs for calculating ETAs. Instead, all the options supported by the Directions API, including flags for including steps and the overview geometry, are now exposed through a new RouteOptions class. Effectively, this change adds support for the geometries, overview, radiuses, steps, and continue_straight query parameters and allows the heading accuracy of any waypoint to be customized. However, note that steps are no longer returned by default, and the overview geometry is simplified by default. The access_token parameter is now the last URL parameter instead of the first. Broke out MBDirectionsRequest.TransportType into three profile identifier constants. You always specify a profile identifier, not a transport type. That makes the desired mode of transportation more open-ended.

Removed the MBDirectionsResponse class in favor of passing the waypoints and routes from the response directly into the completion handler. Renamed Route.geometry to Route.coordinates. For Objective-C compatibility, all enums are backed by integer types instead of String, but they’re CustomStringConvertible to allow for the same expressiveness we’re used to in Swift.

Error handling is much more robust now. Various error conditions returned by the API cause the localized failure reason and recovery suggestion to be set in the NSError object that is passed into the completion handler.

Updated test fixtures and expectations for the v5 server-side API and the revamped client-side API, and updated examples.

Fixes mapbox#41, fixes mapbox#43, fixes mapbox#44.
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