39
<TextView
    android:layout_width="match_parent"
    android:layout_height="48dp"
    android:paddingTop="48dp"
    android:text="Test"
    />

I would expect the TextView to have a measured height of 96dp, regardless of how much space (height-wise) "Test" took up (would expect it to cut off).

Instead, I get the full "Test" + 48dp for the padding.

I can put any valid value for layout_height and get the same result.

To get my 96dp height, I need:

<TextView
    android:layout_width="match_parent"
    android:layout_height="<any valid value>"
    android:height="48dp"
    android:paddingTop="48dp"
    android:text="Test"
    />

where again, I can put layout_height as any valid value (but it needs to be there as a required attribute).

I've never used the height attribute in XML but I couldn't find the difference in the docs, particularly how each one is calculated when the element it's operating on also has values set for padding and/or margin.

Are there any resources available which discuss it, or can someone explain it here?

Edit (summary of questions):

It might be the situation I used it in, which was causing an issue, so my examples from above can be ignored (I tried in a fresh project and got different results from the combinations of attributes).

But my original questions still apply (some overlaps):

  1. what's the difference between them?
  2. when should one be used over the other?
  3. does the use of one affect the use of the other?
  4. does the use of one have implications over other attributes which can control the measured dimensions of a view, like padding or margin?

Edit 2 (an aside):

In case it helps understand my initial situation as compared with the fresh project:

I have an activity which sets windowActionBarOverlay as true, so I get my content flowing under the (translucent) ActionBar.

I also use Croutons, which now were appearing under the ActionBar. Ben Weiss suggested I attach the Crouton to a different ViewGroup, but I wasn't sure which ViewGroup to attach it to.

Instead, I supplied a custom view (which is inflated when it is required) as the Crouton (the TextView from the first part of the question) with a top padding equal to that of the ActionBar, so now it displays vertically below the ActionBar as normal (with other issues for another day).

Martin
  • 11,577
  • 16
  • 80
  • 110
ataulm
  • 15,195
  • 7
  • 50
  • 92
  • could someone suggest how I could improve this question such that it doesn't warrant an anonymous downvote? – ataulm Jul 01 '13 at 22:14
  • 1
    here is a similar question: http://stackoverflow.com/questions/18091531/what-is-use-of-androidheight-attribute-despite-having-androidlayout-height – Prince Aug 06 '13 at 22:35
  • Thanks @Prince, I've voted to close based on this... edit: even though yours was after. Clearly mine was `tl;dr` :P – ataulm Aug 09 '13 at 13:49
  • @ataulm Google will find this question first if “android layout_height vs height” is searched. — Also this question is one month older. — And this question has an exhaustive answer now. — So if anything the other question should be closed. – Martin Dec 22 '13 at 10:08

4 Answers4

28

Question 1:

(what's the difference between them?):

All attributes starting with »layout_« are hints for the ViewGroup the View is part of. For this each android.view.ViewGroup has a set of LayoutParams. The widget itself does not use them.

The android:height parameter is the initial size of the android.view.View. But if the View is part ViewGroup then the ViewGroup will resize the objet according to its layout rules.

BTW: newer APIs have a new android:minHeight and android:maxHeight attribute to clarify programmers intent.

Note that if you don't set android:height the view will calculate the size itself. Which is right thing to do most of the time.

Question 2

(when should one be used over the other?):

ViewGroup is abstract — the answer to this question depends which actual child class you are using.

Note that WRAP_CONTENT tells the to use ViewGroup to use android:height. Which means that this is the correct parameter to be used in your example.

Question 3

(does the use of one affect the use of the other?):

Yes — and recursively . TableLayout will read and write the android:width attribute to find out the widest object and resized all other object to it.

Question 4

(does the use of one have implications over other attributes which can control the measured dimensions of a view, like padding or margin?)

No for android:padding but yes for android:layout_margin. Note that margins are a layout parameter and not every layout manager supports margins.

See margin vs padding for details.

Final words:

It is easier to consider all width and height attributes to be hints only. The final say of the size of an object has the layout manager of the used ViewGroup.

Community
  • 1
  • 1
Martin
  • 11,577
  • 16
  • 80
  • 110
0

From playing about with this a bit, I think that layout_height is flexible - a preferred height but will still expand/shrink with the content - and height is a definite value.

What's happening in your case is that the TextView is wrapping around the Test text but still using the 48dp paddingTop attribute.

James Williams
  • 678
  • 4
  • 14
  • Yes. But some `android.view.ViewGroup` might actually set height themselves. All depends on the layout strategy used. – Martin Dec 22 '13 at 10:02
0

Well, android_layout:height specifies the basic height of the VIEW whereas android:height specifies the height of the object (for example, the button in the xml).

Good luck! :)

tash
  • 189
  • 1
  • 15
  • Not quite `android_layout:height` is not part of the view. It tells the parent `android.view.ViewGroup` which size you would like to have. – Martin Dec 22 '13 at 10:03
0

android:height makes the view be exactly this many pixels tall while android:layout_height specifies the basic height of the view.

Pradeep
  • 104
  • 4