1ec5
commented
8 years ago Some addenda:
You’d drag a custom view into the scene dock above the view controller and optionally set the custom class to MGLCompactCalloutView… You’d specify a reuse identifier for the callout view
Providing a reuse identifier inspectable for ordinary UIViews would be tricky. We can’t add a stored property to UIView via a category. However, we could have the category-defined getter and setter work with an associated object on the view.
If the developer wants the standard bubble look but forgets to set MGLCompactCalloutView as the custom class, should the callout really be transparent and borderless?
You could define an annotation view itself by dragging a UIImageView into the scene dock, connecting it to the map view’s
prototypeAnnotationViewsoutlet collection, and optionally connecting a callout view to the annotation view’scalloutViewoutlet.
There are two likely models here:
- The map view has a
prototypeAnnotationViewsoutlet collection, and each prototype annotation view has acalloutViewoutlet. This option is simpler and reminiscent of MKAnnotationView’s various callout-related properties, but it’s more difficult to mix and match annotation views and callout views. - The map view has
prototypeAnnotationViewsandprototypeCalloutViewsoutlet collections, and a prototype annotation view can designate a callout view by its reuse identifier. This option is more powerful, but the way to link an annotation view with a callout view is less discoverable.
What happens when we add support for showing callouts on shape and line overlays? It may make sense to have prototype callout views be independent of any prototype annotation view.
Where should the callout’s anchor position or anchor edge be exposed? As a property of the callout view or the annotation view?
friedbunny
incanus
ghost
stale[bot]
The current annotation callout API is implemented as a series of delegate methods in MGLMapViewDelegate that configure SMCalloutView. SMCalloutView provides a lot of customization options, but we’re only exposing a few basic ones.
SMCalloutView is great for callout views that need a certain layout, but many developers need more flexibility and don’t mind setting up the layout and drawing themselves. The current API for custom callout views can be very confusing for a developer who wants something more freeform – “Why do I have to implement accessory views?” And you’re basically on your own in terms of styling as soon as you go the custom callout route.
Let’s drop the dependency on SMCalloutView and deprecate the current callout API – both the delegate methods and the protocol – in favor of a more deliberate, coherent callout API. The proposal below is aimed at aligning the iOS SDK’s annotations API with that of the OS X SDK, which manages callouts with NSPopoverControllers and allows you to specify your own.
You should be able to drag a custom view into a storyboard, turn it into an MGLMapView, and design the custom callout views directly inside the storyboard. You’d drag a custom view into the scene dock above the view controller and optionally set the custom class to MGLCompactCalloutView, which provides the standard bubble look and feel (surfaced in the storyboard via a designable). You’d specify a reuse identifier for the callout view, then drag a connection from the callout view to the map view’s
prototypeCalloutViewsoutlet collection. The callout view can be customized extensively without any work on our part:rightAccessoryViewoutlet so that-[MGLMapViewDelegate mapView:annotation:calloutAccessoryControlTapped:]would get called.When configuring an MGLAnnotationView (#1784) or MGLAnnotationImage programmatically, you’d choose which callout view to use with the annotation, identifying one of the prototype callout views either by indexing into the outlet collection or by specifying a reuse identifier. This part differs from how MapKit’s MKAnnotationView API works, but I think it’s worth diverging to offer better storyboard support and more flexibility. Notably, setting up the annotation model object is the only part of the workflow that absolutely requires code.
If possible, we’d provide a compatibility shim for the old API that could get removed in a future major version. But if you want to work with SMCalloutView specifically, then you’d be able to pull in SMCalloutView and customize it to your liking without depending on SDK changes.
The entire API would still be usable programmatically for more advanced use cases. But the goal is that the “First steps” guide, which is intended for beginners, would have only a few lines of code and the rest would be in Interface Builder. Some future directions, somewhat out of scope for this issue, would further reduce the need for code:
prototypeAnnotationViewsoutlet collection, and optionally connecting a callout view to the annotation view’scalloutViewoutlet.A lot of the code in this custom callout view example can be reused to implement a snazzy-looking default callout view.
/cc @friedbunny @boundsj @tmcw