-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix custom tap gestures for NavigationMapView #56
base: main
Are you sure you want to change the base?
Conversation
Apparently it's conventional in the codebase to organize notifications into resume/suspend notification methods. That's fine, but this code isn't related to notifications. Currently this method is only called in one place anyway, so there's no change in behavior, it was just confusing to read.
ebfd9d0
to
def8eeb
Compare
The current MLNMapView supports implementers adding their own TapGesture, and even documents how: ```swift let mapTapGestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(myCustomFunction)) for recognizer in mapView.gestureRecognizers! where recognizer is UITapGestureRecognizer { mapTapGestureRecognizer.require(toFail: recognizer) } mapView.addGestureRecognizer(mapTapGestureRecognizer) ``` Unfortunately this doesn't work with NavigationMapView, which has a catch-all tap gesture the greedily consumes all taps. With this change, we will fail the gesture unless the NavigationMapView intends to handle it. Unfortunately this presents some redundant work, but I've rearranged things so that the redundant work only occurs in the case that the user has successfully selected a Route or WayPoint.
def8eeb
to
ef73edf
Compare
I am wondering, isn't it possible to change this on the client side using something like this:
|
I agree that the whole Gesture Recognizer logic is a bit odd, so improving this would be nice.
We should be sure that this actually works :).
To be honest, I think adding this to the delegate, maybe even a way to either handle taps before and taps after the waypoint/route logic isn't a bad idea either. I am not 100% sure which option would be better though and which option would be more like other iOS libs?
Yes. One thing that I am especially concerned about is the as casting. If we change the method signature this won't work anymore? I guess there is a 50% chance that we miss this in a refactor and then break the code in an unexpected way. |
Description
The current MLNMapView supports implementers adding their own TapGesture,
and even documents how to do this:
For example I use this in maps.earth for selecting POIs rendered in the map layer.
tap-poi.mov.mp4
Unfortunately this doesn't work with
NavigationMapView
, which has acatch-all tap gesture that greedily consumes all taps.
With this change, we will fail the gesture unless the NavigationMapView
intends to actually handle it by selecting a
WayPoint
orRoute
.Unfortunately this presents some redundant work, but I've rearranged
things so that the redundant work only occurs in the case that the user
has successfully selected a Route or WayPoint.
Open Tasks
none
Infos for Reviewer
This is kind of a brittle solution. There is logic mostly but not quite duplicated across two methods. I've tried to add asserts that should help keep them in sync if one is changed. I'm open to suggestions if someone has a better idea of how to handle this.
One alternative would be to add some kind of
mapView(_:unhandledTap:)
to a delegate somewhere. But would it be added to the only theNavigationMapView
which requires it orMLNMapViewDelegate
for consistency? I landed on my approach as the most consistent/least surprising based on current behavior and documentation.🚨- I haven't actually tested the
Waypoint
/Route
selection fromNavigationMapView
because I'm not using these features yet. I'd appreciate if someone who is could test this. Otherwise, I expect to add these features in the coming weeks and this could remain open until then.