Книга: Beginning Android
Concepts and Properties
Concepts and Properties
For all this to work, we need to know how widgets work with rows and columns, plus how to handle widgets that live outside of rows.
Putting Cells in Rows
Rows are declared by you, the developer, by putting widgets as children of a
TableRow inside the overall
TableLayout. You, therefore, control directly how many rows appear in the table.
The number of columns is determined by Android; you control the number of columns in an indirect fashion.
There will be at least one column per widget in your longest row. So if you have three rows — one with two widgets, one with three widgets, and one with four widgets — there will be at least four columns.
However, a widget can take up more than one column if you include the
android:layout_span property, indicating the number of columns the widget spans. This is akin to the
colspan attribute one finds in table cells in HTML:
<TextView android:text="URL:" />
In this XML layout fragment, the field spans three columns.
Ordinarily, widgets are put into the first available column. In the preceding fragment, the label would go in the first column (column 0, as columns are counted starting from 0), and the field would go into a spanned set of three columns (columns 1 through 3). However, you can put a widget into a different column via the
android:layout_column property, specifying the 0-based column the widget belongs to:
<Button android:id="@+id/ok" android:text="OK" />
In this XML layout fragment, the Cancel button goes in the third column (column 2). The OK button then goes into the next available column, which is the fourth column.
Non-Row Children of TableLayout
TableLayout contains only
TableRow elements as immediate children. However, it is possible to put other widgets in between rows. For those widgets,
TableLayout behaves a bit like
LinearLayout with vertical orientation. The widgets automatically have their width set to
fill_parent, so they will fill the same space that the longest row does.
One pattern for this is to use a plain View as a divider (e.g.,
<View android:layout_height="2px" android:background="#0000FF" /> as a two-pixel-high blue bar across the width of the table).
Stretch, Shrink, and Collapse
By default, each column will be sized according to the “natural” size of the widest widget in that column (taking spanned columns into account). Sometimes, though, that does not work out very well, and you need more control over column behavior.
You can place an
android:stretchColumns property on the
TableLayout. The value should be a single column number (again, 0-based) or a comma-delimited list of column numbers. Those columns will be stretched to take up any available space on the row. This helps if your content is narrower than the available space.
Conversely, you can place an
android:shrinkColumns property on the
TableLayout. Again, this should be a single column number or a comma-delimited list of column numbers. The columns listed in this property will try to word-wrap their contents to reduce the effective width of the column; by default, widgets are not word-wrapped. This helps if you have columns with potentially wordy content that might cause some columns to be pushed off the right side of the screen.
You can also leverage an
android:collapseColumns property on the
TableLayout, again with a column number or a comma-delimited list of column numbers. These columns will start out “collapsed,” meaning they will be part of the table information but will be invisible. Programmatically, you can collapse and un-collapse columns by calling
setColumnCollapsed() on the
TableLayout. You might use this to allow users to control which columns are of importance to them and should be shown, versus which ones are less important and can be hidden.
You can also control stretching and shrinking at runtime via