You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: