-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Schedule form updates only if relevant settings have changed after import #6814
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
Conversation
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.
Ace! I think for master, would you consider a follow-up where we just pass through all the changes keys to onSettingsChanged instead of just a flag for form update settings? I think that would then allow us to just have one piece of logic around reacting to key changes.
Yeah, I considered that solution, but I felt it would take a bit more time. I will do that after reviewing your pr: #6811 |
|
Confirming I no longer see the loading indicator (with this APK) after tapping 'Start new form' with the 'Settings JSON' parameter enabled. Thanks for the quick fix! |
|
Tested with Success! Verified on a device with Android 10 Verified cases:
|
|
Tested with success Verified on device with Android 15 |
Schedule form updates only if relevant settings have changed after import
Schedule form updates only if relevant settings have changed after import
Closes #6810
Why is this the best possible solution? Were any other approaches considered?
To summarize all the discussions we've had across different channels:
The issue was that when MDM applied settings to Collect, those settings were re-applied every time the Main Menu was opened. After saving the settings, the form update process was triggered, which meant it ran every time a user returned to the Main Menu to start a new blank form. If the form that needed to be updated (or even just checked for updates) included a large number of media attachments, the process became time-consuming. Additionally, if such a form contained entities, opening it was blocked until the update process completed.
I didn't change the approach of continuously saving settings. Instead, I updated the code responsible for triggering form updates so that the update is now triggered only when relevant settings have actually changed. The relevant settings are:
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?
This should prevent redundant form update scheduling when new settings are applied - whether they come from MDM and are re-applied every time the Main Menu is opened, or when a user reconfigures the app using a QR code that doesn't change anything related to form updates (i.e., the two settings mentioned above).
Do we need any specific form for testing your changes? If so, please attach one.
Any form with entities + thousands of media files.
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 connectedAndroidTest(or./gradlew testLab) and confirmed all checks still passDateFormatsTest