-
Notifications
You must be signed in to change notification settings - Fork 319
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
NAVAND-1472: do not always relaunch timer when routes are updated #7497
Conversation
ChangelogFeaturesBug fixes and improvements
Known issues
|
Codecov Report
@@ Coverage Diff @@
## main #7497 +/- ##
============================================
+ Coverage 74.13% 74.16% +0.03%
- Complexity 6141 6151 +10
============================================
Files 829 830 +1
Lines 32883 32927 +44
Branches 3916 3925 +9
============================================
+ Hits 24377 24420 +43
- Misses 6973 6974 +1
Partials 1533 1533
|
...ndroidTest/java/com/mapbox/navigation/instrumentation_tests/core/RouteRefreshOnDemandTest.kt
Outdated
Show resolved
Hide resolved
...ndroidTest/java/com/mapbox/navigation/instrumentation_tests/core/RouteRefreshOnDemandTest.kt
Outdated
Show resolved
Hide resolved
I'm wondering, how stable the tests are. I see many assumptions that 1-1.5 second accuracy i enough, did you check if that works? |
@@ -62,7 +62,7 @@ class RouteRefreshController internal constructor( | |||
} | |||
plannedRouteRefreshController.pause() | |||
immediateRouteRefreshController.requestRoutesRefresh(routes) { | |||
if (it.value?.anySuccess() == false) { | |||
if (it.isValue) { |
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.
why don't we resume in case of failture?
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.
Null here doesn't mean failure. Null means it wasn't executed because a newer request came along.
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.
does null mean that another request was scheduled and current is cancelled so that we don't need to resume planned refreshes?
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.
Yeah, because we'll think of that when the new request finishes, this on is just replaced by a new one.
It's not super clear, I think it'd be better to introduce some descriptive enum instead of Expected.
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 think it'd be better to introduce some descriptive enum instead of Expected.
Great idea 👍
} | ||
|
||
@Test | ||
fun route_refresh_on_demand_after_reroute() = sdkTest { |
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.
have you considered verifying behaviour in a unit test which tests RouteRefreshController
which uses real implementation or Immediate and planned route request so that only router is mocked? I think those types of situations could be emulated there.
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.
Yes. We have such unit tests. But the point here is that routes change externally (from MapboxNavigation). There is also filtering by reason there. That's why I want to check everything together here.
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.
There is also filtering by reason there.
Why not to move filtering by reason to route refresh controller?
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 updated the tests.
1c6af44
to
3def102
Compare
Looks like they are fine. |
val refreshedRoutes = listOf(it.primaryRouteRefresherResult.route) + | ||
it.alternativesRouteRefresherResults.map { it.route } | ||
routesToRefresh = refreshedRoutes | ||
scheduleNewUpdate(refreshedRoutes, false) |
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 really like that route refresh controller doesn't wait for new routes set from directions session to start the next cycle of refresh, we probably should have done it from the beginning. That decreases coupling + this dependency has never been obvious to me.
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.
++, it took me a while to understand how that works.
@@ -111,6 +111,7 @@ class RouteRefreshController internal constructor( | |||
|
|||
internal fun requestPlannedRouteRefresh(routes: List<NavigationRoute>) { | |||
routeRefresherResultProcessor.reset() | |||
immediateRouteRefreshController.cancel() |
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.
is that supposed to be called only for new routes?
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 don't think so. Otherwise we might get updated routes that are now changed.
When immediate refresh finishes, the routes might have already been changed. We'd get a race here. We'll notify RoutesObserver with old refreshed routes.
...ests/src/androidTest/java/com/mapbox/navigation/instrumentation_tests/core/RefreshTtlTest.kt
Show resolved
Hide resolved
3def102
to
d12a500
Compare
|
||
val routeOptions = generateRouteOptions(twoCoordinates) | ||
|
||
mockWebServerRule.requestHandlers.remove(failByRequestRouteRefreshResponse) |
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.
why do you remove failByRequestRouteRefreshResponse
? 🤔
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 want to replace refresh handler. For that I need to remove the old one.
listOf( | ||
RouteRefreshExtra.REFRESH_STATE_STARTED, | ||
RouteRefreshExtra.REFRESH_STATE_CANCELED, | ||
RouteRefreshExtra.REFRESH_STATE_STARTED, | ||
RouteRefreshExtra.REFRESH_STATE_FINISHED_SUCCESS, | ||
), |
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.
given the first delay of 5 seconds and the second of 2 seconds and refresh interval 3 seconds, so that 2 route refresh happen, shouldn't states contain two REFRESH_STATE_FINISHED_SUCCESS
?
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.
This one actually is duplicated by a unit test so it has to be deleted.
Wrt your question, the first attempt will fail, so no, only one success.
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.
Oh, I didn't notice NthAttemptHandler
d5f0d37
to
acf4a34
Compare
.../src/test/java/com/mapbox/navigation/core/routerefresh/PlannedRouteRefreshIntegrationTest.kt
Outdated
Show resolved
Hide resolved
7cc9b30
to
556f2ef
Compare
1b94a5d
to
fcf83fb
Compare
No description provided.