MapboxNavigationNative v18.0.1 #2477
Conversation
1ec5
added
- chore
backwards incompatible
This comment has been minimized.
This comment has been minimized.
1ec5
force-pushed
the
1ec5-nav-native-v16.0
branch
from
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.
"monotonicTimestampNanoseconds": 1595looks 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.
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.
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.
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. |
zugaldia
changed the title
1ec5
force-pushed
the
1ec5-nav-native-v16.0
branch
from
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.
1ec5
force-pushed
the
1ec5-nav-native-v16.0
branch
from
22f1b9d
to
16fb635
Compare
1ec5
force-pushed
the
1ec5-nav-native-v16.0
branch
from
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:NavigationDirectionsCompletionHandlernow accepts the original tile directory URL passed intoNavigationDirections.configureRouter(tilesURL:completionHandler:); the number of tiles added is no longer passed in.RouteControllersometimes failed to acknowledge that the user arrived at the destination.RouteController.snappedLocationwhile multipleRouteControllers are active.RouteControllertakes too long to detect that the user has gone off-route.RouteControllernow map-matches raw locations within a 100-meter search radius, up from 50 meters, to account for noisy GPS readings.ManeuverType.turnandManeuverType.reachForknow 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.primaryInstructionandVisualInstructionBanner.secondaryInstructionduring offline routing./cc @mapbox/navigation-ios @mapbox/navnative @avi-c @d-prukop