I'm using ConstraintLayout in most of my layouts, and I want to know what's the best practice in the performance aspect:
Using a guideline as a view's limit, including as a margin limit.
Example: 4 guidelines in total, no margins.
guideline picture
Using a view margin, which will result in less accurate spacing, because I will need to insert an arbitrary number of dps.
example: 2 guidelines in total, 2 margins (top + bottom)
android:layout_marginTop="5dp"
android:layout_marginBottom="5dp"
margins picture
If you have another option, I will be happy to read it.
Also, I would like to know how to track performance of layout configuration such as this (where have you looked / what have you used to give me the answer).
Thanks.
In this case, you can get the same result without guidelines. Percent dimensions can be used in ConstraintLayout.
Just set the "layout_constraintHeight_default" attribute to "percent" (to use percentage units), and set the percentage using "layout_constraintHeight_percent". (width related attributes are available too)
As for the layout performance between 4 widgets, and, 2 widgets and 2 constraints(margins). I am sure that the latter will do better as it takes a smaller layout to render.
However, in this case, the difference is insignificant.
Related
I am migrating from Android to iOS (Swift). In Android UI elements are scaled up or down (height and width using "dp", layout_weight e.t.c) according to device size.
However I find this VERY difficult to achieve with Auto Layout's constraints, I want the elements in my UI to scale according to device size.
For example, in the shared image below, asides the compression of images to fit the screen width, every UI element has the same size, only looks like UI elements have been duplicated with same specs on all screens
This might help others in their migration from Android to Swift
(I only pinned the width of the 2 ugly ImageViews below)
P.S: This is what I'm trying to replicate guys, this view to fit properly on all screens. Sorry for the blur, I'm not in charge of this project
There's a zen to the AutoLayout. Let me see if I can give you some direction.
You'll want to test every UI on the smallest simulator available (iPhone 4S). This will let you know if you need to adjust your elements' minimum size.
Now for a top-to-bottom review of your UI posted:
"Profile" looks fine
To make the top-left and top-right boxes resize with screen size, you'll
want to give a constraint to the superview on left and right sides respectively. Then you'll want to make a horizontal constraint between the two (to maintain a space between them. Then you'll want to set them to equal widths. You can also set aspect ratio constraints for each one.
Your forms look fine. I can give more guidance here if the look you're after doesn't match the image you posted.
For the views below the form, you'll probably want to follow #2 above.
As for the height issue, set a constraint from your bottom view to the superview's bottom. There might be crowding, interface builder might yell. Chances are, you'll need to set the horizontal spacing constraints from = to >=.
I have to position the images on my layout such that it does not change its position with varying screen resolutions. They should be exactly where they are placed. layout_weight attribute can be used with linear layout. But I am using relative layout and I am dealing with cropped images. Any solution on how to position the image views? Setting out margin height and width is not worth.
In short - you can't. Devices have different resolutions as well as screen sizes ratio. Thus it's impossible for the app to look same because there is no same definition in Android. The only way to design an interface - is to use bindings to other objects or parent view's borders. Try to investigate what are the rules, e.g. "to the bottom of the picture with 10dp gap" or "next to the TextView" - and it's the constants that are kept on every device.
I can't imagine a scenario where this makes sense but it obviously must exist since the Android team built support for it. The docs on the dimension type clearly state that it supports "mm" and "in" as qualifiers for millimetres and inches respectively.
That should get you what you need but I would advise reevaluating that requirement, as it would make design a massive pain.
I was just building some UI in xml, and Lint gave me a warning and said to set android:baselineAligned to false to improve performance in ListView.
The docs for the Lint changes that added this warning say
Layout performance: Finds LinearLayouts with weights where you should
set android:baselineAligned="false" for better performance, and also
finds cases where you have nested weights which can cause performance
problems.
Can somebody explain why this improves performance, specifically when weight is involved?
By setting android:baselineAligned="false" , you're preventing the extra work your app's layout has to do in order to Align its children's baselines; which can obviously increase the performance. (Fewer unnecessary operations on UI => Better performance)
how android:baselineAligned="false" help . It may not be the answer but help to get concept.
I've just managed to get 3 items (icon, text, button) centered
vertically in horizontal LinearLayout.
This may seem simple, but in reality specifying
android:gravity="center_vertical" as LinearLayout attribute is not
enough - icon is centered, but text and button are not. This is
because (presumably) text have a baseline, and centering algorithm
uses it instead of 'real' vertical center. But what is worse - button
(which comes next to text) is centered using text's baseline!
Specifying android:baselineAligned="false" in LinearLayout turns this
off, and everything centers correctly.
// Baseline alignment requires to measure widgets to obtain the
// baseline offset (in particular for TextViews). The following
// defeats the optimization mentioned above. Allow the child to
// use as much space as it wants because we can shrink things
// later (and re-measure).
if (baselineAligned) {
final int freeSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED);
child.measure(freeSpec, freeSpec);
}
https://github.com/android/platform_frameworks_base/blob/master/core/java/android/widget/LinearLayout.java#L1093
I'm trying to understand Android's View structure and I'm a little confused on how to position child views
Let's say I have a FrameLayout that will contain my custom view. My custom view only draws a rectangle 50x50 px.
So I set my View.setMeasureDimension(50, 50);
Now how should I move this view? I found a couple of ways of doing it.
1: I could do something like canvas.drawRect(new Rect(offsetX, offsetY, right, bottom)); but this will make my View larger and thereby my measureWidth / height are not valid any longer?
2: Set padding on the parent element, and thereby affect the left / top View.getLeft() / View.getTop(). But this will affect all child elements.
3: Use View.offsetLeftAndRight( number of pixels to move ). I do not quite understand what this actually does. Does it cause some kind of canvas.translate() ? But this way I need to keep the state on how many times I called offsetLeftANdRight() because calling offsetLeftANdRight(10) and then offsetLeftANdRight(10) will move it 20px.
I'm a bit confused on what way is the "correct" way of doing it. Is there a better way?
Android apps run on devices of different sizes, with often completely different screens. Because of that you shouldn't be using any absolute positioning or sizing. Wherever possible create views and position them relative to each other.
You need to become familiar with the various views Android provides to create layouts:
http://developer.android.com/guide/topics/ui/layout-objects.html
It sometimes takes a lot of thought as items will be positioned differently on different devices (and orientations) so the view relationships are more important than absolute positions.
LinearLayout is a good all-purpose container for placing controls, though RelativeLayout is often more efficient (if a bit harder to use sometimes)
Once items are positioned relative to each other you can use padding and margins to tweak their positions.
I have referred to this site for Layout Tricks.
Over there one attribute is declared as android:layout_weight="1".
So my confusion is regarding android:layout_weight:
where is the exact use of android:layout_weight ?
Where should we use android:layout_weight ?
From what I understand of layout_weight, the closest comparison I could find is when you pass some % in HTML for the width or height of your div. In our context, the weigth seems to refer to the % of width or heigth your widget should get for itself compared to its neighbours in a given ViewGroup. You can find another exemple with more explanation here.
If you look the way they use it, it sticks exactly to the definition. They give a height of 0dip to keep the whole space free, and then uses equal weigths for the 2 widgets to make same th same height.
layout_weight is quite simply a priority to apply to a view class, the higher, the larger the control or group will be in proportion to it's mates inside that group. The default is 0, so a weight of 1 makes it twice as large as other default controls. No mystery.