[Feature request]: Marker IDs are forcibly overwritten regardless of user-specified IDs

[yutsuki3]

Is there an existing issue for this?

• I have searched the existing issues

Use case

Description

There is an issue in the current implementation where user-specified marker IDs are ignored and new IDs are forcibly generated internally. This makes it difficult to manage, update, or delete individual markers.

Current Behavior

In common_view_api.dart, _createMarkerId() always generates a new ID, overwriting any ID that may have been set in MarkerOptionsDto:

final List<MarkerDto> markersToAdd = options
.map((MarkerOptionsDto options) =>
MarkerDto(markerId: createMarkerId(), options: options))
.toList();

Proposal

The implementation should prioritize user-specified IDs and only auto-generate IDs when none are provided:

final List<MarkerDto> markersToAdd = options
.map((MarkerOptionsDto options) =>
MarkerDto(
markerId: options.markerId ?? createMarkerId(),
options: options
))
.toList();

• Preserves user-specified marker IDs
• Enables easier management of individual markers
• Allows reliable updating and deletion of existing markers

[jokerttu]

Note that marker IDs are not regenerated when the updateMarkers method is used to update existing markers that were created using the addMarkers method.

Also MarkerOptions (nor MarkerOptionsDto) do not have field for MarkerId.

[jokerttu]

@yutsuki3
Thanks for your feature request!

The reason we don't allow developers to set IDs manually is to avoid collisions, as having the same ID on multiple markers causes issues in the platform implementation.

When a marker is added, the platform returns the added markers in the same order with generated IDs.
If developers need custom IDs, they currently have to handle mapping between IDs in their own implementation. This means they need to maintain a separate mapping between their custom IDs and the generated platform IDs, ensuring that interactions such as marker clicks or updates can be correctly linked back to their original identifiers. I admit this is not the easiest approach, as it requires additional logic to track and synchronize these mappings manually.

We will discuss internally whether we should provide the possibility to customize marker IDs (or other object IDs), with a clear warning about potential collisions.

[fummicc1]

Thank you for your response, @jokerttu.

I understand why markerID is managed internally. However, I believe distinguishing between multiple markers at the same coordinates would be quite challenging. Since we associate markers with our domain model using LatLng coordinates, differentiating them might be difficult.

Additionally, if the native library allows users to assign custom markerIDs, I believe the Flutter Navigation SDK should also support custom markerID assignment, and vice versa.

The approach you suggested would work, but if support for custom IDs is added, we could consider making it an optional setting in the Options object or introducing a breaking change to modify this behavior, as this package is still in beta.

I think your approach is the better choice! :)