You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To leverage any future location provider enhancements, we should publish a uniffied device speed through the location provider and state. This will allow a simple default implementation in the views as noted with #247
Created this so #89 can be closed with the current annotations MR #261
The text was updated successfully, but these errors were encountered:
What needs to be added here exactly? This is already part of the UserLocation struct which is published from the LocationProvider implementers (and contains GPS speed, not the less accurate derived speed; I should document that more clearly perhaps?).
It also ends up in TripState indirectly through SnappedLocation, but IMO this is better to get either directly from the location provider or, if needed in the UI, it of course ends up in UI state. On iOS, this would be accessible via snapped location, and on Android we now bubble up the "raw" location (which is more obvious than the snapped one) in the UI state as of #250.
TL;DR, I think this is already published, we can make views today based on the Speed model, and any UserLocationshould already be publishing the more accurate speed info derived from GPS.
That should work, I think this may be more of an implementation detail of our dynamic zoom (and whatever else). Similar to the annotation publisher as seen in #287. I just didn't want to have to combine a bunch of source data to make use of speed and navigation state 😄
To leverage any future location provider enhancements, we should publish a uniffied device speed through the location provider and state. This will allow a simple default implementation in the views as noted with #247
Created this so #89 can be closed with the current annotations MR #261
The text was updated successfully, but these errors were encountered: