Our Android project currently declares ArcGIS Maps SDK for Kotlin 300.0.0. We use CustomLocationDataSource to display fixes from external GNSS receivers, including receivers that provide decoded location data rather than NMEA sentences.
We are investigating reports of delayed map-position updates and position or accuracy inconsistencies when using external GPS. We would like to validate our custom provider against the intended SDK contract; we have not established that the SDK causes these symptoms.
Our CustomLocationDataSource.LocationProvider supplies separate Flow<Location> and Flow<Double> streams. We convert each external Android location to an ArcGIS Location using WGS84 coordinates, horizontal and vertical accuracy, speed, and course. For external receivers, the heading flow derives heading from the fix's bearing. Our Location.create call does not explicitly pass the receiver's original fix timestamp. Some unavailable or invalid accuracy and motion values are currently converted to 0.
Could you advise us on the following?
- How should a custom source represent unavailable accuracy, speed, course, or heading? Could using 0 for a missing measurement affect how LocationDisplay treats a fix?
- How should we preserve or validate the receiver's original fix time? Should the provider discard stale or out-of-order fixes before emission, particularly after a reconnect or source change?
- Is deriving the separate heading stream from the fix's bearing appropriate? Are there ordering or synchronization requirements between the location and heading flows?
- What buffering, update-rate, or instrumentation guidance would help us distinguish delays before our provider emits a fix from delays in CustomLocationDataSource or its on-screen display? Does LocationDisplay animate or interpolate incoming positions?
For external receivers that do not provide NMEA, is CustomLocationDataSource the recommended approach? Beyond the basic sample, what guidance can you give us for a production implementation handling fix freshness, missing measurements, reconnects, and variable update rates?
