Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClusterManager.clearItems() doesn't clear cache #578

Closed
g012 opened this issue Nov 7, 2019 · 2 comments
Closed

ClusterManager.clearItems() doesn't clear cache #578

g012 opened this issue Nov 7, 2019 · 2 comments
Labels
needs more info This issue needs more information from the customer to proceed.
Milestone

Comments

@g012
Copy link

g012 commented Nov 7, 2019

Hello,

When we clearItems in ClusterManager, it seems the markers cache of DefaultClusterRenderer is not cleared. Calling getMarker() on it will return a marker not matching the current Map, causing an exception.

I resorted to recreate the whole renderer on each clear to avoid that.

Thank you.

@g012 g012 added triage me I really want to be triaged. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Nov 7, 2019
@barbeau barbeau changed the title DefaultClusterRenderer should empty its marker cache on ClusterManager reset ClusterManager.clearItems() doesn't clear cache Nov 8, 2019
@barbeau barbeau added priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. and removed triage me I really want to be triaged. labels Nov 8, 2019
@jeffdgr8
Copy link
Contributor

The only place ClusterManager updates ClusterRenderer's markers is in the result of cluster() with the call to onClustersChanged(). So clearItems() doesn't actually update the map markers at all until cluster() is called. This is the same behavior as any of the ClusterManager methods that add or remove ClusterItems, addItems(), addItem(), removeItems(), or removeItem(). All of these methods modify the ClusterItems in the Algorithm, which will change what Clusters are generated on the next call to cluster(). You should call cluster() after calling clearItems() and potentially any other methods afterwards to add or remove ClusterItems from the map.

Could you elaborate more on what your code is doing and what exception is being thrown?

@barbeau barbeau added status: investigating The issue is under investigation, which is determined to be non-trivial. needs more info This issue needs more information from the customer to proceed. and removed status: investigating The issue is under investigation, which is determined to be non-trivial. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Jan 28, 2020
@barbeau
Copy link
Collaborator

barbeau commented Feb 19, 2020

@g012 While looking into #90 I can confirm that after calling ClusterManager.clearItems() there are markers remaining in DefaultClusterRenderer's mMarkerCache cache, but this seems to be by design to allow updating the cluster markers without markers on the map flickering (which would happen if they were removed and then quickly re-added).

If you want to clear the map of all cluster markers, just do:

mClusterManager.clearItems();
mClusterManager.cluster();

I'm adding better Javadocs in a pull request I'm working on for #90 to describe this and related cases (as well as fixing an issue that prevented updating the marker contents from the cache).

I'm going to close out this issue, but if you can provide more information about the specific use case you're attempting with some sample code we can certainly revisit.

@barbeau barbeau closed this as completed Feb 19, 2020
@arriolac arriolac added this to the 1.0 milestone Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs more info This issue needs more information from the customer to proceed.
Projects
None yet
Development

No branches or pull requests

4 participants