Fix DB ANRs during form entry #5867
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
seadowg
force-pushed
the
db-anr
branch
2 times, most recently
from
bdea42d
to
1ae3580
Compare
seadowg
commented
Dec 13, 2023
| override fun onChanged(o: T) { | ||
| data = o | ||
| latch.countDown() | ||
| this@getOrAwaitValue.removeObserver(this) |
There was a problem hiding this comment.
This didn't work with cases where there was already a value set on the LiveData.
seadowg
force-pushed
the
db-anr
branch
2 times, most recently
from
fcd3f6d
to
6fda2a9
Compare
seadowg
force-pushed
the
db-anr
branch
2 times, most recently
from
1382368
to
a6d1ec4
Compare
* Move select with CSV to feature level * Remove tests for features covered by other tests * Delete FormNavigationTest as it feels like our feature tests now cover navigation pretty well
grzesiek2010
requested changes
Jan 17, 2024
collect_app/src/androidTest/java/org/odk/collect/android/support/TestScheduler.kt
Outdated
Show resolved
Hide resolved
collect_app/src/main/java/org/odk/collect/android/external/FormUriActivity.kt
Outdated
Show resolved
Hide resolved
collect_app/src/main/java/org/odk/collect/android/external/FormUriActivity.kt
Show resolved
Hide resolved
collect_app/src/test/java/org/odk/collect/android/external/FormUriActivityTest.kt
Outdated
Show resolved
Hide resolved
...ndroidTest/java/org/odk/collect/android/feature/formentry/ExternalSecondaryInstanceTest.java
Show resolved
Hide resolved
|
Looks like that last commit has broken an instrumentation test, so will mark this as a draft for the moment while I fix. |
grzesiek2010
approved these changes
Jan 22, 2024
|
Tested with Success! We didn't found any strange behaviors or issues related to the Form Entry in General |
|
Tested with Success! |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Blocked by #5836Work towards #5838
Fixes DB ANRs caused by DB access on the UI thread for the form entry flow (the bits covered by tests at least).
The main changes here:
I also ended up introducing Kotlin's Flows as an alternative to
LiveDatain one particular place (inBlankFormListViewModel). This was because I needed to do a DB lookup in a ViewModel based on the value of aLiveData. This is doable, but ends up being pretty clunky as observations are always run on the UI thread (which keepsLiveDatanice and safe), so we'd be jumping back and forwards between threads.Flowlets us choose where transformations/observations are run (similar to RxJava). I've made sure that we can useFlowwithSchedulerso that we're not deviating from our existingasyncsetup.Why is this the best possible solution? Were any other approaches considered?
I'd have preferred to move all the forms/instances DB operations to the background and be able to have the
StrictModecalls constrained to justDatabaseConnection, but it started to feel like too much work for one PR - fixing the cases within the form entry flow felt like a good chunk of progress in the end.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?
There's definitely a bunch of risk to form entry in general here, but there's nothing specific I'd have in mind to test. Playing around with form entry and seeing if there are ways to break it is all I can suggest really! It's not worth trying to reproduce the ANRs as none of them are going to be easy to recreate reliably.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest(or./gradlew testLab) and confirmed all checks still pass