So I have been writing some Android code for a week or two and some layouts are self-explanatory such as gird, table, and so on. However, I am still confused about when to use Linear layouts, when to use Constraint Layouts and when shall I use Relative Layouts. I know that Google prefers Constraint layouts but, a lot of code samples use other kinds of Layouts. I am confused if I shall even prefer other kinds of layouts or not?
The idea is to get the less nesting in your layout as possible, this for performance, if the layout is quite simple and show a vertical or horizontal layout, I will use LinearLayout, otherwise I will use ConstraintLayout because it's the more powerful layout and any layout can be implemented with ConstraintLayout even the simple ones and it's the evolution of RelativeLayout, also android recommends to use that layout.
Related
just a simple question, should we always use Constraint Layout for everything? why another layout still used today?
I want to make a simple login layout like this, should I use Linear Layout or Constraint Layout?
usually, I make every layout with Constraint Layout but my friend told me to use Linear Layout for the login, is it wrong if I use Constraint Layout? thanks before!
ConstraintLayout helps you to avoid using nested layouts and it causes better performance. it's not wrong to use it for everything but if you know that you are not going to have nested layouts, for example, three Textviews respectively, you can use LinearLayout. ConstraintLayout needs more XML code than LinearLayout for simple structures, and using LinearLayout is better for these situations.
I would say ConstraintLayout is more versatile and has better performance compared to RelativeLayout, But LinearLayout has its own significance in android you can specify weights of view using LinearLayout and for complex UIs I would say going with ConstarintLayout is a better option because of its performance and in ConstarintLayout you can specify the view positions, heights, widths, margins and paddings based on screen sizes rather than hard coding the values to fixed dp
https://android.jlelse.eu/constraint-layout-performance-870e5f238100
The above link gives more overview of LinearLayout vs ConsrainLayout performances.
No it it's depends on your need, if you want to make complex layout and want to make them responsive then you can.
I can see that Google actively promotes ConstraintLayout.
Is this means that it should be used in any case where this is possible?
I mean, if we have even some simple view with one or two child views, should we still use ConstraintLayout or this is not justifiable for simple views?
I mean from the performance perspective.
Are there any restrictions where usage is forbidden?
Performance suffers when you have multiple nested views eg relative layout contains a linear layout which contains a scroll view etc etc
The nature of constraint layout is that you can achieve things possible only by nesting other views, in a single constraint layout without nesting.
As long as the simple layout does not contain nested views, there is no strong performance gain by using constraint layout.
According to #Vardaan performances improvement is seen in the application which is also given in android developer blog and using it eliminates deep nesting, but it’s way too hard to do complex layouts with it since we don't deal with simple layout now days check this
I have been mostly designing my views using Relative layout as it works great when you put things positioned from the right edge, center or simply relative to each other. That would great on different screen sizes so the views are more spread.
With the introduction of constraint layout, I find it that it is more powerfull and it achives the same purposes while giving more flexibility.
Does that mean that Relative layout is no longer needed and can be replaced with Constraint all the time? Is there a situation where you shouldn't go constraint view and go for relative layout instead?
Thank you
It is not much different than other layouts you are probably already using (like RelativeLayout or LinearLayout). The attributes are very similar to the ones used with Relative Layout.
This is primarily designed as a visually oriented tool. The visual editor is intended to be the main way developers interact with their layouts.
The main goal of this new layout, is to help developers create complex layouts that are optimized to rendez quickly. In fact, its aim is to reduce layout hierarchies induced by other layout types.
My boss refuses to let me use RelativeLayout. Everything is done using LinearLayout and minimal use of RelativeLayout, such that the layout that I could run with two levels of nesting with RelativeLayout, I now have to do with four using LinearLayout. Any comments on this? What links can share?
In my opinion it would be better to combine these two elements to get the perfect layout.
It depends on the level of nesting indeed. Android suggests to use a minimum Layouts in Layouts as possible, and if you can achieve with one layout, what you want to do with 3, why not?
The app will run faster for it, though with 2-3 nestings you wont see it.
I for example, create a bunch of included layouts, which i reuse in other layouts.
And the level of nesting could get very deep with that
With the LinearLayout we get the clear separation of view or we can say that each layout is separate. With the Linearlayout each UI element us independent of the other. You get the maximum flexibility. It enables to give the vertical and horizontal orientation.
Linearlayout you can control look more and make it almost similar even
on the device change. And also, using LinearLayout is simpler though
starting phase can be quite confusing
From the Docs
A Layout that arranges its children in a single column or a single
row. The direction of the row can be set by calling setOrientation().
You can also specify gravity, which specifies the alignment of all the
child elements by calling setGravity() or specify that specific
children grow to fill up any remaining space in the layout by setting
the weight member of LinearLayout.LayoutParams.
LinearLayout is a view group that aligns all children in a single
direction, vertically or horizontally. You can specify the layout
direction with the android:orientation attribute.
Again it depends upon your need..I also agree with #Lena Bru answer.
What Is A Relative Layout?
After linear layouts, which display controls in a single row or column, relative layouts are one of the more common types of layouts used by Android user interface designers. Much like other layouts, relative layouts can be defined within XML layout resources or programmatically in the application's Java code. The relative layout works much as its name implies: it organizes controls relative to one another, or to the parent control itself.
Get to love the RelativeLayout. It will make your life much easier, when designing for multiple resolutions/densities. If you have an old SDK, update your eclipse plugin. It has graphical snap-lines for RelativeLayouts similar to designing a form in Visual Studio, so you can see what is anchored where. It's really quite good.
google says:
Layouts are a key part of Android applications that directly affect the user experience. If implemented poorly, your layout can lead to a memory hungry application with slow UIs. The Android SDK includes tools to help you identify problems in your layout performance, which when combined the lessons here, you will be able to implement smooth scrolling interfaces with a minimum memory footprint.
I find myself using RelativeLayout more than any other types of layouts in Android XML files. Given that my apps use primarily simple and basic interfaces, it is quite easy to bang out a new RelativeLayout.
Currently I create a RelativeLayout and I assign each component of the layout properties such as Layout Below, or Layout Left, or Layout Right to anchor that component to the correct area of the user's interface.
While it's easy to define new layouts, it's hell trying to move a single component within a layout. Given that I've used components in my layout to space other components, once a component is moved, the layout around that component falls apart. Moving a component means I have to re-do the relationship for all components below that one. Surely I am doing this wrong? There must be a better way?
TL;DR I use RelativeLayouts and the components I put in the UI to space one-another relatively (of course). If I move a component say to the top, the items below it break as the relative relationship breaks. How can I more easily move components around and experiment with my UI without renaming tens of spacial relationships each time?!
This is one of the cases where the tooling is preferable over hand-coding the layout XML. Editing the XML using the Graphical Layout tab helps ease lot of this pain of refactoring RelativeLayouts. It is not the perfect solution, but it does make things a lot easier.
I should point out that these changes have come about in ADT 14 and newer. If you are using any older ADT, I suggest you upgrade. In case you do not know how to use the Graphical Editor to get the most out of your RelativeLayouts, check out this video.
Having said that, the inflexibility of RelativeLayout is the main reason I prefer using nested LinearLayouts over the former - in spite of Google's suggestions to use the former for performance reasons.
As a compromise, I use RelativeLayout only for items in a ListView, and nested LinearLayouts for everything else.
+1 for the question, since I've been looking for the solution myself. However, I think/feel the only way to do this is by declaring attributes like android:layout_alignParentBottom , android:layout_alignParentLeft etc. for the items that can afford to use those attributes, as they align with the parent, which according to my understanding is the layout itself. Otherwise, I don't see any other way with Relative Layouts. As Rafael T says, another way of binding those items to the layout is by using nested Linear Layouts. But then again, even that is a bit tedious. Finally it depends on the programmer who chooses the layout. Personally, I'd choose/prefer Relative Layouts.