Fix: recenter doesn't immediately take effect #53
Conversation
Note: I only ever reproduced the bug in the context my app, which uses this library via Ferrostar, while using the CoreLocationProvider, not the SimulatedLocationProvider. But I expect this to be an issue for anyone using this API. To reproduce the bug in my app: Setup: (all of this is working more or less as expected): - While stationary (not sure if this is required) - start a route - see the user location puck and map centered on my location on the ground. - pan the map off the route - see the user location puck disappear, but you still see the smaller location indicator on the map. (as expected) - see the "recenter me" button appear - tap the "recenter me" button Now here's the problem: At this point I'm expecting the map to recenter with the user location puck on my location on the ground. But instead, I see the user location puck centered at the *current* map position - where I'd previously panned to, *not* at my location on the ground. Interestingly, if you'd repeat the process at this point - panning and then re-tapping the "center me" button, it would *work* this second time. --- The new behavior is definitely an improvement. However, if you've zoomed way out while exploring the map away from your route, there is a slightly noticeable two-part action while we wait for the new completion block - first re-centering and then zooming. It's unquestionably better than the current behavior though.
No worries 😂 And yeah, there's a lot of contributor overlap because so far every regular contributor has been using it for navigation ;) Thanks for looking into this; I've also noticed it in my separate demo app that uses live location. This appears to fix the issue as I've observed it. |
michaelkirk
force-pushed
the
mkirk/re-center
branch
2 times, most recently
from
299885a
to
e8d1113
Compare
|
I've now also run into the same issue and @michaelkirk's changes resolves that for our code base as well - but I've just kept the .zero frame check in place instead of deleting them. See https://github.com/maplibre/swiftui-dsl/compare/main...HudHud-Maps:maplibre-swiftui-dsl-playground:camera-conversion-improvements-plus-tracking-fixes?expand=1 - this also includes #54 |
ianthetechie
added
norelease
There was a problem hiding this comment.
Yes, the zero check is needed. I was able to verify the changes @hactar made, which include that check, fix the broken example behavior.
Thanks guys!
ianthetechie
added
the
release:minor
|
Thank you for resolving this. |
FIXES: stadiamaps/ferrostar#274
Sorry for the cross-org issue, I didn't realize the source of the issue, and it seems like the venn diagram of contributors is a circle anyway.
Note: I only ever reproduced the bug in the context my app, which uses
this library via Ferrostar, while using the CoreLocationProvider, not
the SimulatedLocationProvider. But I expect this to be an issue for
anyone using this API.
To reproduce the bug in my app:
Setup: (all of this is working more or less as expected):
ground.
indicator on the map. (as expected)
Now here's the problem:
At this point I'm expecting the map to recenter with the user location
puck on my location on the ground.
But instead, I see the user location puck centered at the current map
position - where I'd previously panned to, not at my location on the ground.
Interestingly, if you'd repeat the process at this point - panning and
then re-tapping the "center me" button, it would work this second time.
The new behavior is definitely an improvement. However, if you've zoomed
way out while exploring the map away from your route, there is a
slightly noticeable two-part action while we wait for the new completion
block - first re-centering and then zooming. It's unquestionably better
than the current behavior though.