MapObjectManager is a private class

[scruffyfox]

Hi!

I'm trying to implement clustering in my existing codebase which has classes to manage various different markers and overlays. Our custom implementation requires us to delegate the map events to the various overlays. Adding clustering using the default MarkerManager class means all of our listeners are overridden by this new object.

I can't override MarkerManager and setListenersOnUiThread to block this as the method is final. I can't override MapObjectManager to implement my own marker management as the class is package-private.

Is MapObjectManager being a private class intentional? We'd eventually like to refactor our manager/overlays to use more of the util classes, but being restricted to just the provided classes might make this difficult/impossible.

[jeffdgr8]

@scruffyfox MapObjectManager is an abstract class that adds an abstraction to the default Google map listener registration APIs. Many features of this map utils library have overlapping usages for various map object features. For example, clustering requires its own collection of managed markers, which it adds and removes from the map. The KML feature also requires adding its own collection of markers, which require separate listeners. The default Google Maps API only allows registering a single listener per map object type, which causes listeners to override previously registered listeners. Overriding the behavior of these map object managers would break the functionality that allows for using multiple features and collections of map objects and registering separate listeners for each collection, and ultimately break the internal functionality of this library, which requires these listeners to function.

See the multi layer demo for an example of how to use these map object managers. You should create a single manager for each type of map object you're using. Then pass the required managers to the map utils features you're using (e.g. ClusterManager or KmlLayer). For any map object features you're adding on your own (e.g. unclustered markers), create a new collection from the appropriate manager and utilize the collection's APIs to register listeners and add and remove map objects, rather than the Google map APIs directly.

Migrating your existing code should be straightforward. Replace all calls to register listeners, add objects, or clear the map currently being called directly on the Google map object with the equivalent call to the map object collection instead. Similarly, calls to remove objects on objects directly should instead call remove on the corresponding map object collection instead.

[scruffyfox]

Thanks @jeffdgr8. I'll take this into consideration when I get around to refactoring all my existing code :)