Demo of negative margin:
The scenario
Overlapping views by setting a negative margin to one of them so that it invades the bounding box of another view.
Thoughts
It seems to work the way you'd expect with overlapping of the layouts if they should. But I don't want to run into a bigger problem for unknowingly not doing things right. Emulators, physical devices, you name it, when you use negative margins everything seems to work correctly, one view invades another's views bounding box and depending on how it's declared in the layout it will be above or below the other view.
I'm also aware that since API 21 we can set the translationZ and elevation attributes to make view appear above or below other views but my concern basically comes from the fact that in the documentation for the layout_margin attributes it's clearly specified that margin values should be positive, let me quote:
Excerpt:
Specifies extra space on the left, top, right and bottom sides of this view. This space is outside this view's bounds. Margin values should be positive.
Must be a dimension value, which is a floating point number appended with a unit such as "14.5sp". Available units are: px (pixels), dp (density-independent pixels), sp (scaled pixels based on preferred font size), in (inches), mm (millimeters)...
In the years since originally asking this question I haven't had any issues with negative margins, did try to avoid using them as much as possible, but did not encounter any issues, so even though the documentation states that, I'm not too worried about it.
In 2010, #RomainGuy (core Android engineer) stated that negative margins had unspecified behavior.
In 2011, #RomainGuy stated that you can use negative margins on LinearLayout and RelativeLayout.
In 2016, #RomainGuy stated that they have never been officially supported and won't be supported by ConstraintLayout.
In December 2020(v2.1.0, official release June 2021), negative margin support for constraints has been added to ConstraintLayout.
It is easy to work around this limitation though.
Add a helper view (height 0dp, width constrained to parent) at the bottom of your base view, at the bottom add the margin you want.
Then position your view below this one, effectively allowing it to have a "negative" margin but without having to use any unsupported negative value.
Hope this will help someone. Here is working sample code using ConstraintLayout based on #CommonsWare's answer:
Add an helper view (height 0dp, width constrained to parent) at the
bottom of your base view, at the bottom add the margin you want. Then
position your view below this one, effectively allowing it to have a
"negative" margin but without having to use any unsupported negative
value.
Sample code:
<TextView
android:id="#+id/below"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="#F1B36D"
android:padding="30dp"
android:text="I'm below"
android:textColor="#ffffff"
android:textSize="48sp"
android:textAlignment="center"
tools:layout_editor_absoluteX="129dp"
tools:layout_editor_absoluteY="0dp" />
<android.support.v4.widget.Space
android:id="#+id/space"
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_marginBottom="32dp"
app:layout_constraintBottom_toBottomOf="#+id/below"
app:layout_constraintLeft_toLeftOf="#id/below"
app:layout_constraintRight_toRightOf="#id/below" />
<TextView
android:id="#+id/top"
android:layout_width="100dp"
android:layout_height="60dp"
android:textAlignment="center"
android:textColor="#ffffff"
android:text="I'M ON TOP!"
android:background="#676563"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toBottomOf="#+id/space" />
Output:
Instead of negative margins you can use:
translationX and translationY.
Example:
android:layout_marginBottom = -2dp
android:translationY = -2dp
UPDATE:
Have in mind that the whole view is translated.
In case you want use negative margin,set enough padding for container and its clipToPadding to false and set negative margin for it's children so it won't clip the child view!
It might have been bad practice in the past but with Material Design and its floating action buttons, it seems to be inevitable and required in many cases now. Basically, when you have two separate layouts that you can't put into a single RelativeLayout because they need distinctly separate handling (think header and contents, for instance), the only way to overlap the FAB is to make it stick out of one those layouts using negative margins. And this creates additional problems with clickable areas.
For me, and regarding setting a negative margin on a TextView (I realize the OP is referring to a ViewGroup, but I was looking for issues with setting negative margins and I landed here)... I found a problem with 4.0.3 (API 15) ONLY and the setting of android:layout_marginTop or android:layout_marginBottom to a negative value such as -2dp.
For some reason the TextView does not display at all. It appears to be "gone" from the view (not just invisible).
When I tried this with the other 3 versions of layout_margin, I didn't see the issue.
Note that I haven't tried this on a real device, this is using a 4.0.3 emulator. This is the 2nd odd thing I've found that only affected 4.0.3, so my new rule is to always test with a 4.0.3 emulator :)
I have success with reducing the bottom margin of a TextView by using android:lineSpacingExtra="-2dp" which works even though I happen to have android:singleLine="true" (and so I wouldn't have thought that line spacing would be a factor).
No, you should not use negative margin. instead you should use translate. Even if negative margin work sometime, when you change layout programmably, translate would help. And view can't overflow the screen wen you use margin.
I've only known that it was possible for a rather short period of time. But I see no problem with it. Just be aware of screen sizes and such so you are sure not to accidentally make to items that shouldn't appear overlapped on the screen. (i.e. text on top of text is likely a bad idea.)
Related
the upper part of recyclerview item is erased in some phones and is normal in other phones as the images below.
the first image is normal which from samsung phone (android 12 )
the second image has the problem which from huawi phone (android 8)
this is the code
<androidx.cardview.widget.CardView
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="70dp"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:foreground="?android:attr/selectableItemBackground"
android:clickable="true"
android:layout_margin="5dp">
<androidx.constraintlayout.widget.ConstraintLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:layout_margin="5dp">
<com.makeramen.roundedimageview.RoundedImageView
android:id="#+id/itemImage"
android:layout_width="40dp"
android:layout_height="40dp"
android:scaleType="centerCrop"
android:src="#drawable/ic_launcher_background"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
app:riv_oval="true"
/>
<View
android:layout_width="1dp"
android:layout_height="1dp"
android:id="#+id/viewSupporter2"
app:layout_constraintBottom_toBottomOf="#id/itemImage"
app:layout_constraintEnd_toEndOf="#id/itemImage"
app:layout_constraintStart_toStartOf="#id/itemImage"
app:layout_constraintTop_toTopOf="#id/itemImage"
/>
<TextView
android:id="#+id/diseasename"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_marginStart="10dp"
android:text="disease name"
android:textAppearance="?android:attr/textAppearanceMedium"
android:textColor="#color/black"
app:layout_constraintBottom_toTopOf="#id/viewSupporter2"
app:layout_constraintStart_toEndOf="#id/itemImage"
/>
<TextView
android:id="#+id/diseasenickname"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_marginStart="10dp"
android:text= "disease nickname"
android:textColor="#color/teal_700"
app:layout_constraintTop_toBottomOf="#id/viewSupporter2"
app:layout_constraintStart_toEndOf="#id/itemImage"
tools:ignore="NotSibling" />
</androidx.constraintlayout.widget.ConstraintLayout>
</androidx.cardview.widget.CardView>
You're doing a basic mistake of having your cards at fixed height of 70dp. Change them to be wrap_content and tweak margins/paddings of your layout instead to achieve the size you need.
While it looks ok on device you designed it for you can see it cannot fit TextViews on the other one so they ends up being clipped (on top). Actually you can even break it on your Samsung if you go into device settings and increase font size.
You have to let your card view "grow" in those cases so unrestraining height it is the way to go. Although you might consider adding maxlines to your textviews so they don't get too out of hand with maximum font size.
The problem here is your second device is set to a larger system font size than the first one. The dp system is designed so that things look consistent on different devices, and you can see that the ImageView takes up pretty much the same amount of space on both - the space around it is the same, the layout looks the same.
But you have to account for the user changing their overall text size, which is what's happening on your second image. See how the text is just bigger? Not just in your list items - the diseases text is taller than the hamburger icon on this one, the tab headers are much closer together because the words are wider...
You have three options in this case
use dp instead of sp for the text sizes (so they're consistent and don't scale to the user's preference)
make sure your fixed layout has enough space for those larger text sizes
make sure it can expand as necessary to fit them
The first option is ok sometimes, when you have text that's already large enough for everyone, and you want to maintain some kind of visual consistency (like a fixed design where things are a certain size etc). Don't do this as a way to get around the limitations of having to provide accessible content, that scales so the user can read it.
The flexible layout approach is what Pawel's suggesting - basically design your layout so it can grow if necessary. You can use the minWidth and minHeight layout attributes for this (and layout_constraintHeight_min in ConstraintLayout) to design how you want it to look, but use things like wrap_content and constraints to allow it to grow beyond that if necessary. That way you get it looking how you like, but if the user needs bigger text, it compromises.
And don't worry if you don't like how it looks with large text - that's not important! What's important is that the user can read it, and everything's visible and accessible. Nothing cut off, nothing overlapping anything, everything clickable etc. The user is the one making the compromise between style and practicality, and they probably don't have a choice, so just making it usable in that situation is the main thing.
The middle option is the fixed layout that has enough space for the larger text settings. This is actually what's recommended in the Material Design spec - I can't link directly to the Two line version, but go here and scroll down - there are some similar to what you're doing:
Those measurements are all in dp - notice that the top line's position is defined by where its baseline is, the line the text "rests" on, relative to the top of the layout. You can do that with:
android:layout_height="wrap_content"
app:firstBaselineToTopHeight="32dp"
app:layout_constraintTop_toTopOf="parent"
And then the text below has its baseline relative to the bottom of the first
app:layout_constraintBaseline_toBaselineOf="#id/firstTextView"
app:layout_marginBaseline="20dp"
or you could constrain it to the top of the layout like the first one, with a value of 32 + 20dp.
Notice that this design leaves space for the text to grow vertically (up from the baseline, which is in a fixed position). If you use the Material Design type scale (which is a bunch of standard text styles and font sizes with names like Subtitle and Body1) then those list item specs should have enough room to hold the text even at the larger font settings. Both lines in that image can pretty much double in height and still fit
The nice thing about these specs is someone's done the work coming up with a design for you! And they're working with fixed sizes, so you get a nice consistent look to your lists
Is there a way in android to make the margins extend to fill screens? The problem is that layouts I build for Nexus devices look great, but then when previewing on a regular device without the bottom controls there is an ugly space between the rest of the layout and the bottom. I would like the margins between items to increase when there is available space.
Pictures are added below. Sorry for the ugly cutting of some of the fields, I'm unable to show them at this time to due a contract. Notice how "advacned search" is far from the bottom, I would like the vertical margins between all items to increase and make sure this doesnt happen.
How can I acheive this in a relative layout?
Try using LinearLayout and empty Views between each of the items.
just empty View:
<View
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="1"
android:background="#android:color/transparent" />
I'm developing an android calendar app so I need to align the days in a grid-like style. I'm using the API Level 8 so I need to align them by margins. But when switching to Bigger screens the numbers get to the left of screen and do not cover the whole screen.(I know that is because I use dp as a unit for my margin-left). Is there something like CSS % (percent) in Android Layouts?
Try this
android:layout_weight="1"
on each element in that section. It should space evenly.
It's weight attribute for views inside LinearLayout. Here is a good explanation what it means. But you can use it only to set view sizes, not margins. However you can put your view into RelativeLayout, place this layouts to take all available screen width and set attribute centerInParent=true in your view.
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 try to implement a good reusable color picker for my Sketcher application. Instructions and screenshots are here: http://bit.ly/sketcherapp
The problem is I'm stuck with a good "resizable" UI which enable me to support wide range of devices with different screen sizes.
The top two widgets should be the same height and have proportional widths: 80 to 20. Also it would be nice to specify paddings in XML.
Current implementation is not good. I hardcoded some values into code and also it looks bad on Xoom devices because of inaccurate layout measurements.
Is there any way to implement this behavior? Ideally, I need some way to do it like with HTML tables (pseudocode):
table.width=100%, td1.width=80%, td2.padding=5px, ...
or something like that.
Current implementation:
code:
https://github.com/wargoth/Sketcher/tree/master/src/org/sketcher/colorpicker
layout:
https://github.com/wargoth/Sketcher/blob/master/res/layout/color_picker.xml
Thank you.
The top two widgets should be the same height and have proportional widths: 80 to 20.
Use a horizontal LinearLayout, android:layout_width="0dip" for both widgets, and android:layout_weight="80" and android:layout_weight="20", respectively.
Also it would be nice to specify paddings in XML.
Use android:paddingLeft and kin.
OK. I stopped boring with it and created dedicated layouts for each screen size.