Android Layout Fundamentals: Choosing the Right Layout


Welcome to the final part of this review of the Pluralsight course Android Layout Fundamentals by Chiu-Ki Chan.

Chiu-Ki is a mobile developer with a passion in speaking and teaching.

She runs a mobile development company, producing apps such as “Monkey Write” for learning Chinese writing and Heart Collage for snapping photos to stitch into a heart.

Android Layout Fundamentals is the 5th course in the Android Learning Path.

Also in this series:

Part 1 – Introduction
Part 2 – LinearLayout
Part 3 – RelativeLayout
Part 4 – FrameLayout
Part 5 – TableLayout
Part 6 – Choosing the Right Layout

Choosing the Right Layout

Which Layout to Use?

In this final module, Chiu-Ki begins with how to decide which layout to use.

The first rule of thumb is to pick the simplest one that does the job. Once you have a working implementation, you can assess whether or not you need to make any performance improvements.

Chiu-Ki says we can think of the layouts as belonging into one of two groups.

One dimension layouts

  • LinearLayout
  • FrameLayout

Two dimensions layouts

  • RelativeLayout
  • TableLayout

Chiu-Ki gives performance advice. She says performance becomes important when using a layout repeatedly. Fewer views generally means faster performance, as does fewer measure passes.

What are measure passes? Android goes through three phases:

  1. Measure
  2. Layout
  3. Draw

We see a concrete example so explain this, with a LinearLayout and two TextView elements. The first displays “Hello” and the second displays “World”

We see the measurements that get made as the layout code is processed. Height and Width measurements are made for each TextView.

We see a table showing how many passes are needed for each type of Layout. The 1 dimension layouts need as little as one pass, whereas the 2 dimension layouts need at least 2 passes.

Hierarchy Viewer

The calculation that Chiu-Ki worked through in the previous lesson involved a lot of math and process. Fortunately there’s an easier way. We can use the Android Hierarchy viewer.

This shows all the views rendered on the screen allowing us to look at the structure and properties.

We can even use it to examine other apps that we bought from a store by including the ViewServer class.

1. Download from Romain Guy’s github project at

2. Add the Internet permission to your project by updating your AndroidManifest.xml file

3. Enable ViewServer in your activity

Chiu-Ki demonstrates each of these steps. For enabling ViewServer, take a look at the example and copy the relevant lines of code into your own project.

The Android Device Monitor contains many tools, of which the Hierarchy Viewer is one of them. In this lesson we see how to use and navigate through this program.

We can ask Android how long it takes to measure, layout and draw any sub tree.

Chiu-Ki changes the layout from LinearLayout to FrameLayout and changes from TextViews to simple Views.

We realize that we have more views than we need here.


We can use the merge tag to collapse layouts. In Android Studio we replace FrameLayout with merge.

Chiu-Ki says merge tags don’t honor any parameters, so there is no point in having any.

We cannot, for example, just put android:background in the merge tag if we need a background color. To implement this functionality we need to write Java code.

We see how to update the onCreate method in to achieve this.


The include tag is the opposite of the merge tag, and we can use it to modularize our XML code.

We see how to replace ImageViews with an include tag, and see three hearts rendered on the device.

We can then use the tint attribute to change the shade of every heart image:


The hearts become purple. Next we see the weight and height and marginTop parameters applied to the middle include tag. This changes the position of the middle heart, but they all remain tinted to purple.


This is similar to include insofar as it modularizes a subset of our XML into a separate file, but the sub tree isn’t loaded until needed.

Chiu-Ki demonstrates a simple app with the word “Checkerboard” and a button for displaying a 2 x 2 checkerboard.

In activity_main.xml we see a RelativeLayout. There’s a TextView, and Button, and the checkerboard is done using the include tag.

In checkerboard.xml we see there’s another RelativeLayout with 4 views inside to draw the checkerboard.

In the Hierarchy Viewer, we can see our root RelativeLayout, and this is linked to

  • TextView for “Checkerboard”
  • Button
  • The RelativeLayout that shows the checkerboard itself

Chiu-Ki explains that this RelativeLayout from checkerboard.xml is loaded even though it is invisible.

The current implementation works, but a better solution is to replace the include tag with the ViewStub.

We see the Java code needed to use a ViewStub.

We simplify the onCreate method in and cast our view to a ViewStub in the toggleDesc method.

Looking at the Hierarchy Viewer again we see a simplified tree, suggesting our app performance will be better.

Case Studies

In this final lesson we see a number of screenshots of layouts and are asked to think about how to implement them:

  • A heart image followed by “Hello”
  • An edit text view with a “Hello” button to the right
  • The flag of Vietnam
  • The flag of Austria



Chiu-Ki provides the solutions to each of these challenges.

Along the way, we learn drawableLeft and layout_alignParentLeft.

What I found interesting was there are multiple solutions for drawing the flags, and Chiu-Ki begins with a basic solution and refactors the code until we reach the most optimal solutions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s