-
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
Add 12/24 hour format Navigation View Option #805
Add 12/24 hour format Navigation View Option #805
Conversation
918a50f
to
2eb1e84
Compare
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.
Just some cleanup questions / comments.
One thing that's we also have to look at here is MapboxNavigationNotification
which also uses TimeUtils#formatArrivalTime
. We might have to move the timeFormatType
to MapboxNavigationOptions
so it can be used for both the core + UI libraries. The notification is currently created in the core library for the NavigationService
@@ -371,12 +374,15 @@ public void startNavigation(NavigationViewOptions options) { | |||
|
|||
private void setLocale(NavigationViewOptions options) { |
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 would be good to refactor this method, as it's called setLocale
but it's setting Locale
, unitType
, and timeFormatType
. For readability, it may be good to extract these each into their own private method.
boolean isDeviceTwentyFourHourFormat = DateFormat.is24HourFormat(getApplication()); | ||
String arrivalTime = formatTime(time, (int) routeProgress.durationRemaining(), timeFormatType, | ||
isDeviceTwentyFourHourFormat); | ||
summaryModel.setValue(new SummaryModel(getApplication(), routeProgress, locale, unitType, arrivalTime)); |
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.
Would it make sense to move the arrival time formatting into the SummaryModel
itself? Application
and routeProgress
are already being passed. I think it would clean up onProgressChange
It would also remove the duplicate code found in SummaryBottomSheet
@@ -40,7 +45,10 @@ | |||
private ProgressBar rerouteProgressBar; | |||
private boolean isRerouting; | |||
private Locale locale; | |||
private @NavigationUnitType.UnitType int unitType = NavigationUnitType.NONE_SPECIFIED; | |||
@NavigationUnitType.UnitType | |||
private int unitType = NavigationUnitType.NONE_SPECIFIED; |
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 makes sense to align how both the unitType
and timeFormatType
are both set to NONE_SPECIFIED
initially. Currently the time format is set in the NavigationViewOptions#builder()
, while unitType
is set here in SummaryBottomSheet
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.
Actually, I went ahead and removed the unitType
initialization here. It's not necessary because we're already initializing it in MapboxNavigationOptions#builder()
👀
Line 125 in 2975aea
.unitType(NavigationUnitType.NONE_SPECIFIED); |
988ed70
to
d4cd5da
Compare
Yeah, I noticed as well. BTW I think we should do that (consolidate Addressed the rest of the comments. This is ready for a second round of 👀 |
d4cd5da
to
34f21e6
Compare
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.
@Guardiola31337 this looks great, thanks for the updates
NavigationViewOption
If the dev doesn't provide a
NavigationTimeFormat.Type
explicitlyNavigationTimeFormat.NONE_SPECIFIED
is set (default) and the device's 24-hour format setting (DateFormat.is24HourFormat(Context)
) is used.Fixes #740
cc @danesfeder @devotaaabel