Prevent "Check for errors" result snackbar from reappearing on rotation

[dimwight]

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 like resetValidationResult.

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:

• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[lognaturel]

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 resetValidationResult on the ViewModel would be more elegant. I'd tend to go in that direction but I also feel like this is pragmatic. @seadowg, we must have solved this problem elsewhere in the codebase, is there a set pattern used for that?

For whatever it's worth, others do this kind of casting too.

[seadowg]

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.

[dimwight]

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.

[seadowg]

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.

[srujner]

Tested with Success!

Verified on Android 13

Verified cases:

• Issue "No errors found.." snackbar reappears after rotation #5678 is no longer reproducing;
• Don't keep activities enabled/disabled;
• Rotate the screen, minimize the app during Check for error dialog;
• Quick check on Audit files