Implement likert option functionality in Collect #3431
Conversation
…es correctly now. If there are any errors or there are less or more choices than 5 it will not render.
…, text will be shown if image not found, removed likert_icon variable and number of buttons depend on the number of choices given
…hidden and fixed issue of display name instead of label
…ess if it crosses the limit when it will be capped to 95x95
…into likert-testing
…into likert-testing
|
@seadowg We actually added the lines because it simplified things more actually. If we were to add margins they would need to be the same length as the lines anyways. The complication with the margins would be getting it to be the right length with different phone sizes while adding a line with the match parent attribute does it for us. |
collect_app/src/androidTest/java/org/odk/collect/android/formentry/LikertTest.java
Outdated
Show resolved
Hide resolved
collect_app/src/main/java/org/odk/collect/android/widgets/LikertWidget.java
Outdated
Show resolved
Hide resolved
|
I have tested on Androids 4.2 4.4, 5.1, 6.0, 7.1, 8.1, 9.0 and 10 - and I have noticed just one small issue, when I change the language to RTL the scale is reversed in the proper way but the lines are not, they have gaps, see attached screenshots: |
|
@kkrawczyk123 Is there a way to know if an RTL language has been chosen upon rendering? |
|
|
|
@kkrawczyk123 This issue should be fixed now! |
|
@shouryaj |
|
@grzesiek2010 @seadowg @shouryaj @andrewsiew2 @estberg @PieterBenjamin @Joseph-Schafer My thinking was that it would take a fair amount of effort to rework the history for not much benefit. Luckily there are no conflicts and since the feature is relatively stand-alone, I think squashing down to one commit on merge will provide sufficient context. The unfortunate thing is that several people contributed to this effort and the single commit would be attributed to @shouryaj. I was thinking that we could credit everyone in the commit details. |
|
Tested with success!
@opendatakit-bot unlabel "needs testing" |
Closes #1272
What has been done to verify that this works as intended?
We have written espresso tests to verify functionality. We have also extensively stress tested the likert widget with different forms.
Why is this the best possible solution? Were any other approaches considered?
We first started out with using a static XML, but soon realized that this approach would require a lot of XML manipulation from Java. Instead we decided to follow the already existing practices used by the other widgets.
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 should be no regression risks since we simply added an extra widget.
Do we need any specific form for testing your changes? If so, please attach one.
Form is attached. To test images, edit the form with the name of the image you want to test.
likert_test.xlsx
Does this change require updates to documentation? If so, please file an issue here and include the link below.
Link to issue: getodk/docs#1135
Before submitting this PR, please make sure you have:
./gradlew checkAlland confirmed all checks still pass OR confirm CircleCI build passes and run./gradlew connectedDebugAndroidTestlocally.