popups

[incanus]

Popups, callouts, bubbles, whatever you want to call them, we need selection state and info bubbles on markers.

Per @jfirebaugh (and I agree) we should do these for each platform because they are distinct and need to feel natural to the platform, such as being complex, even animated, views and being able to contain other platform-specific views.

For this reason, I think we should only worry about this on Android and iOS.

I've been very happy with SMCalloutView, which we integrated into our iOS SDK, and I think we should continue to use that here.

[incanus]

Also of note is that the performance implications of not doing this in GL core itself will be small. At least on iOS, only one callout is present at a time (single selection) and just simply tracks on the map.

[ljbade]

On Android the OS uses GL anyway to render/draw overlaid views so unlikely to be slower then rendering in our GL context.

[incanus]

@1ec5 has been starting to look into this, tracking using CADisplayLink but going to try @bleege's work on a "region is actively changing" delegate method in iOS.

[incanus]

I'm grabbing this now to start on post-point annotations merge (#1021) since gestures, point-in-bounds, and platform-side callouts are all integrated.

[incanus]

Annotation selection should work something like this. Note that unlike MapKit, the z-index of the selected marker doesn't change (that's in #991).

This is done with something like d53fb94, which just does a dumb 44px box around the touch for point-in-bounds querying, then iterates selection state through the close-by annotations. It doesn't take marker icon size into account; likely we'll want to make this box a bit larger and emphasize in the top direction.

This is kind of like JS's featuresAt(), since point annotations' tiles work like an R-Tree.

[incanus]

Summarizing state of popups. The tough nut to crack here is syncing pan and zoom — including decelerated coasting — between native iOS views and the GL view. We've tried this in three branches, with varying combos of MGLAnnotation protocol data objects or other placeholder markers.

• 877-display-link — using CADisplayLink callback to sync simple UIImageView markers with GL
• 877-callout — bringing in SMCalloutView popups & updating position of it and UIImageView markers using a new mbgl::MapChangeRegionIsChanging event coming out of GL
• 877-point-callout — same as above, but originally merging in GL-side point annotation work (@1ec5 I think we can fold this into the above branch now?)

All have been updated to master as of ae7bd9a.

The next approach I'm going to try is, since we're tracking annotations' positions GL-side, have GL update their screen position values every frame draw, and have Cocoa read out those values, translate to CGPoint, and update on screen. That is, the main difference between all of the above approaches is that we'd have GL update the non-geographic positions itself on frame draw rather than the non-GL parts update them on some sort of (likely delayed and/or not as frequent) callback.

[1ec5]

@incanus Yes, let’s fold 877-point-callout into 877-callout. That’ll make merging for 756-gps-marker easier.

[incanus]

Visual syncing is currently blocked by #1026. In the meantime, I'm going to tighten up the annotation model API, get gestures/selection working, and roll a PR.

[incanus]

Per chat with @1ec5, we are going to move towards dismissing any active callout for map change events for b1. We'll get back to view syncing post-b1.

[incanus]

Point annotations Cocoa API for gestures and selection state is in as of eded1d9. Working on this next to integrate.

[incanus]

This last commit b027b0b is feeling good on top of my nearly-merged annotation flexing in #1061. We are close @1ec5!

[jfirebaugh]

Now that we've got a PR for iOS, I'm removing this from the milestone and untagging iOS, but keeping the bug open to track the Android implementation.

[erf]

Any idea if this feature is far away? Also curious on the progress for on-annotation-click event for Android.

[bleege]

trying to squash but not steal all of @bleege's credit 😉

Not a problem! Always happy to have a tag team partner.