Date Picker Constraint Issue Fix. #2514
Conversation
AdityaKBhadragond14
requested review from
santosh-pingle and
a team
as code owners
...main/java/com/google/android/fhir/datacapture/views/factories/DatePickerViewHolderFactory.kt
Outdated
Show resolved
Hide resolved
...main/java/com/google/android/fhir/datacapture/views/factories/DatePickerViewHolderFactory.kt
Show resolved
Hide resolved
I have addressed the comments. Please do a re-review. Thanks. |
...main/java/com/google/android/fhir/datacapture/views/factories/DatePickerViewHolderFactory.kt
Outdated
Show resolved
Hide resolved
AdityaKBhadragond14
requested review from
aditya-07 and
jingtang10
as code owners
|
It seems the build is failing on few tests in QuestionnaireUiEspressoTest. It's not available via kokoro logs here and we are working on it via this ticket Issue/2515. In the meantime these are the errors:- This should be an easy fix. Requesting you to fix these and upload a commit. It will automatically merge the PR. |
Sure @MJ1998 . I will do it. Thanks. |
| (questionnaireViewItem.minAnswerValue as? DateType) | ||
| ?.value | ||
| ?.localDate | ||
| ?.atStartOfDay( | ||
| ZONE_ID_UTC, | ||
| ) | ||
| ?.toInstant() | ||
| ?.toEpochMilli() | ||
| ?: localDate?.atStartOfDay(ZONE_ID_UTC)?.toInstant()?.toEpochMilli() | ||
| ?: MaterialDatePicker.todayInUtcMilliseconds() |
There was a problem hiding this comment.
some of this can probably be simplified, the conversion from local date to epoch milli is the same for the min value and the local date input, so you can simplify this code a bit by rewriting that.
but the bigger question is why this logic is written as such - you're reading from the questionnaire constraint's min value, and if it's missing, then you take the input value (which could have been an input from before, and then if that's also missing, you take today's date. and then you set this as the selection. and then you use this for two things: 1) the selection for the date picker and 2) the min date for the calendar constraint. i don't really understand why this is done this way.
to me, a perhaps much simpler fix is to simply not set the selection below:
.setSelection(selectedDateMillis)
if the selection will not make any sense. have you tried removing this line?
in that case i'd imagine the behaviour of the date picker will be that you cannot click ok since there simply isn't any possible date to choose from that would satisfy the calendar constraints.
have you tried that? i feel that's a more logical fix.
There was a problem hiding this comment.
Hi @jingtang10 , this makes sense. Removing the .setSelection(selectedDateMillis) will disable the "ok" button and enable only when selected a date. I think this could be more better fix than what I had proposed. Thanks for pointing it out.
IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #2508
Description
The MaterialDatePicker Builder has been modified such that if the questionnaire item has the minimum date extension added then the MaterialDatePicker.setSelection() will have that minimum date from extension else it will get the local date. This way it will select the first valid date based on the constraints added for date.
Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?
Type
Bug Fix
Screenshots (if applicable)
Checklist
./gradlew spotlessApplyand./gradlew spotlessCheckto check my code follows the style guide of this project../gradlew checkand./gradlew connectedCheckto test my changes locally.