ODK Collect is an Android app for filling out forms. It's been used to collect billions of data points in challenging environments around the world. Contribute and make the world a better place! ✨📋✨
Why is this the best possible solution? Were any other approaches considered?
As usual, I've updated the dependencies for the next release. However, this time, there are some significant changes in addition to the regular updates:
Switched to Gradle Version Catalog: Dependency management now uses the Gradle Version Catalog, which is the default approach for managing dependencies in new projects. It offers several advantages over the previous buildSrc module, such as faster project builds when dependencies are changed and notifications about new available versions. For details, see this commit.
Migrated to FusedLocationProviderClient: This migration was necessary to update the play-services-location library. For more information, see this commit.
Reviewed and Fixed Some PMD Rules: Over the last few dependency updates, we had disabled some new PMD rules. After a review, I re-enabled a few of them. However, others were left disabled as they either don’t make much sense, would require extensive edits across hundreds of classes, or are faulty and don’t work as intended.
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?
It's often challenging to determine what should be tested when multiple dependencies are updated. However, in this case, I can highlight one area: location recording. As mentioned earlier, we switched to a new location provider, which could be a potential source of bugs. In fact, this is our second attempt at the migration, as the first one failed due to this issue: https://github.com/getodk/collect/issues/6027. Hopefully, everything will go smoothly this time.
Do we need any specific form for testing your changes? If so, please attach one.
A form with a few geopints might be helpful for testing reading locations:
geo5.xlsx
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:
[x] added or modified tests for any new or changed behavior
[x] run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
[x] added a comment above any new strings describing it for translators
[x] added any new strings with date formatting to DateFormatsTest
[x] verified that any code or assets from external sources are properly credited in comments and/or in the about file.
Why is this the best possible solution? Were any other approaches considered?
As usual, I've updated the dependencies for the next release. However, this time, there are some significant changes in addition to the regular updates:
buildSrcmodule, such as faster project builds when dependencies are changed and notifications about new available versions. For details, see this commit.play-services-locationlibrary. For more information, see this commit.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?
It's often challenging to determine what should be tested when multiple dependencies are updated. However, in this case, I can highlight one area: location recording. As mentioned earlier, we switched to a new location provider, which could be a potential source of bugs. In fact, this is our second attempt at the migration, as the first one failed due to this issue: https://github.com/getodk/collect/issues/6027. Hopefully, everything will go smoothly this time.
Do we need any specific form for testing your changes? If so, please attach one.
A form with a few geopints might be helpful for testing reading locations: geo5.xlsx
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