-
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
Move entities package from JavaRosa #6236
Conversation
Am I understanding correctly that the next steps are to put in a JR PR to remove these same files, merge to master, do some quick QA? Is the |
Yup! There was a bit of "chicken n' egg"-ing going on here where I needed to expose scenario, move everything over and then finally delete so as not to break anything (due to auto snapshot releases).
Spot on. Basically Collect now has some code that's for its own entities implementation and then some that's its JavaRosa "plugin". |
@seadowg don't you think this pr needs testing? You didn't add the label. |
Whoops! Adding now. I usually only add it after reviewing so generally don't do it for my own PRs. Are you thinking of it the other way around? |
I don't have any strong preferences. Usually, I review and manage immediately. In such cases, I add the label. The person who merges should at least double-check tha the label is there. |
Tested with Success! Verified on a device with Android 10 Verified Cases:
|
Tested with Success! Verified on a device with Android 14 |
Blocked by getodk/javarosa#772This allows us to iterate on entities without as much back and forth between Collect and JavaRosa changes.
Why is this the best possible solution? Were any other approaches considered?
I could have converted more classes to Kotlin, but there's a lot of code here and I felt like that would easier to review on a case by case basis as we touch those classes.
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?
A lot of code has been moved, and a few things have been converted to Kotlin, so there's definitely a risk of type conversion problems. The most important things to look at will be form loading and finalization, especially for forms with entities.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest
(or./gradlew testLab
) and confirmed all checks still passDateFormatsTest