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

Factor out code common to Mapbox Swift libraries #1

Closed
1ec5 opened this issue Dec 9, 2016 · 2 comments
Closed

Factor out code common to Mapbox Swift libraries #1

1ec5 opened this issue Dec 9, 2016 · 2 comments

Comments

@1ec5
Copy link
Contributor

1ec5 commented Dec 9, 2016

mapbox/MapboxGeocoder.swift#91 (comment) suggests factoring out a core utility library for any code that needs to be shared among MapboxGeocoder.swift, MapboxDirections.swift, and MapboxStatic.swift. It would probably end up with geometric model objects, high-level networking code, and error handling, but everything is up in the air.

@incanus and I were trying to avoid having to make these three libraries depend on additional libraries. We’re already having problems getting MapboxDirections.swift’s Polyline dependency to build on watchOS in mapbox/mapbox-directions-swift#71 for some reason. But that problem won’t go away soon, as we work on things like OSRM-text-instructions integration (mapbox/mapbox-directions-swift#101).

A core utility library would make it easier to support more Mapbox Web APIs without the overhead of keeping error handling etc. in sync among all the libraries. Eventually we do want to support all the Web APIs, and reducing that overhead would be a prerequisite. Automating releases and checking in Bitrise workflows (mapbox/MapboxGeocoder.swift#19) would also help.

An alternative proposal that floated around Mapbox was to combine all three libraries into one, similar to how our API support is centralized in Mapbox Android/Java Services, along with lots of miscellaneous code like navigation logic and geometric functions ported from Turf.js. That would avoid a proliferation of libraries, but it also means a watchOS version might be far too large if all you want is a static map.

This repository exists as a place to start factoring out a core library. If we decide down the line to glom everything into a monolithic library, the core library would be part of that merge anyways. I’ve been keeping the three repositories more or less in sync for several months, anticipating either approach.

/cc @mapbox/ios @Eldorado234 @bsudekum @tmcw

@1ec5
Copy link
Contributor Author

1ec5 commented Dec 9, 2016

If we decide down the line to glom everything into a monolithic library, the core library would be part of that merge anyways.

Or we could merge everything into this repository and treat it as a monorepo for multiple frameworks: #2.

@boundsj
Copy link
Contributor

boundsj commented May 23, 2017

This repo is going to be telemetry specific so closing this now. We can copy it over to the actual swift core repo when that is created.

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

No branches or pull requests

2 participants