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
History replay improvements #4342
Conversation
…y to allow history parser to show this event to users; modified ReplayLocationManager to be able to replay history events in chronological order, including listening to the events; added default history events listener to MapboxNavigationService that will also set route updates from history to router.
API compatibility report for MapboxCoreNavigation: 🔴Removed Decls
Class Inheritance Change
|
Codecov Report
@@ Coverage Diff @@
## main #4342 +/- ##
=======================================
Coverage 60.59% 60.59%
=======================================
Files 189 189
Lines 21115 21115
=======================================
Hits 12795 12795
Misses 8320 8320 |
Breaking changes comments:
Marked as breaking change since it has new argument with a default value => accepting these changes
Reverted. |
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 is a good improvement to history capabilities of the SDK. However, I have some feedback and suggestions on specific areas that I think could be improved. I hope my comments were helpful.
let type: String | ||
let properties: String | ||
/// History event being pushed by the user | ||
public struct PushRecordHistoryEvent: HistoryEvent { |
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 find the naming of the struct PushRecordHistoryEvent to be a bit confusing, maybe consider renaming it to something more descriptive of its purpose. I've seen 'custom event' is used throughout of the PR indicating that maybe 'CustomHistoryEvent' is a better naming.
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.
Naming for this event was meant to reflect HistoryRecording.pushHistoryEvent
method as this is the way such events are created. I am not sure if CustomHistoryEvent
would continue that relation, even though technically it is a custom history event.
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 find this name difficult to read due to the usage of first push
word which reads as a verb at first. Up to you to keep it that way (given that the same naming is used in NavNative) or rename to CustomHistoryEvent
as verb 'custom' also used in this method comment.
public let timestamp: TimeInterval | ||
/// The event type in the events log for this custom event. | ||
public let type: String | ||
/// The data value that contains a valid JSON attached to the event. |
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 comment mentions the term 'valid JSON', but it's not clear what exactly is meant by this. It would be helpful if the documentation could provide more information and examples of what constitutes a 'valid JSON' in the context of the SDK.
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.
'valid JSON' means its syntactic validity. How could I emphasize it more? There are no requirements to the contents of this data since it's filled by the user.
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 now understand what you mean by 'valid JSON', thanks for clarification, but the same question might be asked by other developers. I think if we a reference that this json is from HistoryRecording.pushHistoryEvent
it would greatly improve clarity.
Events listener that will receive history events if replaying a `History`. | ||
*/ | ||
public var eventsListener: ReplayManagerHistoryEventsListener? = nil | ||
|
||
/** | ||
`simulatesLocation` used to indicate whether the location manager is providing simulated locations. | ||
- seealso: `NavigationMapView.simulatesLocation` |
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.
btw, I have never see custom seealso
rendered properly by Xcode.
@@ -829,6 +838,16 @@ extension MapboxNavigationService { | |||
} | |||
} | |||
|
|||
extension MapboxNavigationService: ReplayManagerHistoryEventsListener { | |||
public func onEventPublished(_ manager: ReplayLocationManager, event: HistoryEvent) { | |||
if let setRouteEvent = event as? RouteAssignmentHistoryEvent { |
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 noticed that the code only replies to one particular event from the history, not all of them. Can you explain the reasoning behind this design choice?
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 handler only tracks RouteAssignmentHistoryEvent
to loop any events when route was changed (by user, via re-routing or any other way) to reproduce the history as close as possible. Other events are location updates (which are already forwarded inside the replay manager), status updates and custom user events which are not relevant for replaying history trace and thus ignored.
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 would be helpful if you could add a brief comment from what you just said, as it's not immediately clear from the code. This would greatly aid in maintaining and understanding the codebase for future developers.
…breaking change by introducing new initi; style improvements
…ordHistoryEvent to UserPushedHistoryEvent
Thanks for the feedback, I think I've now addressed it all. |
Description
This PR improves history replaying capabilities by exposing more public history records types and modifying
ReplayLocationManager
to replicate all stored history events in chronological order, includingsetRoute
events and actually setting them to the router.Implementation
Made
PushRecordHistoryEvent
public; refactoredReplayLocationManager
to work with events feed and added a listener to report occurred events to.