So whenever I try to use layout_weights within each other to achieve the layouts I want, Android Studio helpfully tells me that nested weights are bad for performance. Various answers here on SO say that it's okay to nest them for a couple layers of deep, but don't overdo it. I'm not sure how deep is too deep, o what I'm trying instead is doing something like this:
//get pix size of device screen
int[] dimens = ImageUtils.getScreenDimensions(getWindowManager());
//programmatically set height of my two sections to the percentages that I want
upper.getLayoutParams().height = (int) (dimens[1]*0.8);
lower.getLayoutParams().height = (int) (dimens[1]*0.2);
// do the same thing for the left and right sections of our upper block
upperLeft.getLayoutParams().width = (int) (dimens[0] * 0.5);
upperRight.getLayoutParams().width = (int) (dimens[0] * 0.3);
...so on and so forth
And I mean, it works. I get some nice percentage-based layouts. My question is though, does that actually help with performance at all? Or am I just doing the same thing in a more complicated and fancy fashion?
Edit: adding desired layout. I guess I could use a grid layout if necessary? Or would just plain old percentages work?
"Nested Layouts" implies that Android does not know how big each layout should be without iterating over each layout setting to determine if the size should be changed based on other layouts.
This means that "nesting" could result in many iterations of trying to size each layout, then trying to figure out if child layouts change based on changes to parent layouts and sibling layouts.
If you can determine the size of a layout programmatically (which it seems you can do), then the LayoutManager will use the sizes that you dictate and not try to layout the screen and then check to see whether the layouts have been sized properly.
That said, it might not really matter if you only have a dozen or so layouts. The performance hit happens when several dozens of layouts (or more) need to be measured. That is why a lot of comments on SO say that it doesn't really matter - most times, a few dozen layouts are all that are present on the screen. (HINT: if you have a ListView or GridView or something that requires an indeterminate number of layouts be used; then nesting matters and recycling views matter)
If these layout weights aren't going to change dynamically, you are better off defining them in the XML layouts. Not only will your intention be clearer, but Android does perform optimizations when inflating your layouts.
Related
There is a dialogue, in one place of which I need to show either one element or another, depending on the situation. Example:
I would like to do this so that the elements below do not move. I want to keep the area occupied by alternating elements of a constant size.
What is the easiest way to do this?
I can, of course, manually change the visibility. Вut when switching, if there is a different height, then the underlying elements will jump. I can manually set their height equal, but this is inconvenient. It will be necessary to correct the heights of all alternating elements every time after I change one of them.
For example, Qt has Stack Layout that allows you to alternate elements and takes the size of the largest of them. Does Android have something like this?
You might be able to use the ViewSwitcher to hold the two layouts.
It holds 2 different child views and measures its height to the biggest child by default.
Here's the documentation for it: https://developer.android.com/reference/android/widget/ViewSwitcher
Just an idea if you can't find something like Stack Layout. I haven't tried it.
You can put all the elements in an horizontal LinearLayout with MATCH_PARENT width for the visible one and 0 for the invisible ones, but keeping all of them VISIBLE. It should always have the largest height and only the MATCH_PARENT width element should actually be visible.
With all the various screens sizes (both portrait and landscape) is it best to wrap conventional layouts (RelativeLayout, LinearLinear, etc) with a ScrollView if there is even the possibility of content extending below the screen? Is there a better approach?
Update Question: What about custom inflated Views? Does the same approach apply?
I don't think I would go as far as saying that wrapping every LinearLayout with a ScrollView is a "best practice".
That said, in my own experience, I have often created layouts that use ScrollView + LinearLayout even when I know that my content will fit on most phones. I've done this because (1) I want to support both portrait and landscape orientations (and landscape often does not have enough height to display everything) and (2) because I want to support any device my users might have (and some people do have really tiny phones).
The trick is to differentiate between cases where your LinearLayout is just chopping the screen up into pieces vs cases where your LinearLayout is a parent to some number of views each with their own fixed height. Two Buttons next to each other, each taking 50% of the screen width, obviously don't want a ScrollView around them. But a form of eight EditText fields on top of each other might do well to be wrapped in a ScrollView, even if all eight fit on your personal device's screen just fine.
The downsides to having an "extra" or "useless" ScrollView on larger phones is so tiny that I've never worried about it. A single extra View instance isn't going to hurt performance or use up too much extra memory. The upside of making your app usable on tiny screens, though, is well worth it.
There are few possible cases:
If your layout is a static layout, just buttons, text views etc., then you can just preview different screen sizes within Android studio and verify that the layout works fine for the devices you support.
If your layout is dynamic, like ListView, RecyclerView that gets dynamic data set, it is always a good idea to make ScrollView as the parent.
Does that answer your question? Please reply if further explanation is needed.
I'm familiar with almost all the basic layouts in Android & understand when they are to be used. I know that a RelativeLayout is to be used when elements in the UI are to positioned relative to each other, that a LinearLayout is to be used when UI elements are to be displayed vertically or horizontally. So I was wondering if the ease of development was the only factor that determined what layout should be selected or if there was any performance factor involved. I mean I can lay out two ImageViews vertically in Android using both LinearLayout and RelativeLayout, so why use a particular layout then?
There are some performance gains for avoiding certain things, such as nesting RelativeLayout (see this question). Also, the docs recommend making layouts shallow and wide, which can facilitated with RelativeLayout, again for performance reasons.
However, often thinking about such things will be premature optimization for simple layouts, and you should use whatever makes the most sense for the situation.
I've one of the simplest layouts imaginable: A num pad.
I want to create a fragment containing a 3 x 4 grid of buttons. The layout should automatically resize the num pad to fill the available space.
I've learned, that GridLayout is not up to the task, and TableLayout/TableRow or nesting LinearLayouts means nesting weights, which is also discouraged for performance reasons. A RelativeLayout won't work either, because that requires at least one button with given dimensions.
So, is there a clean way to create a regular grid that will resize to fill its parent?
Any help is appreciated, thx!
You will need a custom compound control.
Check the following link:
http://developer.android.com/guide/topics/ui/custom-components.html#compound
Make the control fill the available space. Make it to have 12 buttons. Calculate the size and position of them based on their position and the available space.
Depending on your needs you might also need to override onMeasure() and onLayout() defined earlier in the above document, in the "Fully Customized Components" section.
Hey Im new to android developing and I have a quick question. Is there a way to place buttons where I want them on the view? Right now they only seem to be placed where there is specific spots for them. Why cant i drag and place them where ever I want like in the iphone sdk for example?
Is there a way to do so or does this functionality not exist? thanks.
Android (eg. similar to Qt) uses a concept of layouts. This is especially useful when you're creating UIs that can be displayed on different devices with different DPIs, different screen resolutions, etc.
So instead placing your buttons at pixel coordinates you put them, independent of device screen resolution, into layouts.
Read more in User Interface documentation. Using Eclipse ADT plugin you can visually create layouts. You can even embed one layout into other, creating eg. LinearLayout in RelativeLayout. This gives much more possibilities of creating screen scalable applications (one app on phone and tablet for example).
There is AbsoluteLayout, but that class is deprecated. The recommended strategy is to use a RelativeLayout (you can control the position of views by setting layout margins) or build your own custom layout class.
An android UI screen is build for various screen sizes , due to which you can not specify an exact location for the UI component .
Android instead uses the concepts of Layouts where each layout has a different behavior. Here are a few of them.
LinearLayout aligns all children in a single direction — vertically or horizontally, depending on how you define the orientation attribute
TableLayout positions its children into rows and columns
RelativeLayout , one of the most used layouts , lets child views specify their position relative to the parent view or to each other (specified by ID).
Android uses layouts to design the UI. For example, a vertical linear layout stacks one element on top of the other.
AbsoluteLayout is the most precise, but it's also harder to maintain and can get messy.
I recommend RelativeLayout. It positions UI elements relative to other elements.
If you don't really need that much precision, one more option is nesting layouts within layouts. But doing that too much gets messy and RelativeLayout becomes the better option.
A UI element's position is determined by the layout you choose. See this link.