Rename location component's enable/disable methods about mapbox-gl-native-android HOT 5 CLOSED

The API is currently exposed on MapboxMap and requires providing a Style. I believe it makes more sense moving the API to Style itself as it's a required argument. This would simplify showing a default styled user location on the map as:

new StyleBuilder().withLocationComponent()
// or
style.setLocationComponentEnabled(true) 

Options classes can be provided as:

new StyleBuilder().withLocationComponent(LocationComponentOptions... options)
// or
style.setLocationComponentEnabled(true, LocationComponentOptions... options) 

from mapbox-gl-native-android.

IMO any object tied to a style should have the lifespan equal to the one of the style in question, this would force users to cache all of the component's current options and re-apply them with each style change, which is now done out-of-the-box becuase the component can survive style changes.

I think that just because an entity needs access to the style object to add sources and layers doesn't mean that it should be managed by the style object itself.

Anyway, let's get this ticket back on track and focus on the rename of the enable/disable method, any additional thoughts on that @tobrun? I'm going to cut another ticket to capture above comments.

from mapbox-gl-native-android.

Yes, the LocationComponent's layers/sources are tied to the Style object, but I like the idea of sticking to the current setup where the LocationComponent is a separate entity. As @LukasPaczos says, the LocationComponent is already surviving style changes, which makes it seem and visually behave like it's independent from the visible style. By "visually behave", I mean that when it's enabled and the style is switched, there is lag between the new Style being visible and the LocationComponent being visible again. It's not as if the LocationComponent is loaded exactly at the same time as the rest of the Style's visual properties. Correct me if I'm wrong, but it's not as if LocationComponent styling information is in the Style JSON when a Style object is initially loaded anyways. Anyways, you get my point 👀

Maybe rather than enableLocationComponent() and disableLocationComponent(), the methods could be showLocationComponent() and hideLocationComponent()? Or maybe displayLocationComponent() instead of showLocationComponent()?

enable and disable don't make it immediately clear that they adjust the LocationComponent's actual visibility. enable and disable sound more like behind-the-curtain telemetry enabling/disabling of detecting device location, rather than conveying the fact the methods will affect whether or not the device location dot will actually appear on the map.

from mapbox-gl-native-android.

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

from mapbox-gl-native-android.

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

from mapbox-gl-native-android.