[ios] Provide haptic feedback when user rotates to due north

[friedbunny]

This is an embellishment, brought about by the fact that I have a phone that supports it now. 😉

• Adds light haptic feedback when a user rotates the compass to/across due north.
  • Acts as a hint to users that they’ve found north/0°.
  • Requires iOS 10+ and a device that supports haptic feedback (iPhone 7 or newer).
  • Does not play haptics when the compass auto-snaps back, as that seemed too distracting/disconnected. Could reinvestigate, if folks thought that’d be worthwhile.
• Adds MGLMapView.hapticFeedbackEnabled, enabled by default.
• Makes iosapp’s zoom/tilt/rotation HUD persistent across launches and repositions it to the top-left.

/cc @fabian-guerra @akitchen @1ec5

[1ec5]

I wonder if we’ll eventually outgrow this single Boolean flag. Something akin to AppKit’s NSHapticFeedbackPattern enumeration would give us a bit more flexibility.

[fabian-guerra]

Which would be the events that may provide haptic feedback?

[1ec5]

For now, just compass snapping, though #10847 (comment) hints at a couple more possibilities. An enumeration with “haptic feedback levels” would give us room to add more in the future without overwhelming the default behavior.

[friedbunny]

Having an enum would allow us to offer a higher/broader level of feedback as a configurable option, which could be nice. I think that’s a #future thing, though, when/if we’re able to find multiple other use cases for rumbling people’s devices.

[1ec5]

Understood, though note that this design locks us into a binary option until v5.0.0.

[akitchen]

That's a very good point. An enum with just two values (on and off, essentially) would make this easier to extend in the #future without the need for a deprecation and subsequent breaking change.

[friedbunny]

What do we call the on enum value if we don’t know what future options will be? 🤔

[1ec5]

I was thinking of a bitfield along the lines of MGLDebugMaskOptions, except perhaps with an All option that occupies the entire width of the type.

[1ec5]

Going forward, any gesture that results in a snapping motion should trigger haptic feedback, if only for consistency. What about situations where we limit user interaction without snapping? Eventually we’ll want to implement snapping if the user tilts too far (#2191) or the developer returns NO in -[MGLMapViewDelegate mapView:shouldChangeFromCamera:toCamera:], but these interactions do represent a hard stop currently.

[friedbunny]

Per discussion, I’ll look into converting BOOL hapticFeedbackEnabled to a bitmasked enum.

[friedbunny]

On second thought, I’d like to just proceed with BOOL hapticFeedbackEnabled. Here’s my reasoning:

• There aren’t many haptic use-cases in this SDK that we should implement by default — limit snapping/stopping seems to be essentially it. Developers are free to implement marker-dropping thuds today, but that’s probably not something we’d offer either way.
• Anything more than a BOOL feels like over-designing for a future that probably won’t happen. (E.g., it’s taken us 1.5 years to get to haptic feedback at all, we’re not designing AppKit, etc.)
• If we find additional use-cases that would overwhelm the current implementation, eventually deprecating one BOOL is not a huge risk — I think it’s better to keep a simpler API today.