Marker dragging: fix loss of drag events and difficulty observing marker positions

android-maps-compose 2.2.1

The current API design of Marker and MarkerState poses significant challenges. This issue is a continuation of comments I made in #10; @arriolac asked to move discussion to a new issue.

1. ‘DragState’ events are lost, in particular START, but also DRAG, and, theoretically, even END.

This is due to the characteristics of snapshot state in relation to events:

Observable state is a lossy compression of the events that produced that state.

https://developer.android.com/reference/kotlin/androidx/compose/runtime/package-summary#snapshotFlow(kotlin.Function0)

I have a use case where I need to reliably detect START and END to temporarily keep a backup of the old marker location to restore in case the final marker drag location is deemed invalid by business logic.

1. Hoisted state objects are not suitable for representing collections of app marker data.

Hoisted state objects can be a suitable vessel for maintaining UI state. However, they are an anti-pattern for representing data that is ultimately maintained in an app data model. Observing requires using snapshotFlow for each indivdual state object, and updating implies feeding model data back to the state object in some manner.

An app commonly maintains a collection of markers, so a collection of MarkerState objects is needed, one for each marker. Markers may be added or removed, adding significant complexity to the task of keeping separate collections of marker data in sync. Typically one will opt to recreate the entire collection if one element changes in any way.

I will add more detail and proposals in comments below.

Clarification: In my main use case for this feature, markers define the corners of a polyline/polygon, so order is significant, and the marker collection is a list, where updates, inserts, and deletions can occur at any position. Keeping lists of variable size with changing marker content synchronized is a more challenging problem than for example maps of markers where order is not significant; I use the latter in another case, and it is easier to deal with.

[bubenheimer]

Thanks @arriolac, makes sense. I made one clarification in the original comment that my primary use case is changing lists of markers, which is a more challenging problem than unordered collections.

[bubenheimer]

There are small, but significant changes in the latest version of my gist: https://gist.github.com/bubenheimer/fe7580248a7f7f905f05b70ceaeb97ed

In particular: Marker position can now be set from the dragging handler. This is particularly relevant at the end of a drag sequence, where an app may decide to accept, discard, or change the final marker position. The handler can promptly change the marker position in the middle of a drag operation as well, to be on par with existing Maps SDK capabilities. (And without going through recomposition which could cause additional visual artifacts.) Of course, this is not really recommended. It effectively offers all the capabilities of the Maps SDK without needing to expose MarkerState.position directly to composition.

The other gist changes are smaller refinements and bug fixes.

The gist is the essence of what I think the Maps Compose API changes should look like.