-
Notifications
You must be signed in to change notification settings - Fork 312
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
MapboxNavigationNative v18.0.1 #2477
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
This comment has been minimized.
This comment has been minimized.
ceeb5fe
to
924ef91
Compare
I’ve upgraded to v17.0.1. So far, I’ve only ensured that the targets compile (other than #2499) and the example and CarPlay example applications launch without crashing. I’ve also updated the documentation. Other than that, tests are still crashing. |
I've tried to run Navigation SDK example and was able to compile it successfully. Though getting such behavior right away: Actually we're getting
History: @SiarheiFedartsou, @mskurydin, can you please take a look at this one? Is there any additional info I can provide which can be useful for you? |
@MaximAlien Also I see one more thing in the provided trace:
UPDATE |
@@ -11,7 +11,7 @@ extension FixLocation { | |||
|
|||
// In practice, “submillisecond precision” is 10 nanosecond precision at best, but convert the timestamp to nanoseconds anyways. | |||
// Unlike on Android, we aren’t concerned about the timestamps’ monotonicity. | |||
let timestamp = location.timestamp.timeIntervalSince1970 * 1e-6 | |||
let timestamp = location.timestamp.timeIntervalSince1970 * 1e6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"monotonicTimestampNanoseconds": 1595
looks weird.
Turns out I was passing in megaseconds instead of nanoseconds. 🤦
We’re down to the following test failures:
|
@@ -208,7 +208,7 @@ class NavigationServiceTests: XCTestCase { | |||
altitude: 0, | |||
horizontalAccuracy: 30, | |||
verticalAccuracy: 10, | |||
course: -finalHeading, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m surprised we got away with this until now, but negating a CLLocationDegrees
makes it invalid rather than pointing it in the other direction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, when I read docs here it states A negative value indicates that the course information is invalid.
@@ -208,7 +208,7 @@ class NavigationServiceTests: XCTestCase { | |||
altitude: 0, | |||
horizontalAccuracy: 30, | |||
verticalAccuracy: 10, | |||
course: -finalHeading, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, when I read docs here it states A negative value indicates that the course information is invalid.
SKU token tests have suddenly started failing:
Locally, I’m seeing these warnings in the console when running the example application in this repository:
This is a serious issue: it means nondeterministic behavior at runtime and likely conflicting, unrelated implementations for MBXAccounts. |
I do not have enough context yet, but probably one of the ways to fix duplicated symbols warning is to build |
Those symbols are implemented in Swift and don’t bridge to Objective-C, so their runtime names are already prefixed with the Turf module name and mangled, avoiding any potential for collision. |
02fbe93
to
22f1b9d
Compare
Not sure what’s up with codecov, but we definitely didn’t just drop this much in test coverage. |
The navigator needs nanoseconds, not megaseconds.
Previously, the test attempted to simulate making a wrong turn by negating the expected final heading and using that as the course of the location update. But a negative course is an invalid course that we avoid passing along to the navigator. The correct way to turn in the opposite direction is to add 180°.
… contains updated MapboxCommon version 4.0.0.
The idea behind introducing the monotonicTimestampNanoseconds parameter to FixLocation was apparently that the navigator could rely on a guaranteed monotonic value to sort locations and detect and discard any jumps in time that may be caused by changes to or unreliability in the system time. The timestamp in each location update serves a somewhat different purpose than a monotonic counter, since it corresponds specifically to the time at which the system thinks it received the location update. A significant amount of time may have elapsed since the location update, and that gap may not be consistent between location updates, a fact that would be obscured by relying on the monotonic counter instead of the location timestamp. To avoid misunderstandings about the origin and behavior of the timestamp, this change goes back to specifying only a conventional timestamp and leaving the monotonic counter unspecified.
22f1b9d
to
16fb635
Compare
16fb635
to
b2e8f8d
Compare
Still getting this error intermittently:
|
Upgraded to MapboxNavigationNative
v16.0.0v17.0.1v18.0.0v18.0.1. Notable changes in this upgrade compared to what’s in the release-v1.0-pre-registry branch:NavigationDirectionsCompletionHandler
now accepts the original tile directory URL passed intoNavigationDirections.configureRouter(tilesURL:completionHandler:)
; the number of tiles added is no longer passed in.RouteController
sometimes failed to acknowledge that the user arrived at the destination.RouteController.snappedLocation
while multipleRouteController
s are active.RouteController
takes too long to detect that the user has gone off-route.RouteController
now map-matches raw locations within a 100-meter search radius, up from 50 meters, to account for noisy GPS readings.ManeuverType.turn
andManeuverType.reachFork
now indicate the name of the intersection, if available, during offline routing. (Update the turn and continue phrases to include junction names and guide signs valhalla/valhalla#2386)VisualInstructionBanner.primaryInstruction
andVisualInstructionBanner.secondaryInstruction
during offline routing./cc @mapbox/navigation-ios @mapbox/navnative @avi-c @d-prukop