Consider moving the map style parameters to the StyleState

[sargunv]

The map snapshotter (#266) introduces an additional use case for map style. Conceptually, it makes sense that:

1. a snapshotter should be able to have the same style as an interactive map
2. a snapshotter's style should be configurable the same as an interactive map

So, perhaps it would make sense for the StyleState, instead of the MapLibreMap, to own the base style URI and the style composition, and the StyleState to be passed as parameter to the snapshotter?

[sargunv]

Example before:

MaplibreMap(styleUri = "https://tiles.openfreemap.org/styles/liberty") {
  val tiles = getBaseSource(id = "openmaptiles")
  CircleLayer(id = "example", source = tiles, sourceLayer = "poi")
}

Example after:

val styleState = rememberStyleState(uri = "https://tiles.openfreemap.org/styles/liberty") {
  val tiles = getBaseSource(id = "openmaptiles")
  CircleLayer(id = "example", source = tiles, sourceLayer = "poi")
}

MaplibreMap(styleState = styleState)

and then for the snapshotter:

val snapshotter = rememberMapSnapshotter(styleState = styleState)
val cameraState = rememberCameraState()
var bitmap by remember { mutableStateOf<ImageBitmap?>(null)

LaunchedEffect(Unit) {
  bitmap = snapshotter.capture(cameraState)
}

cc @michalgwo as you're interested in the snapshotter; thoughts on this kind of API?

[michalgwo]

It makes sense to me to have the base style URI and the style composition in the StyleState, but I'm not sure if it's possible to use the same style composition with the map and snapshotter.

[sargunv]

Took a look at MapLibre Android docs: https://maplibre.org/maplibre-native/android/api/-map-libre%20-native%20-android/org.maplibre.android.maps/-style/-builder/index.html

It looks like the MapSnapshotter takes a style builder, and the style builder takes some base style (url or json) and can have programmatic sources and layers added to it.

Right now our style composition relies on mutating a style at runtime, so we'd need to decouple the code that maintains the "style diff" (all the programmatically added/removed sources, layers, and images) from the code that applies it to a Style. And then that diff will have two ways it can be applied:

1. directly to a style, as it changes
2. to a style builder for a snapshot

If someday the offline manager accepts a style builder, it'll be handy there too.

Need to look at iOS to see if capabilities are similar.

[sargunv]

Or alternatively, implement only (2), and have the interactive map recreate the style when sources, layers, or images are added/removed. Sounds like it might be expensive (but, how often are apps doing this, vs just mutating particular properties on the sources/layers?). Might even be a fix for the double-source-addition bug causing #236.

[sargunv]

This'd be a pretty fundamental change to style management, so I think I'll cut a v0.9.0 release now and split this out into the next release. That way we don't have so many major changes all bundled into a single release.

[sargunv]

Ah damn, looking at the MapLibre iOS docs, they only support initializing a snapshotter with a style URL: https://maplibre.org/maplibre-native/ios/latest/documentation/maplibre/mlnmapsnapshotoptions

So I think we have two one feature requests to upstream:

• Support programmatic styling for the snapshotter on iOS, for parity with Android
• Support programmatic styling for the offline packs on iOS and Android

In the meantime, I think we can merge something like the existing snapshotter PR: #266

Moving the style composition to the style state still makes sense though, so we can have different style state APIs (for example, a low level imperative one like #18).

[sargunv]

Ah, never mind: https://maplibre.org/maplibre-native/ios/latest/documentation/maplibre/mlnmapsnapshotter/style

We can mutate the style on the snapshotter after loading it, so it should be possible on iOS.

So back to my original plan to land the snapshotter after this style state change.