iOS annotation views

[incanus]

Our current iOS user dot is a custom view (made of three parts; the dot and, mutually exclusively, either the pulsing halo or the accuracy radius).

We also do this with the (singular) callout view:

Though we currently punt on tracking this callout view to the map pan/zoom since there are margin and layout issues that are more complex than the mere user dot.

We eventually want to support other, user-provided views atop the GL map view for several reasons:

• Users are already creating views in projects and want to use them on maps.
• Follows expected MapKit APIs.
• Allows use of existing libraries expecting to work with views such as kingpin (related: point clustering #320).
• Native views allow animatability with Cocoa APIs (CABasicAnimation, UIView animation blocks, etc.)

Somewhat blocked by / could be improved upon with #1125, which I think is at the core of a successful implementation.

Tasks:

• Memory-efficient reuse identifier-based queueing approach for view vending from delegate (-[MGLMapViewDelegate mapView:viewForAnnotation:], -[MGLMapView dequeueReusableAnnotationViewWithIdentifier], etc.)
• Improved syncing/tracking performance in improve synced view tracking #1125 as mentioned above, including research into possible frame-based view/layer OpenGL compositing/texture uploading.
• Branching current tap gesture hit testing to account for native-side views as well as core-side symbols.

[1ec5]

This is a good opportunity to pick #1582 back up as well.

[incanus]

👍

[incanus]

Branching current tap gesture hit testing to account for native-side views as well as core-side symbols.

Actually, this might not be necessary as long as the size of native-side views is taken into account, as hit testing can work the same way.

[incanus]

Based on what I'm seeing with #941, we may be able to punt on this for b3 and just benefit from custom marker imagery there and a better user dot and callout from #1125. It would definitely keep hit testing simple and not have problematic z-ordering between iOS-side views and GL-side sprites, and using what I learned in #1125 (comment) we could keep this all GL-side even when using UIView for b4.

[incanus]

Pushing this off of b3 to keep things simple, as well as keep us in platform-independent territory a bit longer. We'll hit it right & performant out of the gate for b4.

[maxneust]

@incanus Any ETA for when will this be implemented? The only thing keeping us from moving to Mapbox-gl is custom views for annotations/callouts. Thanks!

[mackuba]

I'd also be interested in this - I'm migrating my app from MBXMapKit right now, and I have a "pulsating dot" custom view there very similar to the one described above that I use for map markers.

[mackuba]

Also, once you add support for views, something like map.viewForAnnotation(annotation) would be nice, because I need to access existing annotation views on the map and rotate them in some cases.

[pecheriere]

Hey @incanus, do you have any news about this ?

[gpbl]

I also need to use a custom view for the user location annotation. I tried to subclass MGLMapView but many internals seems to be only accessible by the MGLMapView instance itself.

[1ec5]

If you need to customize the appearance of the user location annotation view (user dot) and don't need a lot of fanciness (like the puck that appears during course tracking), here's a workaround you can use:

1. Implement a class similar to MGLUserLocationAnnotationView that responds to all the same methods.
2. In your MGLMapView subclass (or even your view controller), swap out the map view's private userLocationAnnotationView property using -setValueForKey:.

Important: This is a kludge, and there's no guarantee that it won't break in future releases, especially once we close out this bug but even in seemingly unrelated changes. So this is a last resort; please test thoroughly.

[xemacobra]

I was wondering when do you expect this to be implemented as it is the only thing blocking me from using MapBox over MapKit in my current project even if it only supports a couple of hundred markers instead of thousands. Thanks

[stephensilber]

Also waiting on this feature to migrate from MKMapKit to Mapbox for 2 separate projects of mine!

[devcarlos]

Is this going to be implemented someday ? We have only decided to use MapBox because of the Dark/Light custom styles and the Annotation cannot be as flexible as the map? Really ? Very disappointed so far and thinking to stay with MapKit after all.

At least you should give some hints to create an MGLAnnotationImage with custom texts like title, subtitle or similar.

[1ec5]

Yes, this issue is on the 3.3.0 milestone. The implementation depends on #4384 and would likely progress in tandem with #4392.

In the meantime, the iosapp demo application has some code you can crib for rendering text onto an annotation image. It looks like this:

[devcarlos]

Thanks @1ec5 I was going to try the same (take a UIView snapshot) with my Map Pin icon as background and the Title text required.

Regards,
Carlos

[1ec5]

The Android analogue to this issue is #3276.

[postmechanical]

@1ec5 Any progress on this issue? Is there a branch for it yet?

[1ec5]

Hey @postmechanical, we’re just getting started on this issue today. We’re starting with #4384, as that’ll be critical for performance. Performance-wise, there’s also the approach @incanus took in #1125 (comment), but we aren’t planning to revisit that optimization until we’ve got the basic API up and running.

[mmccroskey]

Hi @1ec5 -- I work with @postmechanical and was wondering if there were any updates you guys could offer on this one?

[boundsj]

Hi @mmccroskey as @1ec5 said above, we are just getting started on this. I will make a PR in the coming days but I don't have an exact ETA on when this feature will be completed. As @1ec5 mentioned, you can monitor #4384 (and this ticket) for updates as they happen.

cc @twbell

[mmccroskey]

Sounds good, thanks @boundsj

cc @postmechanical

[1ec5]

For future reference, the experimental performance optimization described in #1125 (comment) is on the view-based-points branch.

[1ec5]

MGLAnnotationView landed on iOS in #4801. Opened #5035 to track porting it to OS X.

[1ec5]

Our current iOS user dot is a custom view (made of three parts; the dot and, mutually exclusively, either the pulsing halo or the accuracy radius).

Filed #5039 to base the user dot on the annotation view class.

I also need to use a custom view for the user location annotation.

Filed #5037 to add a way for you to specify the user location annotation’s view.

Filed some more issues for tail work: #5036 #5038 #5040.