-
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
Optimize redownloading entity forms #6376
Conversation
c37dc4c
to
eb4bb68
Compare
a6b69a3
to
a3a102b
Compare
@lognaturel I've got a few more changes to make here (the current optimization around skipping extra saves is probably buggy), but it'd be interesting to get your Pixel 3a numbers here. I'd like to update the benchmark targets so that it passes on both the FP3 and that device. |
@@ -184,31 +184,6 @@ class LocalEntityUseCasesTest { | |||
assertThat(songs[0].branchId, equalTo(offline.branchId)) | |||
} | |||
|
|||
@Test | |||
fun `updateLocalEntitiesFromServer overrides offline version if the online version is the same`() { |
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.
@lognaturel I'm not sure if this is behaviour we want or not so I wanted to call it out. It seems much simpler to me for the client to assume that if its local version and the server version of an entity are the same that the data (label and properties) will also be the same. I think this is the case when using Central as edits/fixing conflicts would always increment the version? If that's not the case and Central can return a matching version number with different data, then I can call this out with a more explicit test.
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.
@lognaturel and I chatted about this, and we actually want to do the opposite so that the entity "metadata" and data are always in sync. We also want to make sure that trunkVersion
and branchId
make sense in cases where the server has different data, but the same version. I'll make changes to this.
a8af2c0
to
4667073
Compare
entities/src/main/java/org/odk/collect/entities/LocalEntityUseCases.kt
Outdated
Show resolved
Hide resolved
entities/src/main/java/org/odk/collect/entities/LocalEntityUseCases.kt
Outdated
Show resolved
Hide resolved
...ct_app/src/main/java/org/odk/collect/android/database/entities/DatabaseEntitiesRepository.kt
Outdated
Show resolved
Hide resolved
...ct_app/src/main/java/org/odk/collect/android/database/entities/DatabaseEntitiesRepository.kt
Outdated
Show resolved
Hide resolved
entities/src/main/java/org/odk/collect/entities/LocalEntityUseCases.kt
Outdated
Show resolved
Hide resolved
entities/src/test/java/org/odk/collect/entities/LocalEntityUseCasesTest.kt
Outdated
Show resolved
Hide resolved
collect_app/src/test/java/org/odk/collect/android/entities/EntitiesRepositoryTest.kt
Outdated
Show resolved
Hide resolved
entities/src/main/java/org/odk/collect/entities/storage/Entity.kt
Outdated
Show resolved
Hide resolved
...ct_app/src/main/java/org/odk/collect/android/database/entities/DatabaseEntitiesRepository.kt
Show resolved
Hide resolved
Pixel 3A:
When manually opening the form after, I got the following exception
I believe that was because an update was happening in the background as I tried to open, does that sound right (so related to #6232)? |
Interesting! It looks to me like we'll get that for any filtered entity list when opening the view hierarchy (in debug builds) because select choices are loaded on the UI thread there. I'm guessing fixing this is going to be a lot of work, so I might have to look at disabling the strict mode check there for now. |
Digging into it, it doesn't feel like the best use of my time to work around the broken form hierarchy at the moment. I'm going to pull this out as an issue as we can always just disable StrictMode for a bit if we need to. |
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.
There is still one question unanswered #6376 (comment) plus this test name that should be improved.
collect_app/src/test/java/org/odk/collect/android/entities/EntitiesRepositoryTest.kt
Outdated
Show resolved
Hide resolved
entities/src/main/java/org/odk/collect/entities/LocalEntityUseCases.kt
Outdated
Show resolved
Hide resolved
Good question! That was the case before the PR right? There was no visible update to the forms if the CSV wasn't updated (we just don't do any extra work we don't have to now). I think that's expected right now. As far as I'm concerned, we're not really optimizing the entities experience for manual downloads (although they are very useful for testing different scenarios), but it might be something we want to tweak if we do see a lot of entities use with them. |
Yes |
Tested with Success! Verified on a device with Android 10 Verified Cases:
|
Tested with Success Verified on device with Android 14 |
Closes #6344
Closes #6389
Blocked by #6372Why is this the best possible solution? Were any other approaches considered?
There are two keys changes here that lower subsequent download times (with or without changes):
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?
The main changes and risks are again all around form update for entity follow-up and update forms.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest
(or./gradlew testLab
) and confirmed all checks still passDateFormatsTest