How To Make an Android UI Part 1: XML and Views

Many of the posts on this site so far deal with nuanced tricks such as RecyclerView swiping/drag and drops, and often make the assumption that the reader has already worked with the Android UI. This post is going to break it down for the beginners, teaching you the fundamentals of mobile UI development and where you can pick up on skills to move forward.

XML Files

In Android, layouts are most commonly generated by explicitly declaring UI elements inside an XML file. The alternative to this is programmatically adding views at run time. From the layout documentation, Android lays out the benefits of using the XML approach to creating layouts:

The advantage to declaring your UI in XML is that it enables you to better separate the presentation of your application from the code that controls its behavior. Your UI descriptions are external to your application code, which means that you can modify or adapt it without having to modify your source code and recompile. For example, you can create XML layouts for different screen orientations, different device screen sizes, and different languages. Additionally, declaring the layout in XML makes it easier to visualize the structure of your UI, so it’s easier to debug problems. As such, this document focuses on teaching you how to declare your layout in XML. If you’re interested in instantiating View objects at runtime, refer to the ViewGroupand Viewclass references.

Separating the UI logic from the application code is a major benefit for code maintainability and debugging, and for most cases will work in favor of the developer. Unfortunately, there will be cases when you need to create a dynamic UI that adds and removes Views at run time. This does not refer to adding and removing items from a list, an action that is usually handled by some type of Adapter class. This refers to the situation where you need to add a new element such as a button or input control if a certain condition is met.

Designing the XML

Okay. In order to separate the logic of our application in a beneficial way, we will define our UI inside of an XML file in the res/layout folder of our project, but what goes in the XML file? The documentation above hinted at two key classes here, View and ViewGroup. Let’s first take a look at what the ViewGroup class has to offer:

A ViewGroup is a special view that can contain other views (called children.) The view group is the base class for layouts and views containers. This class also defines the ViewGroup.LayoutParams class which serves as the base class for layouts parameters.

The View group is the base class for layouts and views containers. Put simply, this means that all of your XML files will have a parent tag that is some sort of ViewGroup. The most common ViewGroups I’ve worked with are:

  • LinearLayout
  • RelativeLayout
  • FrameLayout
  • CoordinatorLayout

There are many more you can find in the documentation, but you can expect to see these more often than anything else.

Inside of the ViewGroup, we can have any number of Views:

This class represents the basic building block for user interface components. A View occupies a rectangular area on the screen and is responsible for drawing and event handling. View is the base class for widgets, which are used to create interactive UI components (buttons, text fields, etc.). The ViewGroup subclass is the base class for layouts, which are invisible containers that hold other Views (or other ViewGroups) and define their layout properties.

So, putting all this together, let’s say we want to create a simple RelativeLayout, with two TextViews at the top left and top right corners. We can use a RelativeLayout ViewGroup as our parent item, and inside of it use two Views (TextViews, specifically) as children. Since they are children of a RelativeLayout, we can give them attributes for their relation to the parent:

I hope this is enough to get you started on creating your own layouts. If you use Android Studio, take advantage of the ‘Preview’ tab to see what your layout will look like as you add more XML elements. Be sure to read the documentation to determine what kind of parent container you need, as well as the child elements that you’re looking for.

Stay tuned for part 2, which will discuss how to access these elements from within your code and manipulate them or add more of them.

Share this post...
Share on Reddit0Share on Google+1Tweet about this on TwitterShare on LinkedIn0Share on Facebook0

Leave a Reply