The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Introducing GridLayout

In 2011, Google added GridLayout to our roster of available container classes (a.k.a., layout managers). GridLayout is an attempt to make setting up complex Android layouts a bit easier, particularly with an eye towards working well with IDE graphical layout editors. In this chapter, we will examine why GridLayout was added and how we can use it in our projects.


Understanding this chapter requires that you have read the core chapters of this book.

Issues with the Classic Containers

Most layouts are implemented using a combination of LinearLayout, RelativeLayout, and TableLayout. Almost everything you would want to be able to create can be accomplished using one, or sometimes more than one, of those containers.

However, there are issues with the classic containers. The two most prominent might be the over-reliance upon nested containers and issues with drag-and-drop GUI building capability.

Nested Containers

LinearLayout and TableLayout suffer from a tendency to put too many containers inside of other containers. For example, implementing some sort of 2x2 grid would involve:

On the surface, this does not seem that bad. And, in many cases, it is not that bad.

However, views and containers are relatively heavyweight items. They consume a fair bit of heap space, and when it comes time to lay them out on the screen, they consume a fair bit of processing power. In particular, the fact that a container can hold onto any type of widget or container means that it is difficult to optimize common scenarios (e.g., a 2x2 grid) for faster processing. Instead, a container treats its children more or less as “black boxes”, requiring lots of method invocations up and down the call stack to calculate sizes and complete the layout process.

Moreover, the call stack itself can be an issue. The stack size of the main application thread has historically been rather small (8KB was the last reported value). If you have a complex UI, with more than ~15 nested containers, you are likely to run into a StackOverflowError. Android itself will contribute some of these containers, exacerbating this problem.

RelativeLayout, by comparison, can implement some UI patterns without any nested containers, simply by positioning widgets relative to the container’s bounds and relative to each other.


Where RelativeLayout falls down is with the drag-and-drop capability of the graphical layout editor in IDEs like Android Studio.

When you release the mouse button when dropping a widget into the preview area, the tools need to determine what that really means in terms of layout rules.

LinearLayout works fairly well: it will either insert your widget in between two other widgets or add it to the end of the row or column you dropped into. TableLayout behaves similarly.

RelativeLayout, though, has a more difficult time guessing what particular combination of rules you really mean by this particular drop target. Are you trying to attach the widget to another widget? If so, which one? Are you trying to attach the widget to the bounds of the RelativeLayout? While sometimes it will guess properly, sometimes it will not, with potentially confusing results. It is reasonably likely that you will need to tweak the layout rules manually, either via the Properties pane or via the raw XML.

The New Contender: GridLayout

The preview of this section took that left turn at Albuquerque.

GridLayout and the Android Support Package

The preview of this section was last seen in the Bermuda Triangle.

Our Test App

The preview of this section was traded for a bag of magic beans.

Replacing the Classics

The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).

Implicit Rows and Columns

The preview of this section will not appear here for a while, due to a time machine mishap.

Row and Column Spans

The preview of this section is in the process of being translated from its native Klingon.