NN 132

[VysotskiVadim]

No description provided.

[github-actions]

Changelog

Features

Bug fixes and improvements

• Fixed an issue where DirectionsRoute#duration ignored charge time after refresh operation. [#7121](https://github.com/mapbox/mapbox-navigation-android/pull/7121)
• Improved quality of continuous alternatives, now the mechanism respects routes from current navigation session. [#7137](https://github.com/mapbox/mapbox-navigation-android/pull/7137)
• Improved EV offline navigation, now it fallbacks to a regular onboard routing. [#7137](https://github.com/mapbox/mapbox-navigation-android/pull/7137)
• Improved location simulation when DR ends, i.e. when a driver leaves a tunnel. [#7137](https://github.com/mapbox/mapbox-navigation-android/pull/7137)

Known issues ⚠️

Other changes

Android Auto Changelog

Features

Bug fixes and improvements

[VysotskiVadim]

@dzinad , @averkhaturau , as I know the notification feature isn't stable on server side and the API may change. Do I understand correctly that current implementation in NN works for current design and just stop working in case of changes on server side without crashes?

[dzinad]

I think it's finalized: https://mapbox.atlassian.net/browse/NAVAPI-37?focusedCommentId=102077

[VysotskiVadim]

I haven't found any existing filtering mechanism for RoadObjectMatcherObserver.onRoadObjectMatched. Do you think it's okay if it will be called with an internal type which is not supported yet?
cc @dzinad , @LukasPaczos , @DzmitryFomchyn

[LukasPaczos]

Could we instead pass an error with a message that this type is not supported?

[VysotskiVadim]

Could we instead pass an error with a message that this type is not supported?

@LukasPaczos , maybe don't call callback at all?

[LukasPaczos]

We're not exposing RoadObjectMatcher.matchNotificationObjects at all so do I understand correctly that it should never truly happen? In this case we could even assert 🙃

[VysotskiVadim]

We're not exposing RoadObjectMatcher.matchNotificationObjects at all so do I understand correctly that it should never truly happen? In this case we could even assert 🙃

Unfortunately I'm not really familiar with EH, but I see that route object matcher is a part of public API.

mapbox-navigation-android/libnavigation-core/src/main/java/com/mapbox/navigation/core/MapboxNavigation.kt

Line 368 in ca1cde2

val roadObjectMatcher: RoadObjectMatcher

From what I see, it can happen. @LukasPaczos , I plan to add filtering to road object matcher similar to how it works here, do you see any red flag in this approach?

[LukasPaczos]

I don't see any red flags.

[VysotskiVadim]

I explored RoadObjectMatcher and found out that it works by request and always return objects of custom type. So no filtering for notifications is needed there