In android studio, in design section, Layouts and Containers are categorized separately.
What is the fundamental difference between them?
Layouts all directly extend ViewGroup. The Layout suffix is part of the class name for classes in this group, e.g. LinearLayout, RelativeLayout.
Containers is a bucket description for Views that wrap dynamic content. They are more specialized than Layouts and can but don't have to extend a Layout. Some extend ViewGroup indirectly e.g ListView, some don't e.g. VideoView. The Container label is used in Android Studio but is not part of the class name.
I would define the differences as follows:
Layouts are general-purpose ViewGroups dealing directly with graphical views. They have no requirements on what kind of children they can manage.
Containers fulfill more specific tasks, that's why they have additional requirements on how many and which kind of children they can accept. Because of that most containers require writing Adapter classes in order to express those requirements.
A container is a view used to contain other views. Android offers a collection of view classes that act as containers for views. These container classes are called layouts, and as the name suggests, they decide the organization, size, and position of their children views.
Layouts are basically containers for other items known as Views, which are displayed on the screen. Layouts help manage and arrange views as well. Layouts are defined in the form of XML files that cannot be changed by our code during runtime.
Related
I read this here:
Android provides a number of ready-made views that you can use to
design and organize your layout. "Widgets" are views that provide a
visual (and interactive) elements for the screen, such as a button,
text field, checkbox, or just an image. "Layouts" are views derived
from ViewGroup that provide a unique layout model for its child views,
such as a linear layout, a grid layout, or relative layout. You can
also subclass the View and ViewGroup classes (or existing subclasses)
to create your own widgets and layouts and apply them to your activity
layout.
If I am not wrong, this means people can even design their own widgets and layouts? Does that ever happen? Any examples?
this means people can even design their own widgets and layouts?
Yes.
Does that ever happen?
Yes.
Any examples?
There are hundreds of examples out on the Android Arsenal alone. Just looking at a couple of columns of the recent items, there are the following custom widgets and containers:
material-drawer
Material Design Android Library
StarBar
AndroidProgressLayout
DiscreteSeekBar
Android-SingleInputForm
SunDate Picker
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 need to implement an overlay (translucent) screen for my app, something similar to Showcase View
My guess was to use FrameLayout for this usecase, because it is used to stack items on top of each other. But I was surprised to see that the above library uses RelativeLayout.
My question is when to use FrameLayout then, if not in cases like this? What are the disadvantages if I go the FrameLayout way?
A common rule of thumb when choosing layouts is to select the combination that results in the smallest number of nested layout views.
Specific to your question, RelativeLayout is larger and more capable than the much simpler FrameLayout. So for simple layouts, the latter is probably more efficient. But if using RelativeLayout and it's added positioning options allows you to implement your GUI in a smaller number of layout views, then that would likely be a better choice.
Here's a page that discusses some trade-offs and demonstrates some helpful tools to use when designing your layouts. It mostly talks about RelativeLayout and LinearLayout, but is also apropos to your choice between RelativeLayout and Framelayout. Just keep in mind that FrameLayout is an even simpler layout.
Edit (2017): For even more complicated layouts, you may be able to avoid nested layouts by using ConstraintLayout.
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.
What are the differences between <\include> tag and <\ViewStub> tag and which one is preferrable while designing the layout.
The < include /> will just include the xml contents in your base xml file as if the whole thing was just a single big file. It's a nice way to share layout parts between different layouts.
The < ViewStub /> is a bit different because it is not directly included, and will be loaded only when you actually use it/need it, ie, when you set its visibility to VISIBLE (actually visible) or INVISIBLE (still not visible, but its size isn't 0 anymore). This a nice optimization because you could have a complex layout with tons of small views or headers anywhere, and still have your Activity load up really fast. Once you use one of those views, it'll be loaded.
include
It is used to reuse layout resource
ViewStub
It is used to lazily inflate layout resource
Sharing and reusing layouts is very easy with Android thanks to the tag, sometimes even too easy and you might end up with user interfaces that contain a large number of views, some of which are rarely used. Thankfully, Android offers a very special widget called ViewStub, which brings you all the benefits of the without polluting your user interface with rarely used views.
A ViewStub is a dumb and lightweight view. It has no dimension, it does not draw anything and does not participate in the layout in any way. This means a ViewStub is very cheap to inflate and very cheap to keep in a view hierarchy. A ViewStub can be best described as a lazy include. The layout referenced by a ViewStub is inflated and added to the user interface only when you decide so.
Another important difference is related to layout inflating. with it is not possible to change the layout already static inflated in XML, it is necessary to replace the view and set programmatically al the layout parameters.
With it is possible to define (for e.g.) height, width, etc... and inflate different layout at runtime time