8.1 XML Layout Basics

Understanding XML in Android Layouts

In Android, user interfaces are usually described with XML files. These files tell Android what views to create and how to arrange them on the screen. You will later learn about specific layout types such as LinearLayout and ConstraintLayout. In this chapter, you focus on the common XML basics that all layouts share.

An Android layout XML file is a text file written in the XML format. It is stored in the res/layout directory of your project and usually describes the UI for a single screen, a part of a screen, or an individual reusable component. When your activity or fragment starts, Android reads this XML, creates the actual view objects in memory, and displays them on the screen.

Every layout XML file has one root element, which is usually a layout container such as LinearLayout, ConstraintLayout, or sometimes a single view like TextView if the layout is extremely simple. Inside this root element you place child views and other layout containers to build your interface.

Basic Structure of a Layout XML File

A typical layout XML file starts with an XML declaration line. After that, the root view element appears, which includes special attributes for namespaces and layout dimensions.

Here is a simplified example of a layout file named activity_main.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:id="@+id/helloText"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Hello Android" />
</LinearLayout>

The first line declares the XML version and encoding. The next line starts the root element LinearLayout. It contains an XML namespace declaration and some attributes that are common to almost all views.

You do not need to memorize every part right away. Over time, you will recognize common patterns. For now, concentrate on the role of attributes such as android:layout_width, android:layout_height, and android:id, because they appear in nearly every view.

XML Namespaces and the `android` Prefix

When you see attributes like android:layout_width, the android: part is a namespace prefix. It tells Android which group of attributes the name belongs to. In most layout files, you will see a line similar to this on the root view:

xmlns:android="http://schemas.android.com/apk/res/android"

This line defines the android prefix and maps it to a specific URI. You do not access that URI directly in your code. Instead, it is used by the tools so that they can understand which attributes are standard Android attributes.

You might also see other prefixes, such as app: or tools:, declared in a similar way. Those will be important later when you work with ConstraintLayout, custom attributes, or design-time tools. For basic layouts, you mainly use the android: prefix.

If you forget the namespace or type attribute names without a prefix, Android Studio will usually show an error or suggestion. Rely on the editor to help you correct these early mistakes while you are learning.

Common Layout Attributes: Width and Height

Every view and layout in Android must define its width and height. These are specified with android:layout_width and android:layout_height. They tell the layout system how much space each view wants to occupy.

The simplest values you will see are match_parent and wrap_content. You will sometimes see exact values like 100dp, but for beginners the first two are more important.

wrap_content tells the view to be only as big as needed to display its content. For a TextView, wrap_content gives just enough space to show the text. For an ImageView, it makes the view as large as the image it displays, unless other constraints are applied by the parent layout.

match_parent tells the view to expand to fill as much space as its parent layout allows in that direction. For example, a Button with android:layout_width="match_parent" tries to take the full available width inside its parent container.

When you create a new view, you must always set these two attributes for at least its root. Many child views also need them, although some layout editors can auto-generate them for you.

You will later see how exact sizes in dp (density independent pixels) work together with more advanced layout rules. For now, remember that width and height are always required, and wrap_content and match_parent are the most common starting choices.

View IDs and Reference by Code

To interact with views from your Kotlin code, for example to change text or set a click listener, you need a way to identify those views. This is done by assigning an ID in the XML file using the android:id attribute.

The typical pattern for an ID looks like this:

android:id="@+id/helloText"

The @+id/ part tells Android that you are defining a new ID resource with the name helloText. The plus sign indicates creation if it does not exist yet. Later, when you want to refer to this view in another XML file or in code, you use @id/helloText in XML or R.id.helloText in Kotlin.

If you do not give a view an ID, you can still see it on the screen, but you cannot easily access it in your code. Anything you plan to manipulate programmatically, such as changing text or visibility, should have an ID.

XML Tags, Attributes, and Hierarchy

In XML, tags define elements and attributes describe properties of those elements. In Android layout XML, each tag corresponds to a view class or a layout class. For example, the <TextView> tag represents the TextView class. The tag name must match the class name, including capitalization.

Android uses a nested structure in layout files. The root view contains child views. Child views can contain their own children if they are layout containers. This nesting describes the view hierarchy, which is how Android organizes the UI on the screen.

Here is an example with multiple nested views:

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:id="@+id/titleText"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Title" />
    <Button
        android:id="@+id/okButton"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="OK" />
