Implemented flexbox layout

[grzesiek2010]

Closes #3744

What has been done to verify that this works as intended?

I tested some widgets manually and ran all automated tests.

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

I was able to get rid of a lot of code removing Grid widgets that didn't use recyclerview. That was something I had always wanted to do. I used google FlexboxLayout which allowed me not only improved the behavior described in the issue but also get rid of those Grid widgets.

	columns-pack	compact	compact-2
Before
After

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 change should improve the behavior described in the issue and also improve the way we build compact (columns-pack no buttons) widgets (widgets with images instead of radio buttons/checkboxes). It would be good to test as many select widgets as possible since the risk is related to almost all of them.

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

All widgets form
SelectsTestColumnsPack.xml.txt
and generally any form with select widgets.
The form I prepared some time ago to document selects might be helpful https://docs.google.com/spreadsheets/d/1uA6NeUbE51WACiKUjErFUxYFeJdGGWglNGKivuzei7I/edit#gid=1181650558

Does this change require updates to documentation? If so, please file an issue here and include the link below.

Probably we need to update some screenshots only but it's not very important.

Before submitting this PR, please make sure you have:

• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• 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

[seadowg]

Well this seems a lot nicer. Really happy to be getting rid of the GridWidget hierarchy 😄

[mmarciniak90]

@grzesiek2010 @lognaturel

I do like changes for these widgets

pr	v1.26.3

But I'm not a fan of causing regression on other widgets at the same time.

pr	v1.26.3

[grzesiek2010]

1. The thing with start/end margins is that now we use only RecyclerView for all select widgets what''s awesome but at the same time we don't use margins in order to make the whole screen clickable. In other widgets we just use paddings to fake those start end/margins but if I did the same here every single element would have that padding what would add too much space between elements. I think it's not a big deal We can think of improvements here but it's not important in my opinion.

Before	After

---

2. The border width is not even a regression here in fact it's a fix. Apparently GridWidgets used different sizes (look at other attachments where the border size differs) and now it's consistent

Before	After

---

3. GridWidgets didn't use paddings but if we used columns-n or columns appearances with RecyclerView padding was added so it also wasn't consistent and I tried to find balance like that. I think it looks good.

Before	After

[kkrawczyk123]

@grzesiek2010 I can see an unnecessary search text field on widgets:

• Select one widget: Select one widgets with autocomplete appearance. appearance: compact autocomplete
• Select one widget: Select one widgets with autocomplete appearance. appearance: compact no-buttons autocomplete
• Select multiple widget: Select multiple widgets with autocomplete appearance. appearance: compact autocomplete
• Select multiple widget: Select multiple widgets with autocomplete appearance. appearance: compact no-buttons autocomplete

master	Android 5.1	Android 10

There is also a difference in displayed answers in columns.
The form that I have used:
selectTest3028.zip

[grzesiek2010]

You are using autocomplete so you expect that search field. It was a bug on muster that it didn't work like that.
When it comes to:

a difference in displayed answers in columns

don't you think it's better and expected? You are using compact (which is the same like columns-pack) appearance and it should accommodate as many elements in one row as possible.

[kkrawczyk123]

@grzesiek2010 I agree that it looks better on devices with a bigger screen, not on smaller one but they are so rare so I don't think it's worth to do something about that. I've continued my testing and I have noticed that it looks badly in RTL language - answers are missing and scroll is deformed on Androids from 7-10, see the gif:

It looks in the best way on Android 5.1( list or huge space between questions):

[grzesiek2010]

What appearance is that? Does that look worse than on master?

[kkrawczyk123]

It is the form from issue, it looks much better on the master, the scroll remains untouched:

[lognaturel]

I am bothered by the left side of the choices not matching up with the question text. I would be ok with treating that as a separate issue, though, as I do think the benefits here far outweigh the inconvenience of that visual change.

Looking at it in more contexts, I also wish the vertical spacing were a little less. @grzesiek2010 I'm guessing you matched what was there for image grids? What about matching the text select vertical spacing? How does that look with images?

