Why would someone use weights 2:4 instead of weights 1:2? I am looking through a Udacity course layout. It's a LinearLayout with two children views. and the children are given weights 2 and 4 respectively as opposed to 1 and 2. Why is that?
Because they wanted to? The actual values don't matter, the ratios are all that does. Usually when you see that its code that evolved over time, they originally had something in there with weight 1 and removed it (while weights don't need to be whole number, most people try to keep them that way).
Related
There is a dialogue, in one place of which I need to show either one element or another, depending on the situation. Example:
I would like to do this so that the elements below do not move. I want to keep the area occupied by alternating elements of a constant size.
What is the easiest way to do this?
I can, of course, manually change the visibility. Вut when switching, if there is a different height, then the underlying elements will jump. I can manually set their height equal, but this is inconvenient. It will be necessary to correct the heights of all alternating elements every time after I change one of them.
For example, Qt has Stack Layout that allows you to alternate elements and takes the size of the largest of them. Does Android have something like this?
You might be able to use the ViewSwitcher to hold the two layouts.
It holds 2 different child views and measures its height to the biggest child by default.
Here's the documentation for it: https://developer.android.com/reference/android/widget/ViewSwitcher
Just an idea if you can't find something like Stack Layout. I haven't tried it.
You can put all the elements in an horizontal LinearLayout with MATCH_PARENT width for the visible one and 0 for the invisible ones, but keeping all of them VISIBLE. It should always have the largest height and only the MATCH_PARENT width element should actually be visible.
I am trying to have 3 LinearLayouts ordered horizontally (basically forming three columns) within another LinearLayout where the width of the middle layout can vary depending on it's content.
All columns should be visible at all times filling the viewport from left. The left and irght column will be assigned a max width. So only the size of middle layout varies. If the total width of all columns exceeds the viewport size the middle column must not overlap or push out the other columns. But instead it should use the remaining space.
I tried using layout weights but that would put the right column always on the right side and the middle column would fill up all the space even though it's content would not require that.
When I try to use a RelativeLayout as a container I either end up with all three columns overlapping each other or the first column disappears.
I thought the below code (only schematic for now, as I don't have access to the code atm) should work, but as written above the first LinearLayout does not show up. The last LinearLayout seems to be in place as desired.
<RelativeLayout>
<LinearLayout
android:layout_alignParentStart>
</LinearLayout>
<LinearLayout>
</LinearLayout>
<LinearLayout
android:layout_alignParentEnd>
</LinearLayout>
</RelativeLayout>
Does anyone know how I can fix this? Please let me know if you need more detailed code examples etc. I will try to provide them as soon as possible.
I found a few other questions concerning this or similar topics but the solutions always used either layout weights or something like the code snippet above. So far I had no luck with those approaches, maybe because those questions where either for slightly different use cases or a few years old so that the api has changed in the mean time.
Any pointers are greatly appreciated :-)
Yes. You want to defined the center columns with a layout_width="0dp" and a layout_weight="1". The left and right columns will be layout_width="wrap_content".
A LinearLayout should contain the 3 inner "column" LinearLayouts.
I finally found a solution that works.
Using the layout_weight as describe by Jeffrey Blattman alone does only work when the views get large enough to fill the screen.
But as long as the views only fill a part you get gaps between them as the middle view fills up the remaining space. This is something I want to avoid in this case.
For some other reason I had to put my layout into a fragment. Now when I set the dimensions of the fragment to wrap_content the behavior is exactly as I want it. So the views do not get blown up while they are to small but are laid out as if there was no layout_weight defined. But still when growing larger the edge views stay within the screen.
I've one of the simplest layouts imaginable: A num pad.
I want to create a fragment containing a 3 x 4 grid of buttons. The layout should automatically resize the num pad to fill the available space.
I've learned, that GridLayout is not up to the task, and TableLayout/TableRow or nesting LinearLayouts means nesting weights, which is also discouraged for performance reasons. A RelativeLayout won't work either, because that requires at least one button with given dimensions.
So, is there a clean way to create a regular grid that will resize to fill its parent?
Any help is appreciated, thx!
You will need a custom compound control.
Check the following link:
http://developer.android.com/guide/topics/ui/custom-components.html#compound
Make the control fill the available space. Make it to have 12 buttons. Calculate the size and position of them based on their position and the available space.
Depending on your needs you might also need to override onMeasure() and onLayout() defined earlier in the above document, in the "Fully Customized Components" section.
It's just freaking me out, but I can't make my layout depend on weight. There are two relative layouts and two linear layouts and some elements in both of these layouts. I've put android:layout_weight="0.2 to the first one, android:layout_weight="0.1 to the second one, android:layout_weight="0.5 to the third one, and android:layout_weight="0.2 to the last one. The sum is 1, right? But it doesn't work. I'm afraid, it's because of different layout_height and maybe different categories of layouts? The XML-code is here
My experience with the layout_weight attribute is the following:
Set all layout_height (or width depends on what you are doing) to fill_parent or wrap_content (it should be the same value for all elements). Try both versions. Sometimes wrap_content is better sometimes fill_parent is better.
There are many theories about the mystic of the layout_weight attribute.
This is my version^^
Edit: I forgot to mention, that the logic is inverted: the less weight the bigger the element.
I have experienced that setting the width or height (depending on which direction you want your layouts to span) to 0 can be usefull from time to time.
It is possible that you might need to use the value "0.4f", when you use values > 1.
You could also try setting the weight_sum to an amount (in your example it could be 10) and then use the layout_weight values 2, 1, 5 and 2 - but I'm not sure that it will make a difference.
I have referred to this site for Layout Tricks.
Over there one attribute is declared as android:layout_weight="1".
So my confusion is regarding android:layout_weight:
where is the exact use of android:layout_weight ?
Where should we use android:layout_weight ?
From what I understand of layout_weight, the closest comparison I could find is when you pass some % in HTML for the width or height of your div. In our context, the weigth seems to refer to the % of width or heigth your widget should get for itself compared to its neighbours in a given ViewGroup. You can find another exemple with more explanation here.
If you look the way they use it, it sticks exactly to the definition. They give a height of 0dip to keep the whole space free, and then uses equal weigths for the 2 widgets to make same th same height.
layout_weight is quite simply a priority to apply to a view class, the higher, the larger the control or group will be in proportion to it's mates inside that group. The default is 0, so a weight of 1 makes it twice as large as other default controls. No mystery.