-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Style-compliant JSON in Android and iOS SDKs #13467
Comments
I also think the Mapbox SDK style parsing, layer parsing and source parsing should be exposed to provide more functionality to developers. I also have the layer definitions and source definitions but cannot add them as json to the style. I have to write code to parse it and read into the I am also experiencing issues converting some paint and layout properties which in v10 of streets style were expressed as functions using I don't want to add additional code in my project to parse the json layers & sources for a couple of reasons:
@tobrun, @zugaldia, anyone, Could you help me out? |
/cc: @tmpsantos as this looks like something we'd like to add to core first, instead of implementing it twice (with the subsequent roundtrips) on the platform side. |
/cc: @chloekraw per chat. |
I actually suggested something like this before: |
On iOS and macOS, you can use |
We have a customer currently building a hybrid app with Mapbox. The app is set up such that most of the business logic lives in javascript, and then actual rendering commands are handed off to native code when running in iOS/Android. They were able to get through the initial mapbox-gl-js implementation pretty quickly and now are working on duplicating that functionality with the iOS native SDK. They are passing the same source/layer objects to native code that they are using for the JS implementation. An example of this would be:
This has ended up being a bit clunkier than they were hoping, as they need to parse the objects coming from JS, instantiate the correct native object, and then update appropriate properties on those objects. Is there any way to work directly with style-compliant JSON in the native SDKs. For example, the Objective C handling for addLayer in the above case might look something like:
They were hoping there was an existing mechanism for parsing JSON objects directly into native style layers and sources. Given that you can do this for a complete map style file, it seemed likely that functionality would exist somewhere in the native SDK (but is perhaps not exposed). Exposing that functionality would drastically reduce the amount of code needed to maintain consistency between android/ios/web.
The text was updated successfully, but these errors were encountered: