Question

Consider this layout (pulled from here):

I’d like to understand the principles behind making this layout scale with screen size. For the square, a custom onMeasure function works nicely:

@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    super.onMeasure(widthMeasureSpec, widthMeasureSpec);
}

The width and height of the custom Togglebuttons and Imagebuttons below should scale to fill the remainder of the screen, minus layout_margins, and the text and images within should scale to fill the buttons, minus padding. The outer margin should also scale.

My first thought was to use a relative layout to position the buttons, and layout_margin/padding attributes to create margins. However, relative layouts and layout_margin/padding require fixed pixel values, so they aren’t scalable.

I then thought of using nested linear layouts with layout_weights to position the buttons, and placeholder views to create margins. Although these techniques are scalable, they don’t work with buttons, because buttons have many attributes (text size, image size, corner radius, etc.) that require fixed pixel values. This limitation means, for example, that the following xml:

<ToggleButton 
    android:layout_weight="1"
    style="@style/myButton"
    [...] />
<View 
    android:layout_weight="1"/>
<ImageButton 
    android:layout_weight="1"
    style="@style/myButton"
    [...] />

won’t necessarily make the two buttons, and the space between them, all the same width. It all depends on the text size, image size, etc. etc. of the buttons.

I’ve taken a look at this question but I feel there should be a simpler solution for such a simple problem, that shouldn’t require resorting to too much non-XML.

Answer 1

It depends a lot on the number of custom View and ViewGroup classes you want to create. An implementation with the least number of custom classes that I could think of would be something like this (very similar to what you’ve described):

• Customized FrameLayout for the largest square, with a custom onMeasure() implementation to match the height to the available width (you mentioned this one already).
• Nested LinearLayout instances using weight to get all the grid buttons to be the same size.

The big drawback to this approach is efficiency. You would need roughly 36 LinearLayout instances to create the small 9×9 grids inside of a larger 9×9 grid…that’s 36 views of pure layout overhead.

---

As far as text sizing, there are a couple ways I could think of to handle this. One would be to use Paint.measureTextBounds() (you can get the Paint object of any TextView to do the measurements) to determine what size you need to make the text in each button after they have been measured. Unfortunately this would be a somewhat iterative process because the Paint measures a given text based on its current settings, so you would need to:

1. Set the text size
2. Measure bounds
3. Check height
4. Repeat until the size just fits

The good news is you would only need to do this once and just apply it to all the grid buttons, but you would need to wait until the grid buttons are measured.

Another option here would be to display an image instead of text inside of something like ImageView, which can scale the content for you to its size. You could use something like the TextDrawable that I wrote to set text content as an image that is scalable without quality loss.

---

Now back to the layout. You could gain back a ton of efficiency by creating a custom ViewGroup to measure and lay out the grid (the name GridLayout is already taken…and it doesn’t quite serve this purpose, so let’s call it BlockLayout). Creating a custom BlockLayout will allow you to measure the size of each block and lay out 9 subviews in a grid with a single parent instead of 4 LinearLayout instances. This is basically the same way that you measure the overall square, just divided evenly.

You could then build the entire layout with only 10 instances of layout overhead…and even less if you can code the entire thing into a single ViewGroup.

Basically the more code you can write to flatten the view hierarchy, the better your application will run overall.

HTH