-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Prevent "Check for errors" result snackbar from reappearing on rotation #5691
Conversation
Thanks, @dimwight, and it's nice to see you again! I know we haven't always been very good at responding to your PRs and I'm going to make an effort to stay on top of it. That said, I'm not very deep in Collect code these days so I'm going to need a double check from others. Conceptually, it does feel like the view code should be clearing out the validation result. I agree For whatever it's worth, others do this kind of casting too. |
@@ -562,6 +566,7 @@ private void setupViewModels(FormEntryViewModelFactory formEntryViewModelFactory | |||
swipeHandler.setBeenSwiped(false); | |||
} else if (validationResult instanceof SuccessValidationResult) { | |||
SnackbarUtils.showLongSnackbar(findViewById(R.id.llParent), getString(org.odk.collect.strings.R.string.success_form_validation), findViewById(R.id.buttonholder)); | |||
((MutableLiveData) validation).setValue(null); |
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'm not a fan of casting here as it breaks the encapsulation of FormEntryViewModel
- FormFillingActivity
is making an assumption about the return type of getValidationResult
that the type information itself doesn't back up.
We do have a way of dealing with these "single fire events" when using LiveData
: Consumable
. There's an example of this in use in ProjectPreferencesFragment
.
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.
Thanks for the tip, a bit advanced for me but I got it to work after some puzzling.
I've also tested with a dummyFailedValidationResult
.
And thanks @lognaturel for the kind welcome, it's nice to be back.
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.
Great!
We'd usually want a test for this, but it's currently a bit of a headache to add unit tests for FormFillingActivity
and this regressing wouldn't be a major enough problem to make that effort worth it at the moment.
Tested with Success! Verified on Android 13 Verified cases:
|
Closes #5678?
What has been done to verify that this works as intended?
Tested manually.
Why is this the best possible solution? Were any other approaches considered?
Seems to be "the simplest thing that could possibly work". More elegant alternatives could be to change the signature of
FormEntryViewModel.getValidationResult
to reflect the actual class; or completely encapsulate with something likeresetValidationResult
.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Behaviour is now as expected. Doesn't break any tests.
Do we need any specific form for testing your changes? If so, please attach one.
No?
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew checkAll
and confirmed all checks still pass OR confirm CircleCI build passes and run./gradlew connectedDebugAndroidTest
locally.