[grzesiek2010]

I am bothered by the left side of the choices not matching up with the question text. I would be ok with treating that as a separate issue, though, as I do think the benefits here far outweigh the inconvenience of that visual change.

The easiest solution that we could share across all widgets would be to have a global margin. The thing is that we decided to make the whole screen clickable for selects. I agreed on that but I wasn't totally convinced and now it's a problem here.
Is that really important or maybe we can change?

Looking at it in more contexts, I also wish the vertical spacing were a little less. @grzesiek2010 I'm guessing you matched what was there for image grids?

Where is it too big? Generally spacing is the same for all elements it differs only between columns-pack (compact) appearance and the others
https://github.com/getodk/collect/pull/3925/files#diff-16abb480481e8a0a0d07cf1a8bee3aa2R209
but then every element might use a different layout with different spacing so it would be good to standardize it.

Another question: can we get rid of that arrow icon that indicates it's the quick appearance? It is used only with normal selects but requires a separate layout. We don't use it with no-buttons appearance and here in case of columns-pack it doesn't make much sense too. I think there is no need to display it. The separate layout which is required just to handle that arrow cause problems with rtl languages so that's why I'm asking about here too.

[lognaturel]

we decided to make the whole screen clickable for selects

Ah, yes, now I remember what this refers to. We've seen people try to tap the very left of their screen while holding their devices and having to tap again. I do think it's important to have the tap region extend all the way to the left of the screen. I don't have enough of the layouts loaded in my brain to know what's possible. The left spacing looks great with columns-pack and it's tappable all the way to the left, right? You just can't also achieve that with columns-pack no-buttons?

Where is it too big?

You know what, I was wrong and the vertical spacing now matches all other selects which is what we want. I was referring to the vertical space between elements.

can we get rid of that arrow icon that indicates it's the quick appearance?

I think I had advocated for keeping it but really, it's not very clear what it means. Given the trouble it's causing I'm up for removing it.

[grzesiek2010]

I fixed one issue: the case where in rtl languages items were displayed in separate rows despite the fact column-pack appearance was used. However I'm not able to fix that empty space which is visible also with rtl languages:

since:

• it takes place only when we use rtl languages
• it will be visible only when we use multiple questions on one screen
• and only with columns-flex appearance

I think we can ignore it for now, as @lognaturel said:

the benefits here far outweigh the inconvenience of that visual change

so @kkrawczyk123 please file a separate issue.

I think I had advocated for keeping it but really, it's not very clear what it means. Given the trouble it's causing I'm up for removing it.

I got rid of it, @kkrawczyk123 keep it in mind.

The left spacing looks great with columns-pack and it's tappable all the way to the left, right? You just can't also achieve that with columns-pack no-buttons

would something like below would be ok?

[lognaturel]

Quick thing for the RTL columns-pack case: the label text should be grouped with the button. There's supposed to be padding after the text label to visually separate choices and it looks like that's always applied to the right. It should be applied to the end which is the left in RTL languages.

The spacing for columns-pack no-buttons in the second screenshot looks ok to me. It is a change and certainly if someone got their images just right for a particular screen size this could be problematic. I don't know how likely that is. The padding is not in fact very much, it just looks huge because the images are so small, I think. Let's put it out and see how users react. We can always go back to no padding if needed.

[grzesiek2010]

@kkrawczyk123 I think it's ready for testing again.
I noticed that text (in rtl) in radio buttons/checkboxes was displayed like:

and I fixed it but generally there are many more bugs in rtl so it's something for separate prs as long as it's not a big regression caused by this pr.

[kkrawczyk123]

Tested with success!
Verified on Androids: 5.1, 7.1, 8.1, 9.0 and 10.

Tested scenarios:

• light mode
• dark mode
• change language
• RTL language
• minimize app
• screen rotate
• forms with columns-flex appearance
• widgets with quick appearance
• regression check on different types of select one question
• regression check on different types of select multiple question

@getodk-bot unlabel "needs testing"
@getodk-bot label "behavior verified"