290 CHAPTER 8: Android UI Design: Using Advanced ViewGroup Layout Containers
Under this scenario, the other two Button UI elements will expand equally, and fill the remaining
screen space. If the third UI Button element were to be given a weight of 2, instead of 0, that UI
Button would be specified as being more important (or having more screen layout weight) than your
other two UI Button elements. Under this scenario, that UI Button would get half of your total screen
real estate, while the first two UI Buttons share the rest equally, that is, each would get one-quarter,
or 25%, of the total UI design space.
The way that these relative weights would be calculated is as follows: to get the total weight, add
1+1+2=4 and then to calculate each relative weight percentage, divide the weight value by the total
value, like so: 2/4 is 50% and 1/4 is 25% for the other two.
To give each UI Button an equal portion of the screen space, you would use a layout_weight value
of 0.333.
As I mentioned previously, an easier way to set layout_weight would be to use percentage
of one floating-point values, such as using 0.5 instead of 2, and 0.25 instead of 1, for this
particular example. Doing it this way would allow you to numerically conceptualize the screen
weight as percentages of the screen width (or height, if using a LinearLayout definition with
orientation=“vertical”), rather than using whole numbers relative to each other.
It is important to note that float (decimal) data values can accept integer (whole number) data
values, since a value of 2 can also be considered to be a 2.0 value, so integer values will always be
accepted in float value data fields.
The layout_weight parameter will be used by the SlidingPaneLayout “engine” (algorithm)
specifically, in order to determine how Android will divide any leftover space between the two panes
after a change in screen size or orientation has been detected by Android, and the new screen
measurement data has been assessed. The weight parameter is not as critical (and not as useful) for
the SlidingPaneLayout as it is for the LinearLayout container. The android:layout_weight parameter
for the SlidingPaneLayout will be considered relevant by the SlidingPane algorithm (engine) only for
the width dimension, whereas LinearLayout can use weight in the height dimension as well as in the
width dimension.
When the two panes involved in a SlidingPane UI design do not overlap at all, the layout_weight will
behave as it would in a LinearLayout. This allows developers to define the percentage of the screen
that is used by each of the two panes. Remember, the two weight values need to add up to 100%,
so the best approach is to use floating-point values that add up to one, such as 0.35 for 35% of your
screen width, and 0.65 for the other 65% of screen width. This allows Android developers to assign
very precise dual pane dividing values.
If the two panes (and the child UI widgets inside of them) are constrained by the device screen
width, such as in a portrait display orientation, or smaller Android devices, such as smartwatches,
the two panes will overlap, and a more complex weight assessment algorithm will be utilized.
As you might imagine, in this circumstance, your layout weight specification is not followed (applied)
as precisely by the SlidingPaneLayout algorithm, and will instead favor your right-side primary
content pane, and will allow the left-side UI pane to slide over the primary content only when the UI
is needed by the user.
A weight assigned to the fixed (right) content pane that becomes covered by the (left) UI pane will be
evaluated in such a way that the content pane will be sized to fill most of the available screen space.
A small (minimized) strip of the UI pane will still be visible on the left, which will allow the user to grab