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.
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.
Most layouts are implemented using a combination of
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.
TableLayout suffer from a tendency to put too many containers inside
of other containers. For example, implementing some sort of 2x2 grid would involve:
LinearLayoutholding onto a pair of horizontal
TableLayoutholding onto a pair of
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
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.
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.
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 preview of this section took that left turn at Albuquerque.
The preview of this section was last seen in the Bermuda Triangle.
The preview of this section was traded for a bag of magic beans.
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!).
The preview of this section will not appear here for a while, due to a time machine mishap.
The preview of this section is in the process of being translated from its native Klingon.