History reader #4194
History reader #4194
Conversation
…y files; added convenience inits to ReplayLocationManager and MapboxNavigationService to run history replay
…factored HistoryFileReader; code docs added
Udumft
force-pushed
the
vk/NAVIOS-666-history-reader
branch
from
db1c229 to
e72535f
Compare
Breaking Changes in MapboxCoreNavigationBreaking API Changes
|
|
|
||
| /// Provides event-by-event access to history files contents. | ||
| /// | ||
| /// Supports `pbf.gz` files. |
There was a problem hiding this comment.
This is the file extension for a compressed protocol buffer. This same file extension represent a Mapbox vector tile, a raw OSM extract, or a completely arbitrary data structure. We should be more specific, but what more can we say about the expected file format, assuming the format isn’t officially stable yet?
For what it’s worth, I think it would be wonderful if at some point we could publish the .proto file somewhere and generate support code via swift-protobuf. That would give developers the ability to introspect these files without us having to essentially reverse-engineer the format within this SDK.
| self.init(indexedRouteResponse: routeResponse, | ||
| customRoutingProvider: customRoutingProvider, | ||
| credentials: credentials, | ||
| locationSource: ReplayLocationManager(historyFileDump: historyFileDump), |
There was a problem hiding this comment.
Yes! This is exactly the original vision behind introducing ReplayLocationManager in the first place. But how important is it to provide this convenience initializer versus expecting developers to compose ReplayLocationManager(historyFileDump:) with the existing initializer?
There was a problem hiding this comment.
I'm thinking that this convenience init would help to configure replaying. It may go a bit beyond simply simulating coordinates stream, as replay probably should also restore RouteOptions or other configuration as it was recorded...
| default: | ||
| break |
There was a problem hiding this comment.
Should we add support for the other HistoryRecordTypes, GetStatus and PushHistory? At a glance, it doesn’t seem as useful as the two you’ve hooked up above, but then we should open a ticket to track that as tail work, for completeness.
There was a problem hiding this comment.
Added them as internal objects. They make next to 0 sense to users. We are not exposing navigation status publicly in RouteController so we shouldn't do it here too, and push history event parameters are cryptic even to myself.
I think current approach will allow to introduce new types of events if they arrive later.
… return types; member naming improved.
Breaking Changes in MapboxCoreNavigationBreaking API Changes
|
…history file updated
Breaking Changes in MapboxCoreNavigationBreaking API Changes
|
Breaking Changes in MapboxCoreNavigationBreaking API Changes
|
Description
Adding history reader feature to improve debugging capabilities and to support feature parity between platforms.
Implementation
Implementation is based on NN.HistoryReader which is designed to read
pbfhistory files. Added several convenience wrapper methods to access contents as well as convenience initializers to simplify history replay setup, including free drive and AG scenarios.