Is it nice to use negative fields in Android?

Question

Negative field demo:

Scenario

Overlapping views by setting a negative field on one of them so that it invades the bounding box of the other view.

Thoughts

It seems to work as you expect, with overlapping layouts if necessary. But I do not want to face a more serious problem, because I do not know what to do. Emulators, physical devices, you name it, when you use negative fields, everything seems to work correctly, one view invades the other bounding box of the views and depending on how it is declared in the layout, it will be above or below another view.

I also know that with API 21 we can set translationZ and elevation to make the view higher or lower than other views, but my problem mainly comes from the fact that the documentation for the layout_margin attributes clearly states that the margin values ​​must be positive , let tell me:

Excerpts:
Specifies the extra space on the left, top, right, and bottom sides of this view. This space is beyond this point of view. Margin values ​​must be positive . There must be a dimension value, which is a floating point number added using a block 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 those years when I asked this question, I did not have any problems with negative margin, I tried to avoid using them as much as possible, but did not encounter any problems, so even if the documentation says that I'm not too worried about this one.

Answer 1

In 2010, @RomainGuy (Android kernel developer) stated that negative fields have unspecified behavior .

In 2011, @RomainGuy stated that you can use negative fields on LinearLayout and RelativeLayout .

In 2014, @RomainGuy stated that they were never officially supported or supported by ConstraintLayout .

It’s easy to get around this limitation.

Add an auxiliary view (height 0dp, width limited by the parent) at the bottom of the base view, add the desired value at the bottom.
Then position your view below this, effectively allowing it to have a “negative” margin, but without using any unsupported negative value.

Answer 2

If you want to use a negative margin, set a sufficient padding for the container and its clipToPadding to false and set negative margins for it so that it doesn't crop the child view!

Answer 3

For me and for setting a negative field in a TextView (I understand that OP refers to ViewGroup, but I was looking for problems with setting negative fields and I landed here) ... I found a problem with 4.0.3 (API 15) ONLY and setting android:layout_marginTop or android:layout_marginBottom to a negative value such as -2dp.

For some reason, TextView does not display at all. It seems that he "left" the view (not just invisible).

When I tried this with the other 3 versions of layout_margin, I did not see a problem.

Please note that I have not tried this on a real device, it uses emulator 4.0.3. This is the second strange thing that I found that it affected only 4.0.3, so my new rule is to always test with the 4.0.3 emulator :)

I have success with decreasing the bottom margin of a TextView using android:lineSpacingExtra="-2dp" , which works even if I have android:singleLine="true" (and therefore I would not have thought that line spacing would be a factor).

Answer 4

It may have been bad practice in the past, but with Material Design and its floating action buttons, it seems inevitable and in many cases is necessary now. Basically, when you have two separate layouts that you cannot fit into one RelativeLayout because they need certain separate processing (for example, the title of the header and the content), the only way to override the FAB is to make it stick out from the same layout using negative fields. And this creates additional problems with interactive areas.

Answer 5

I only knew that this was possible in a fairly short period of time. But I do not see a problem with this. Just remember the screen size, etc., so that you do not accidentally hit objects that should not be displayed on the screen. (i.e., text on top of text is probably a bad idea.)