I came through many examples in internet.I found that neither Relative Layout nor Linear Layout supports android:layout_gravity.By it I mean the views inside these layouts does not support android:layout_gravity attribute. So any one having idea which layout supports android:layout_gravity and how to use it in better way?
Children (that is, direct descendants in the View hierarchy) of LinearLayout do use layout_gravity (see LinearLayout.LayoutParams), but only on the "secondary" axis. So, in a vertical LinearLayout, center_horiztonal will work, but center_vertical will do nothing.
Children of FrameLayout also support layout_gravity (see FrameLayout.LayoutParams).
Keep in mind that the layout_* parameters set values in a LayoutParams object provided by the view parent. So a layout_* parameter will only have an effect if the parent view supports the parameter.
Actually if you use RelativeLayout you don't need to use layout_gravity.Better way to position your layout's elements are android. Here you can get a good explanation how to use RelativeLayout.
Related
I'm new to Android development so this might be an obvious question, but I've looked at multiple sources and can't find the answer. If you put widget elements inside a layout element then the parent of those widget elements is the layout element, right? So what is the parent element of the layout? Because in the default generated file, activity_main.xml (for the layout), there is the attribute android:layout_width="match_parent" for the topmost constraint layout element. So, what is the parent of this constraint layout element?
Your ConstraintLayout is the root layout of your Activity but it is just part of a layout created by the system.
You can for example get the reference of the parent layout of your ConstraitLayout:
ViewGroup layoutRoot = findViewById(android.R.id.content);
When you set match_parent, your View (a Layout is a ViewGroup which is just a View) will try to fill the space available in its parent layout. So, in a certain way, it just tell to how much your view can grow in the X/Y-axis. In your case, your ConstraintLayout will grow in order to match that android.R.id.content
Of course, there's one View on the top of the stack (probably the decorView of your Window) which is created by the System and is assuming whole area available on the Window created by the system.
Basically we use parent layout as Linear Layout/Relative Layou/ConstraintLayout/Frame Layout etc. So all are classes which extends ViewGroup. Please refer to Google developer documentation for better understanding.
Read this -
https://developer.android.com/reference/android/view/ViewGroup.html
match_parent is a fixed value for views to stretch according to their parents.
For example let's say you have a Textview inside a RelativeLayout. If the Textview is set to match parent then it would stretch according to its parent/rootview which is the Relative layout.
So basically it would have as the same height and width as the parent layout.
Let's say I have two views that I want to center vertically. The first view is bigger than the second view.
I noticed that if I place theses two views inside a RelativeLayout with properties layout_height="wrap_content" and android:gravity="center_vertical" nothing happens. This is what I get :
In the opposite, if I place these two views inside a LinearLayour with properties layout_height="wrap_content" and android:gravity="center_vertical" the views are centered vertically :
Lastly, if I place these two views inside a RelativeLayout with properties layout_height with a fixed height and android:gravity="center_vertical" I get the same result as the LinearLayout. The views are centered vertically.
I would expect the views to be centered vertically in each case. Do you know the reason for this difference?
LinearLayout handles all its child object based on its orientation (Horizontal or vertical). So when you are saying gravity: "center_vertical". You are actually referencing based on your parent layout.
In case of RelativeLayout,it enables you to specify the location of child objects relative to each other (child A to the left of child B) or to the parent (aligned to the top of the parent).
Personally I would use gravity only in LinearLayouts and the centerInParent for RelativeLayouts.
In your first case it'll work with RelativeLayout as you expected if you use android:layout_centerVertical="true" to the child view which you want to be centred.
So in case of LinearLayout you need to specify the orientation first (i.e. horizontal/vertical) so that the child views are inflated based on the reference of your parent layout.
While in RelativeLayout, as the name says it all, you can specify the position with respect to the views which are the child of a parent RelativeLayout.
Now the views you want to achieve can be generated in many other ways too.
For example, set your parent layout as LinearLayout. Don't specify any gravity attribute in the parent layout. Hence, you set a layout_gravity attribute to the child to certer_vertical and this should work too.
Well, after some others tests, it seems that the behavior of android:gravity for a RelativeLayout is a bit random. I will just avoid to use is.
I would like to know which is more profficient way of placing children in RelativeLayout. There are two approaches of doing this:
1) Place the main view with absolute position (like layout_centerInParent or set margins/paddings correspondent to parent view) After that you add other views and set them attributes like android:layout_above="#id/relative_view_id" and place them below relative view. It is not good way because your views hierarchy in xml does not match to what you see in preview.
2) You assign to children of RelativeLayout attributes with absolute id android:layout_above="#+id/relative_view_id" (+ appeared). It provides the correct views order in xml. BUT when you looking for declaration of view with relative_view_id from java code (by pressing cmd+B) Android Studio suggests all the views where you declared #+id. In our case View with attribute android:layout_above="#+id/relative_view_id" will also appear in search results.
What is your way of placing Views in RelativeLayout?
android:layout_above
Positions the bottom edge of this view above the given anchor view ID.
Accommodates bottom margin of this view and top margin of anchor view.
For your question I would prefer No 1 way .
android:layout_above="#id/relative_view_id"
Its refer the already generated id (relative_view_id) .
We can get the relative position of a View, in pixels, using getLeft(), getTop() etc.
Is there any tag to do the reverse in a layout xml?
Something like android:layout_left="30dp" or something?
You are certainly welcome to use padding (e.g., android:paddingLeft) and margins (e.g., android:layout_marginLeft) to influence the position. However, the position is controlled primarily by the layout rules for the particular container that you are using (LinearLayout, RelativeLayout, etc.).
Ok so imagine a situation where you have the main layout as LinearLayout (which supports layout_weight) and inside it you have nested RelativeLayout (which does not support layout_weight).
Now since the RelativeLayout is nested inside LinearLayout, will it be able to use layout_weight ? And if the case was reversed (Linear inside Relative), will LinearLayout be able to use layout_below, layout_toParentLeft, etc ?
Now since the RelativeLayout is nested inside LinearLayout, will it be able to use layout_weight ?
No. Since RelativeLayout is nested inside LinearLayout it can be given a weight to be weighted inside the LinearLayout but it does not inherit the property of weightSum to hand out to children.
And if the case was reversed (Linear inside Relative), will LinearLayout be able to use layout_below, layout_toParentLeft, etc ?
Yes, you are inside of a RelativeLayout so any child can be given those properties. However, any child inside of that nested LinearLayout can not use the properties of RelativeLayout as in your example.
WeighSum Docs
a number greater than 0.0f, or a number lower than or equals to 0.0f
if the weight sum should be computed from the children's
layout_weight"
android:weightSUme="aNumber" can be used to "sum" the weight of the children. If all the childrens sums will add up to 1 then you don't need this property. As I recently learned from #RomainGuy through a discussion with #Squonk, it is really only needed if they won't equal 1 and you want some empty space in your layout. Otherwise, the cpu will determine what the weightSum will be.
The answer to your question is not very complicated. I can synthesize it in two letters: NO