</LinearLayout>

In this example, the LinearLayout is the parent, and it has two children, a TextView and a Button. The layout type controls how these children are arranged, but the concept of nesting is always the same, regardless of layout type.

You will later learn specific attributes that layouts use to position their children, but the idea of a hierarchy and nesting is fundamental and always present.

Using the Layout Editor and XML Together

Android Studio provides a visual layout editor and an XML editor side by side. When you drag and drop views in the visual editor, Android Studio updates the XML for you. When you type in the XML, the Preview updates automatically.

As a beginner, it is helpful to watch how the XML changes when you make a change in the visual editor. For example, if you drag a Button into the layout, the editor will add a <Button> tag with several attributes. If you change the text in the Properties panel, you see the android:text attribute change in XML.

You can switch between different views of the layout editor, such as Design view, Code view, or a split view that shows both. Working often in split view is useful because it helps you connect what you see visually with the underlying XML description.

You do not have to write all layout XML by hand, but understanding it will give you much more control and confidence when something does not look right or when you want to create more precise designs.

Basic Text and Image Attributes

Most views have some basic attributes that you will use frequently, especially for text and images. While later chapters handle styles and theming in more depth, it is useful here to see how simple content is added directly in the XML.

For text based views, such as TextView and Button, the android:text attribute sets the visible text if you are not yet using string resources. For example:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Welcome" />

For image based views, such as ImageView, the android:src attribute specifies which drawable resource to display. You might see something like:

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/ic_launcher_foreground" />

In both cases, simple inline values work for quick tests, though later you should move to resources such as @string/... and @drawable/... for better structure and reuse.

Working with Resource References

In layout XML you rarely type plain values for everything. Instead, you often refer to resources stored elsewhere. You have already seen IDs and drawables. The same pattern applies to many other values.

A resource reference usually starts with @, followed by the resource type, a slash, and the resource name. For example, @string/app_name, @color/primaryColor, @dimen/padding_standard, or @drawable/logo.

Here is a short example that uses a string reference and a color reference:

<TextView
    android:id="@+id/infoText"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/info_message"
    android:textColor="@color/black" />

The real value for the text is defined in a separate XML file in res/values/strings.xml. The color is defined in res/values/colors.xml. Using references instead of hard coded values makes your layout XML easier to maintain, and it prepares your app for translation and theming.

Later chapters about resources, styles, and themes will show how to create and organize these values in more detail. For now, pay attention to the @ notation and remember that it indicates a resource reference, not a literal value.

Self-Closing Tags and Multi-Line Tags

In layout XML, you will see two styles of writing tags: one that uses an explicit closing tag and one that closes itself on the same line. Both are valid and depend on whether the view has child elements.

If a view has children, you must use a start and end tag:

<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />
</LinearLayout>

If a view does not contain any other views, it can be written as a self closing tag:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" />

The /> at the end means the view has no child elements. It is purely a matter of structure, not behavior. Android treats both forms the same, as long as the nesting is correct.

Naming Layout Files and Using Them in Code

Layout XML files sit in the res/layout folder and must follow a naming rule. They should use only lowercase letters, numbers, and underscores. Spaces and capital letters are not allowed. For example, activity_main.xml, fragment_home.xml, or list_item_user.xml are valid names, while MainActivityLayout.xml or home-screen.xml are not.

Android uses these filenames as resource names. In Kotlin, when you want to set a layout for an activity, you typically write something like:

setContentView(R.layout.activity_main)

The R.layout.activity_main part refers to the activity_main.xml file in the layout folder. The R class is generated automatically and gives you type safe access to your resources.

If you rename a layout file, Android Studio can update references in code for you. It is still a good idea to use clear and consistent names from the beginning, such as prefixing layout files with activity_, fragment_, or item_ depending on their purpose.

Summary of Essential XML Layout Concepts

XML layout files describe the structure and basic properties of your Android user interface. Each file has a single root view, usually a layout container, and a nested hierarchy of child views.

You learned that every view must define android:layout_width and android:layout_height, typically using wrap_content or match_parent. IDs created with android:id="@+id/..." let you access views from Kotlin code. XML namespaces such as xmlns:android enable the use of standard attributes, and resource references like @string/... or @drawable/... keep values organized.

With these basics in place, you are ready to explore specific layout types such as LinearLayout and ConstraintLayout, where you will learn how to position and align views using additional layout specific attributes.