Performance impact from using RelativeLayouts near the top of your view hierarchy
As explained in this article on performance in Android, a RelativeLayout requires two layout passes to render properly. For complex view hierarchies, this can have a significant impact on performance. Nesting RelativeLayouts makes this problem even worse, because every RelativeLayout causes the number of layout passes to go up.
Every single ViewGroup (e.g. LinearLayout, RelativeLayout, CoordinatorLayout, etc.) needs to store information about its children's properties. About the way its children are being laid out in the ViewGroup. This information is stored in objects of a wrapper class ViewGroup.LayoutParams.
To include parameters specific to a particular layout type, ViewGroups use subclasses of ViewGroup.LayoutParams class.
Most of ViewGroups reutilize the ability to set margins for their children, so they do not subclass ViewGroup.LayoutParams directly, but they subclass ViewGroup.MarginLayoutParams instead (which itself is a subclass of ViewGroup.LayoutParams).
LayoutParams in xml
LayoutParams objects are created based on the inflated layout xml file.
All parameters that begin with layout_ specify how the enclosing layout should work. When the layout is inflated, those parameters are wrapped in a proper LayoutParams object, that later will be used by the Layout to properly position a particular View within the ViewGroup. Other attributes of a View are directly View-related and are processed by the View itself.
layout_width, layout_height and layout_gravity will be stored in a LinearLayout.LayoutParams object and used by the LinearLayout
gravity, text and textColor will be used by the TextView itself
layout_width, layout_height and layout_weight will be stored in a LinearLayout.LayoutParams object and used by the LinearLayout
background, scaleType and src will be used by the ImageView itself
Getting LayoutParams object
getLayoutParams is a View's method that allows to retrieve a current LayoutParams object.
Because the LayoutParams object is directly related to the enclosingViewGroup, this method will return a non-null value only when View is attached to the ViewGroup. You need to bare in mind that this object might not be present at all times. Especially you should not depend on having it inside View's constructor.
If you want to depend on having LayoutParams object, you should use onAttachedToWindow method instead.
Casting LayoutParams object
You might need to use features that are specific to a particular ViewGroup (e.g. you might want to programmatically change rules of a RelativeLayout). For that purpose you will need to know how to properly cast the ViewGroup.LayoutParams object.
This might be a bit confusing when getting a LayoutParams object for a child View that actually is another ViewGroup.
IMPORTANT: The type of LayoutParams object is directly related to the type of the ENCLOSINGViewGroup.
The CoordinatorLayout is a container somewhat similar to FrameLayout but with extra capabilities, it is called super-powered FrameLayout in the official documentation.
By attaching a CoordinatorLayout.Behavior to a direct child of CoordinatorLayout, you’ll be able to intercept touch events, window insets, measurement, layout, and nested scrolling.
In order to use it, you will first have to add a dependency for the support library in your gradle file:
The number of the latest version of the library may be found here
One practical use case of the CoordinatorLayout is creating a view with a FloatingActionButton. In this specific case, we will create a RecyclerView with a SwipeRefreshLayout and a FloatingActionButton on top of that. Here's how you can do that:
Notice how the FloatingActionButton is anchored to the CoordinatorLayout with app:layout_anchor="@id/coord_layout"
app:layout_scrollFlags="scroll|enterAlways" is used in the Toolbar
app:layout_behavior="@string/appbar_scrolling_view_behavior" is used in
the ViewPager properties
A RecyclerView is used in the ViewPager Fragments
Here is the layout xml file used in an Activity:
Creating LinearLayout programmatically
FrameLayout is designed to block out an area on the screen to display a single item.
You can, however, add multiple children to a FrameLayout and control their position within the FrameLayout by assigning gravity to each child, using the android:layout_gravity attribute.
Generally, FrameLayout is used to hold a single child view. Common use cases are creating place holders for inflating Fragments in Activity, overlapping views or applying foreground to the views.
It will look like this:
Gravity and layout gravity
android:layout_gravity is used to set the position of an element in
its parent (e.g. a child View inside a Layout).
android:gravity is used to set the position of content inside an
element (e.g. a text inside a TextView).
Which gets rendered as following:
GridLayout, as the name suggests is a layout used to arrange Views in a grid. A GridLayout divides itself into columns and rows. As you can see in the example below, the amount of columns and/or rows is specified by the properties columnCount and rowCount. Adding Views to this layout will add the first view to the first column, the second view to the second column, and the third view to the first column of the second row.
You can use the Percent Support Library by adding the following to your dependencies.
If you wanted to display a view that fills the screen horizontally but only half the screen vertically you would do thie following.
You can also define the percentages in a separate XML file with code such as:
And refer to them in your layouts with @fraction/margin_start_percent.
They also contain the ability to set a custom aspect ratio via app:layout_aspectRatio.
This allows you to set only a single dimension, such as only the width, and the height will be automatically determined based on the aspect ratio you’ve defined, whether it is 4:3 or 16:9 or even a square 1:1 aspect ratio.
RelativeLayout is a ViewGroup that displays child views in relative positions.
By default, all child views are drawn at the top-left of the layout, so you must define the position of each view using the various layout properties available from RelativeLayout.LayoutParams.
The value for each layout property is either a boolean to enable a layout position relative to the parent RelativeLayout or an ID that references another view in the layout against which the view should be positioned.
Here is a screenshot how this will look like:
One of the most used attribute for LinearLayout is the weight of its child views. Weight defines how much space a view will consume compared to other views within a LinearLayout.
Weight is used when you want to give specific screen space to one component compared to other.
weightSum is the overall sum of weights of all child views. If you don't specify the weightSum, the system will calculate the sum of all the weights on its own.
layout_weight specifies the amount of space out of the total weight sum
the widget will occupy.
The output is:
Now even if the size of the device is larger, the EditText will take 2/4 of the screen's space. Hence the look of your app is seen consistent across all screens.
Here the layout_width is kept 0dp as the widget space is divided horizontally. If the widgets are to be aligned vertically layout_height will be set to 0dp. This is done to increase the efficiency of the code because at runtime the system won't attempt to calculate the width or height respectively as this is managed by the weight. If you instead used wrap_content the system would attempt to calculate the width/height first before applying the weight attribute which causes another calculation cycle.
This modified text is an extract of the original Stack Overflow Documentation created by following contributors and released under CC BY-SA 3.0