You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you set up the annotations for your map view controller in viewDidLoad - as suggested in the README then you get a superfluous cluster annotation if presenting the map view controller in Landscape. Note the big "59" cluster on top of ÖSTERREICH.
If you move it to viewWillAppear or later, then this extra cluster does not appear:
I believe that the reason for the misbehavior comes from MKMapView having an incorrect position during viewDidLoad. I added logging for the visible map rect in the -init of CCHMapClusterOperation.
Portrait, viewDidLoad:
Visible map rect = {{141014758.6, 88274850.3}, {6111232.3, 10743653.0}}
Visible map rect = {{141014758.6, 88274850.3}, {6111232.3, 10743653.0}}
Portrait, viewWillAppear:
Visible map rect = {{141014758.6, 88274850.3}, {6111232.3, 10743653.0}}
Landscape, viewDidLoad:
Visible map rect = {{40502319.6, 79459175.3}, {127778493.3, 69020511.0}}
Visible map rect = {{141014758.7, 91996163.0}, {6111232.1, 3301027.8}}
Landscape, viewWillAppear:
Visible map rect = {{141014758.7, 91996163.0}, {6111232.1, 3301027.8}}
The second line in the Landscape-viewDidLoad log comes from this call stack:
As you can see there is a timer delay that fixes the visible map rect and calling the mapView:regionDidChange:animated: thus triggering a reclustering.
Putting the setup code into viewWillAppear resolves the issue, but the question for this bug report is, whether the initial clustering shouldn't be delayed until after the first setting of the visible region. The current recommendation and code leads to a superfluous clustering operation.
The second question is, why the second clustering operation does not correct the superfluous cluster annotations that the first one created.
This issue observed on an app with deployment target 8.1, running on 8.3, using a MKMapView from storyboard and size classes throughout.
The text was updated successfully, but these errors were encountered:
I updated the sample code to read in 500 annotations synchronously in viewDidLoad. In this scenario, CCHMapClusterOperation gets called twice: once for a setRegion call and once for adding annotations. The clusterer has to re-cluster the annotations in both cases because either operation causes a change in the visible annotations (the first one will be basically for free because there are no annotations to cluster). Is this what you are seeing as well?
As for the second case: setting the region should definitely re-cluster all visible annotations. Could you provide sample code that demonstrates this issue? When I use the example project, the app starts in portrait and when I rotate manually to landscape, everything works fine. But your are starting this view controller in landscape?
If you set up the annotations for your map view controller in viewDidLoad - as suggested in the README then you get a superfluous cluster annotation if presenting the map view controller in Landscape. Note the big "59" cluster on top of ÖSTERREICH.
If you move it to
viewWillAppear
or later, then this extra cluster does not appear:I believe that the reason for the misbehavior comes from
MKMapView
having an incorrect position during viewDidLoad. I added logging for the visible map rect in the -init ofCCHMapClusterOperation
.Portrait, viewDidLoad:
Portrait, viewWillAppear:
Landscape, viewDidLoad:
Landscape, viewWillAppear:
The second line in the Landscape-viewDidLoad log comes from this call stack:
As you can see there is a timer delay that fixes the visible map rect and calling the
mapView:regionDidChange:animated:
thus triggering a reclustering.Putting the setup code into viewWillAppear resolves the issue, but the question for this bug report is, whether the initial clustering shouldn't be delayed until after the first setting of the visible region. The current recommendation and code leads to a superfluous clustering operation.
The second question is, why the second clustering operation does not correct the superfluous cluster annotations that the first one created.
This issue observed on an app with deployment target 8.1, running on 8.3, using a MKMapView from storyboard and size classes throughout.
The text was updated successfully, but these errors were encountered: