GoogleMap.OnInfoWindowCloseListener is missing from MarkerManager.Collection

[bshi]

MarkerManager documentation claims (emphasis mine):

Keeps track of collections of markers on the map. Delegates all Marker-related events to each collection's individually managed listeners.

However notably one OnInfoWindowCloseListener, also a marker related event and the only one not covered, isn't handled by MarkerManager (and consequently ClusterManager and related).

In #750 we added OnInfoWindowLongClickListener but the close listener wasn't included.

[googlemaps-bot]

🎉 This issue has been resolved in version 3.20.0 🎉

The release is available on:

• v3.20.0
• GitHub release

Your semantic-release bot 📦🚀

[bshi]

@dkhawk I believe #1636 is necessary but not sufficient to resolve the broader issue. ClusterManager (a dependent of MarkerManager) also needs updates (done in #1541)

Furthermore, as mentioned in the commit msg for #1541, these are technically breaking changes as anyone that upgrades from, e.g. 3.19.0 to 3.20.0 and also uses these events will now have conflicting setters.

BREAKING CHANGE: ClusterRenderer adds two InfoWindowClose listeners. Applications that used ClusterRenderer or
MarkerManager with GoogleMap.setOnInfoWindowCloseListener must now register their listener(s) with relevant
collection/clustering management class.

[kikoso]

Hi @bshi . Thanks for the comment!

When you mention a breaking change, this would be if these events have been handled in a custom renderer, correct? #1636 introduces two public methods that do not affect previous versions of the library. IMO a breaking change would happen if the library already provides those setters.

On the other message: you are correct, #1541 introduces functionality that needs to be implemented, otherwise the ClusterManager (and hence, the renderers) are not implementing the listeners. This is included in #1541, but I believe now there will be a conflict after merging #1636 (both PRs add this bit of functionality, but in a different order).

Would it be possible for you to rebase main onto #1541? Then IMO can be merged (and this is correctly marked as a breaking change)

[bshi]

I believe #1636 is also broken because it does not properly register the new listener during setup. That's why this kind of change is backward compatible. My recommendation would be to revert #1636 until more robust QA/testing can be done.