Home » Android » Is it a bad practice to use negative margins in Android?

Is it a bad practice to use negative margins in Android?

Posted by: admin March 11, 2020 Leave a comment

Questions:

Demo of negative margin:

                         enter image description here

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.

How to&Answers:

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.

It is easy to work around this limitation though.

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.

Answer:

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:

enter image description here

Answer:

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!

Answer:

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.

Answer:

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).

Answer:

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.

Answer:

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.)