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.
Related
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.
I was ready some articles about performance optimization for android layouts. Most of them recommended using RelativeLayouts over other layouts because this might help you avoid Nested Layouts, that consume memory.
Personally, I believe that every thing has its Advantages and Disadvantages. But I could not figure out the disadvantages of the RelativeLayouts over the different types of layouts.
What is the disadvantages of RelativeLayouts?
When I should avoid using RelativeLayouts?
Thanks in advance.
For me, RelativeLayout is too much time consuming if you have to reorganize your components. That is the biggest downside.
For this reason, I would say RelativeLayout are really good as top level layout, and bottom level layout. But the mid-level layouts, are better served using the taylored (Linear, Table...) layout.
For example, when creating a form, the very top layout of my Activity or Fragment will be a RelativeLayout, but my form will be created as one big vertical LinearLayout. And inside this Linear, each line will be a RelativeLayout in which I will have a Text View and an Edit Text.
This way I can very easily sort the fields of my form and (I think) I keep my layout memory friendly by not overusing nested LinearLayout.
Relative Layout is the most used layout in most cases and from my experience, no disadvantage using this layout.Like I said before pick whichever is the best for the job, and worry about performance later.
update :
I copied comment from Is a RelativeLayout more expensive than a LinearLayout?
In a talk at Google I/O 2013 (Writing Custom Views for Android),
Romain Guy clarified the misunderstanding that caused everyone to
start using RelativeLayouts for everything. A RelativeLayout always
has to do two measure passes. Overall it is negligible as long as your
view hierarchy is simple. But if your hierarchy is complex, doing an
extra measure pass could potentially be fairly costly. Also if you
nest RelativeLayouts, you get an exponential measurement algorithm.
https://www.youtube.com/watch?v=NYtB6mlu7vA&t=1m41s
https://www.youtube.com/watch?v=NYtB6mlu7vA&t=38m04s
https://developers.google.com/events/io/sessions/325615129
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.
What purpose does FrameLayout serve in Android? Is there any specific scenario for which it is designed for?
In my Android application, I have a scenario where I have to show two ImageViews, one over the other. This is a .png image file with a 9-patch drawable over this image.
Which ViewGroup should I use for this purpose: RelativeLayout or FrameLayout?
I also want to know the different scenarios that each of the ViewGroups should be used for.
I don't recall how i got to this question but here is my answer that could help anyone:
As you can see here
FrameLayout is designed to block out an area on the screen to display a single item. Generally, FrameLayout should be used to hold a single child view, because it can be difficult to organize child views in a way that's scalable to different screen sizes without the children overlapping each other.
In general is not useful to have 2 views one over the other because you're going to have overdraw effect (an area of the screen that is getting drawn by the gpu more than once which is really useless).
If you really have to, then you need to use the onDraw method (you can see an example here) and Canvas API (have a look here) and the clipRect method (you can see an example here)
Regarding FrameLayout or RelativeLayout, if you want to keep things simple or your activity has already enough nested layouts, better use FrameLayout. In 2017, there is the constraint layout which could be of some help as well.
Yes, you can use a FrameLayout in your scenario.
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.