Fix select_one/multiple list height

[grzesiek2010]

Closes #7310

Why is this the best possible solution? Were any other approaches considered?

The problem was caused by the fact that we always set the height of the list of choices (if it was a long list), regardless of whether the choices were displayed directly in questions or in a dialog. We don't need to do that for the dialog case.

The smallest solution would be to pass a boolean flag and only set the height when it is true, keeping the old behavior. However, this is a good opportunity to improve the approach slightly, which is what I did by passing the height directly. This has two advantages:

• We remove the responsibility for calculating the height from the RecyclerView.
• We no longer need the "guessed" number of elements (MAX_ITEMS_WITHOUT_SCREEN_BOUND) that was previously used to determine whether limiting the height was necessary or not: https://github.com/getodk/collect/pull/7311/changes#diff-345fc063e7a817a7c0a68f814d7caf8ddafa8709c69474945fad7ba9f00a33b3L29

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 reworks the way we determine the height of the list of choices displayed directly in questions or in a dialog when the minimal appearance is used.
In the dialog case, the list always takes the full screen height. However, for lists displayed directly in questions, it uses approximately 90% of the screen height. This is because answers are displayed inside a scroll view that may also contain other questions (field-list). To make this work correctly, we set a maximum height for the list.
Please test for regressions, especially that choices displayed in field-lists with other questions below them are rendered correctly in both very long list and very short list cases.

Do we need any specific form for testing your changes? If so, please attach one.

The form is linked to the issue.

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:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[WKobus]

Im not sure if it is intended change but there are 2 scrolls on select forms with images e.g. SelectIcons form from user 1291 in this project https://test.getodk.cloud/projects/425/app-users

It does not occur on newest store or master version

[grzesiek2010]

Im not sure if it is intended change but there are 2 scrolls on select forms with images

Yes. Before, we only limited the height of the list to 90% of the screen when there were more than 40 items - that's how we determined whether the list takes up too much space and should be limited (in that case, there were two scrollbars in previous versions as well). However, it wasn't perfect, as this example shows: you can have only a few items but with big images, which ends up taking a lot of space as well.
The extra scrollbar you're seeing is a side effect of limiting the height based on the real height it takes rather than on the number of items it contains.

[WKobus]

Tested with success

Verified on phone with android 10, 16 and tablet with android 16

Verified cases:

• Issue Last option not visible in minimal appearance select with many choices #7310 does not occur
• Single and multi select forms with different appearances
• Selects forms with short and long list of selects
• Select forms with images
• Select forms on a fieldlsit
• Horizontal and portrait view
• Different font sizes
• 3 button and gesture navigation in android settings
• Swipe and buttons navigation in collect
• Checks on other dialogs in app

[seadowg]

The extra scrollbar you're seeing is a side effect of limiting the height based on the real height it takes rather than on the number of items it contains.

@grzesiek2010 could we hide one of the scroll bars? Is there actually two scrollable surfaces in play?

[srujner]

Tested with success

Verified on phone with android 14

[grzesiek2010]

could we hide one of the scroll bars? Is there actually two scrollable surfaces in play?

Yes, there are two scrollable surfaces. When we limit the height of the select_one/select_multiple list to 90% of the screen and there are more choices than fit, the list itself becomes scrollable. The second scrollbar belongs to the entire ODKView, since there can be multiple questions on the screen that need to scroll together. So I think we should leave it as is.