I'm on a quest to learn how to layout components properly in Android. I'm a seasoned CSS/MXML developer and am having the hardest time getting a full understanding of layout properties in Android components.
One thing is I'm not sure the differences between these:
layout_margin vs. padding
layout_gravity vs. gravity vs. ignoreGravity
Should you use one over the other with Linear, Table or Relative Layouts? An example of something I'd like to learn is having an overall margin on a layout with separate components relating to the top/middle/bottom of the screen. The sdk docs are a good start, but they don't show how things work in different situations.
Any tips on where to go to learn a more complex/comprehensive layout design?
Any attribute with the prefix layout_ is a LayoutParams attribute. While most view attributes are parsed during view construction by the view itself, LayoutParams are special arguments to the parent view that provide hints about how the parent should size and position the child view. Which LayoutParams are valid on a view depends entirely on the type of the parent view.
layout_margin is therefore an instruction to a parent view that supports margins. It says, "put this much space between me and other views or the edge of the parent." Padding is space inside a view between
the view's edges and its content.
layout_gravity is gravity for a single child within its parent. gravity affects the contents of the view it appears on.
Which one you use depends on the result you want to achieve. If you want a layout to have a fixed amount of space between its edges and all of its contents, you want padding. If you want to move the layout's own edges in by a certain distance, you want margins. When you have layouts without backgrounds set, these two can be visually equivalent. When you start creating complex UIs where layouts have 9-patch backgrounds that visually group the contents the differences become apparent.
I hope you can see the difference between padding and margin. Padding is inside spacing while margin is outside spacing.
Related
I have a screen which basically consists of 2 parts
upper is a hierarchical structure of multiple LinearLayouts with regularly changing TextViews,
lower is a heavy for drawing custom view.
Currently the TextViews in the upper part have wrap_context set to their width, as a result every their change cause Android to relayout the whole page, including the hard for drawing custom view in the lower part.
My question - Is there another way to solve this problem except changing layout_width parameter for changing TextViews to constant value?
Create LinearLayout to be parent with vertical orienetation. Now create two children LinearLayout with vertical orienetation but with layout_height to 0dp for each and layout_weight to 1 for each respectively.
I'm developing an android calendar app so I need to align the days in a grid-like style. I'm using the API Level 8 so I need to align them by margins. But when switching to Bigger screens the numbers get to the left of screen and do not cover the whole screen.(I know that is because I use dp as a unit for my margin-left). Is there something like CSS % (percent) in Android Layouts?
Try this
android:layout_weight="1"
on each element in that section. It should space evenly.
It's weight attribute for views inside LinearLayout. Here is a good explanation what it means. But you can use it only to set view sizes, not margins. However you can put your view into RelativeLayout, place this layouts to take all available screen width and set attribute centerInParent=true in your view.
I have an application where I want to achieve a layout where the product image will be in the background and top of that to the right bottom, I want to place the price of the product and to the left bottom I want to place an add button.
Should I use frame layout or relative layout ???
As a practical rule, I think it's up to you. I personally tend to use RelativeLayouts because they're more flexible, but you can achieve the same effect with either.
This SO post explains the performance differences between the two layouts in more detail: FrameLayout vs RelativeLayout for overlays
Relative layout: When you have relation between siblings or parent.
Frame layout: When siblings are placed independent of each other and are only dependent on parent.
Based on your situation, you can opt in of any of these.
My advice, If you have specific size for your background for each device, then go for relative layout, and set the background to your image. Because when using background in RelativeLayout, It'll fit the size of the relative layout itself, whether the image suits the size of the RelativeLayout or not. (Can be stretched/pixelated/Not properly added)
If you're not sure about specific size, you should use FrameLayout, with ImageView, that handles the ScaleType, which can be centerCrop, and it'll fit the layout in good shape.
And for the TextView, use layout_gravity, which will handle the position based on the parent layout.
I'm working on the controls for a game, and require part of the control panel (gray in the figure below) to change dynamically, either showing a single canvas (left) or 5 buttons (right). The border between the lower-row views should always be positioned at exactly the same x-position as the border between the buttons on the upper row, as shown. At the same time, all twelve upper buttons should be scaled and distributed evenly.
I've considered several approaches, but as of yet none do all of what I want:
Using two LinearLayouts, one for each row of controls: reliably aligning the borders seems to be impossible, and replacing part of the layout is difficult at best.
Using a TableLayout: again, replacing a portion of the layout is difficult.
Using a RelativeLayout: resizing and aligning buttons independently of the screen size doesn't seem possible
Any suggestions for an alternative method, or on how to make one of the above approaches work? It would also be nice if there were some way to animate the change of views, i.e. sliding in the buttons from the left over the canvas. Thanks!
Interesting, I've done this several weeks ago. What I did is to make use of this property of View object: "Visibility". So that means at a fixed position, I can set any View to display on to, not depending on any type of Layout, it can be Visibility.GONE, Visibility.VISIBLE or Visibility.INVISIBLE.
In my app, I used RelativeLayout to set relative position to the right side TextView.
Give it a try :)
In order to close this question: I have solved the problem by writing a custom layout class that places and sizes the child views without heeding the measured size of the children. Effectively this gives me the behavior of a linear layout with layout weights, but is more deterministic with border placement.
A ViewAnimator is used to switch between the Canvas and the Buttons.
I'm trying to layout a set of horizontal and vertical buttons. The problem is that if I indicate 'layout_weight' for buttons, their dimensions don't follow the 'layout_width' & 'layout_height' tags.
Here's what I'm trying to achieve
So, buttons must have identical height & width and distribute evenly horizontally and vertically.
Can anyone suggest a solution please?
Thanks
UPDATE: After a lot of investigation and trying out different solutions, I came to a conclusion that my only option is to create my own custom layout and place buttons correctly there.
That configuration (the L shape) might make this a tad trickier... since the corner button might size like it's horizontal counterparts or it's vertical counterparts, depending on which linear layout they are apart of. In any event, you should be using wrap_content for the height or width, and they should all have a weight of 1. It's my understanding that the wrap_content for the height or width is important for the Linear Layout to size them correctly. It might work with fill_parent when the weights are all 1, but if you use different weights on different Views with fill_parent, things won't appear as you expect.
If you can't make it work with linearlayout and weights (which you should be able to do), you could always try to do some manual workarounds using relativelayout.