Hello :)

hello, Kai!

how can I help you today?

While I was doing a custom button, I defined its size with "dpi". And wondered if that is the way to go.

do you mean dp?

(or possibly the older dip equivalent)?

I meant to write "dip" :D

dip and dp are the same; we tend to use dp nowadays

Should all elements that are not constrained by the very edges around them have a "definitive" size?

I use "dip" alot because I like it more. "device independent pixels" = "dip"

I think we settled on dp because all the other ones are two letters as well

but dip was used a lot in the early days, and from your experiences, presumably it still works :-)

in terms of whether your button should be sized in dp, that is partially a question for your designer and partially a question of whether the button has a text caption or not

if it has a text caption, I'd lean towards sp, to take the user's chosen font scale into account

and the designer may have had other sizing rules in mind (e.g., 40% of the screen width)

It's more the question if all elements need some sort of non-relative size

relative sizes are fine, so long as they look the way you want on all screen sizes

and, if you include wrap_content in "relative sizes", that's fine so long as it looks the way you want with widely varying content

you can use things like android:minWidth, android:minHeight, android:maxWidth, and android:maxHeight to help manage wrap_content behavior in a ConstraintLayout

and you can use text autosizing to allow text to shrink if needed

Do you implement "mostly relative" layouts often=?

Or is it the exception?

there are two types of projects that I work on: ones where there are graphic designers, and my own projects

for my own projects, I try to use what I think you mean by "relative sizing", so the UI can hold up under varying screen sizes

with graphic designers, I wind up in the dual problem of "they call the shots" and "they really can't be bothered with multiple screen sizes", so I tend to have to "wing it" a bit more to come up with something that hits their designs and still holds up on varying screen sizes

the designs that the designers come up with usually are very nice, but the details that I get do not take varying screen sizes into account, so it is difficult to tell what a certain dimension really means if the screen is smaller or larger than the canvas the designer used

Let's say you have a screen with four "fields", to choose one of four options to go forward. How would you implement the layout of such fields?

ummm... a column? I guess I don't really understand the scope of your question

It's hard to come up with examples of what I mean :D

I don't really know how to phrase my question.

perhaps a better approach is to point me to a screenshot of some mobile screen and ask how I would implement it

after all, a picture is worth (checks calculator) a thousand words

(approximately)

You have a "calculate picture to words" button on your calculator? That's awfully nice

programmable calculators FTW!

I have implemented "Buttons" similar to the ones in above links

yeah, I think you gave me that screenshot before, as it looks familiar

My version sports a "highlight" bar and changes the background when selected, but it's the same idea.

is this a fixed grid? or are there N buttons that wind up in a grid RecyclerView?

In my case it's a fixed 2x2 grid in portrait and 1x4 in landscape.

OK, let's talk portrait first

the buttons are square, and you want them to fill the width of their container (e.g., the screen)?

Let's assume yes

OK, that container then should be a ConstraintLayout

you have two main choices for setting the horizontal sizing:

1. use percentages for the widths of the buttons and the widths of the margins

2. use conventional fixed-sized margins and use a chain to allocate the remaining width evenly between the two buttons

(BTW, by "buttons", I mean the rounded rectangle -- we'll talk implementation of the buttons themselves in a bit)

I'd try option #2 first, as margins-as-percentages could get messy

a "weighted chain" (with equal weights) and margins should give you your even sizing

then, use layout_constraintDimensionRatio to have the buttons be equal height to their allocated widths

(basically, a 1:1 ratio)

that should get you your 2x2 grid -- for the 1x4 grid, you'd do the same basic thing with right aspect ratio

with me so far?

I think so. Would I not scale the text in any way?

we haven't gotten to the interiors of the buttons yet

right now, pretend the buttons are empty rounded rectangles

Ok. Let's go :D

Let's drop the "rounded" btw

I'm going based on the screenshot, as that's all I have

And make them normal equally-sized rectangles (== squares)

translating these instructions to your real use case is left as an exercise for the reader :-)

*shuts eyes*

;-)

Ok, we got the button shape and positions.

so now, let's talk about the button interiors

this is a case where the screenshot alone isn't really sufficient -- I'd talk to the designer if I had one

if this design came to me in a dream, and I didn't have a designer...

since we need a background (in the screenshot, the rounded rectangle), we need a container for the icon and caption

I'd use a nested ConstraintLayout here, so the overall UI is a ConstraintLayout holding onto four nested ConstraintLayouts, the latter being your buttons

the sticky wicket is in trying to interpret how much of the space goes to the icon vs. the caption

I'd probably take a shot at setting the height of the icon to a % of its container (the button's ConstraintLayout), and using the aspect ratio to control its width

You'd set the rounded rectangle via the background of the underlying container?

yes

huh

so the ConstraintLayout for the button would have an android:background attribute

in your case, with the "selected" concept, that's probably a StateListDrawable of some form

I'd set the height of the text to fill the remaining space after the icon's height plus margins

i.e. android:layout_height="0dp" in ConstraintLayout terms

and I'd set up the autosize attributes to ensure that my text didn't run out of room

that would be my first stab at this -- sometimes, my guesses as to the right types of constraints do not work, so I'd have to experiment

but, in theory, that would get you what you want

(again, relative to that screenshot)

Interesting

What are the autosize attributes?

(and where that page says "Support Library", think "Jetpack")

Won't that make you end up with different text sizes in similar elements?

if your minSdkVersion is below 26, you would use the app: prefix instead of android: so the Jetpack handles those

yes

at least, if things get long

typically, I aim for everything to be the same font size and fit at the designer's dimensions

however, on smaller screens, or for German translations, the text needs to shrink

that shrinking might not be even, because the translations might not be even

if that would be a big problem, and you need to somehow synchronize the text sizes across four TextViews based on which one needs the smallest text...

...well, let's just say that https://xkcd.com/1425/ comes to mind

X)

but an answer of "we're going to keep the same text size, and if the text gets cut off, that's too bad" is a non-starter to me

so, I'd rather have varying font sizes and ensure everything is readable, despite the screen size and translation lengths

OK, that's all the time I have for today's chat

next one is Thursday at 7:30pm US Eastern

have a pleasant day, and stay healthy!

Have a good time