WIP: Style layers and data sources #272
Conversation
There was a problem hiding this comment.
Cool stuff @maximumbuster, to support a real style API and making that easy to maintain, I would like to look into the possibility of generating all of this code. This is also what we do upstream for Android and iOS: eg https://github.com/mapbox/mapbox-gl-native-android/blob/master/scripts/generate-style-code.js
|
@tobrun that sounds cool, you mean generate the function to convert the properties json to layer properties? |
|
Sounds like we could use the code_builder package for that. |
Ideally we would generate:
That looks cool 😄 . Note that this approach however would result in supporting the full style-spec logic (and that would be a substantial amount of work). If we would reuse the EJS template based setup from gl-native we would only need to adapt a platform implementation of the code generator and provide EJS template files. |
|
This looks super interesting, any updates on this? |
|
Any update ? Style layer and source would be really appreciated 👍 Our app draws more than 1000 symbols dynamically. Which makes the map very slow to draw everything |
|
We need this so much please 🙏 |
|
Haven't worked on this for a while but I had an implementation with sources, expressions and line+symbol layers working for android and ios here: https://github.com/maximumbuster/flutter-mapbox-gl/tree/layers. Not sure what it would take to get this merged in the main repo but feel free to copy code from my repo if you want. |
There was a problem hiding this comment.
@maximumbuster The question is how we go forward from here. This seems pretty complete.
@tobrun Adding typed interface for the properties would be great, but this seems usable and useful as it is (with a few changes). Adding proper types - with code generation - seems very much doable in a future release - especially if we do this merge with that in mind. Delaying this for another two years does not seem like a good idea.
However i agree that doing the code generation at least for the native side might be good idea.
I will implement this myself - i'll write a full implementation - with code generation.
Hopefully done in the few weeks. @maximumbuster will will base in your code tho - i hope thats fine with you!
|
|
||
| //FIXME: Add your Mapbox access token here | ||
| static const String ACCESS_TOKEN = "YOUR_TOKEN_HERE"; | ||
| static const String ACCESS_TOKEN = "pk.eyJ1Ijoib3V0d2F5LWFkbWluIiwiYSI6ImNrMnRxYnQ3bzFlNTEzbXVpNXIxZG00dG0ifQ.jt1gMJMirDNJneqN3G1O8w"; |
| s.dependency 'Flutter' | ||
| s.dependency 'MapboxAnnotationExtension', '~> 0.0.1-beta.1' | ||
| s.dependency 'Mapbox-iOS-SDK', '~> 5.6.0' | ||
| s.dependency 'Mapbox-iOS-SDK', '~> 5.2' |
| init(withFrame frame: CGRect, viewIdentifier viewId: Int64, arguments args: Any?, registrar: FlutterPluginRegistrar) { | ||
| if let args = args as? [String: Any] { | ||
| if let token = args["accessToken"] as? NSString{ | ||
| if let token = args["accessToken"] as? String? { |
There was a problem hiding this comment.
whats the reason for this change?
| void _onStyleLoadedCallback() { | ||
| controller.addSource("source_1", geojson); | ||
| controller.addLineLayer("source_1", "layer_1", { | ||
| 'line-width': "[\"interpolate\", [\"linear\"], [\"zoom\"], 15.0, 1.0, 23.0, 10.0]" |
There was a problem hiding this comment.
It would be great if you could change addLineLayer to not expect Map<string, string> and instead use Map<String, dynamic>. JsonEncode will work on anything thats also valid as an option for the parameter as the parameters are expected to work with json anyhow. As invokeMethod takes care of that you can simply pass the properties as you do now. For native you could remove the code that decodes the values, as the whole object would already have been decoded right away.
This line could then be written as:
'line-width': ["interpolate", ["linear"], ["zoom"], 15.0, 1.0, 23.0, 10.0]
which feels much less hacky. Also this has the added benefit that as invokeMethod tries to encode to json, that is whatever has been passed in is not valid json the error happens on the dart side and not in the native code.
| } | ||
|
|
||
| void _onStyleLoadedCallback() { | ||
| controller.addSource("source_1", geojson); |
There was a problem hiding this comment.
Similar to my other comment I would change the geojson parameter of addSource to Map<String, dynamic>. Much less hacky than messing with strings. invoke will work regardless. If someone wants really to use a string then its trivial to call jsonDecode to get a map.
| 'setSymbolTextIgnorePlacement() has not been implemented.'); | ||
| } | ||
|
|
||
| Future<void> addSymbolLayer(String sourceId, String layerId, Map<String, String> properties) async { |
There was a problem hiding this comment.
maybe rename this to addSymbolLayerDynamic so that we can add a typed version called addSymbolLayer in the future?
| await MapboxGlPlatform.getInstance(_id).addSource(sourceId, geojson); | ||
| } | ||
|
|
||
| Future<void> addSymbolLayer(String sourceId, String layerId, Map<String, String> properties) async { |
There was a problem hiding this comment.
addSymbolLayerDynamic for future typesafe version?
| await MapboxGlPlatform.getInstance(_id).addSymbolLayer(sourceId, layerId, properties); | ||
| } | ||
|
|
||
| Future<void> addLineLayer(String sourceId, String layerId, Map<String, String> properties) async { |
There was a problem hiding this comment.
addLineLayerDynamic for future typesafe version?
|
closing in favor of #723 |
This is very much a WIP but shows an example of how we could create sources and layers using the native sdks. It also uses expressions parsed from text to make styling more flexible at runtime with data driven and camera driven styling.