Use Polyline dependency

[tmcw]

Just like MapboxDirections.swift, we should depend on the Polyline lib

[1ec5]

This will depend on restructuring the project to produce a dynamic framework (#2), much as we've done for MapboxDirections.swift and MapboxGeocoder.swift.

[1ec5]

This will be unblocked once #16 lands.

[tmcw]

#16 landed, can I grab?

[1ec5]

Be my guest!

[tmcw]

👍 waiting on raphaelmor/Polyline#27

[1ec5]

raphaelmor/Polyline#27 is merged and Polyline’s podspec has been bumped to 3.1.0, but CocoaPods’ central repository hasn’t been updated yet. Since the polyline functionality in this repository already works, we should wait until CocoaPods gets updated. Otherwise, downstream users will have to include a second line in their podfile to override the version that CocoaPods resolves the pod to.

[1ec5]

Polyline has been updated with support for all the platforms this library supports.

[incanus]

Counterargument: polyline encoding/decoding is so small and lightweight, we might be able to get away with just sourcing this internally. For example here is a port of our JS version that I did recently: https://gist.github.com/incanus/47737ead1b92ff12095070ca11c493d0

[tmcw]

I'm happy to vendor an existing Polyline lib, but hesitant to write one ourselves that doesn't have a separate bug tracker. The basic polyline algorithm looks simple, but in mapbox/polyline we've learned about a sneaky class of errors around the particular behavior of number handling in JavaScript - I'd expect similar tiny but significant problems from any new implementation in any language, and want to make sure we have a place to fix them once and for all if/when we find them.

[1ec5]

@incanus, are there any substantive differences between your implementation and the one in the Polyline pod?

[incanus]

No, my thinking was about brevity and about less dependencies (even if our own, external dependency, it’s still easier IMHO) but I don’t feel strongly. I would want tests, yes, to exercise what I have written better. You two know better than I if dependencies have been enough of a problem or not.

[1ec5]

Now that this project uses Carthage for dependency management and is written in Swift 3, it should be a lot more straightforward for this project to depend on Polyline v4.0 the way MapboxDirections.swift does.

[1ec5]

#53 introduces a dependency on Polyline. Of interest, one of the test fixtures had to be changed because of an encoding difference, but the classic Static API output remained unchanged.

[1ec5]

#53 needs some conflict resolution, but we’ll close this issue once that PR lands.