concept layout in category android

This is an excerpt from Manning's book Android in Action, Third Edition. Login to get full access to this book.

The layout for this application is straightforward. The overall layout is a vertical, linear layout with only four elements; all the UI controls, or widgets, are going to be in a vertical arrangement. A number of layouts are available for Android UI design, which we’ll discuss in greater detail in chapter 3.

Figure 3.4. Class diagram of the Android View API, showing the root View class and specializations from there. Note that ViewGroup classes such as layouts are also a type of View.

As is evident from the diagram in figure 3.4, View is the base class for many classes. ViewGroup is a special subclass of View related to layout, as are other elements such as the commonly used TextView. All UI classes are derived from the View class, including the layout classes (which extend ViewGroup).

Child elements do keep track of what size they’re initially asked to be, in case layout is recalculated when things are added or removed, but they can’t force a particular size. Because of this, View elements have two sets of dimensions: the size and width they want to take up (getMeasuredWidth() and getMeasuredHeight()) and the actual size they end up after a parent’s decision (getWidth() and getHeight()). Layout is a two-step process: first, measurements are taken during the measure pass, and subsequently, the items are placed to the screen during the layout pass, using the associated LayoutParams. Components are drawn to the screen in the order in which they’re found in the layout tree: parents first, then children. Note that parent views end up behind children if they overlap in positioning.

Layout is a big part of understanding screen design with Android. Along with placing your View elements on the screen, you need to have a good grasp of focus and event handling in order to build effective applications.

Listing 20.7. Inflating the Activity layout

public class MainActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); } : : }

copy

This is an excerpt from Manning's book Android in Practice. Login to get full access to this book.

As we’ve seen, the @ sign in a layout file (which itself is a type of resource) is a reference to another resource. In the case of @string/hello we’re referring to a strings.xml file. It’s always a good idea to keep different types of entities in your project separate from the code. This goes for layouts, strings, images, XML files, and anything that Android refers to as a resource.

Once all views have been measured, the layout pass is entered. This time, each parent must position every child on the screen using the respective measurements obtained from the measure pass by calling their layout method. This process is illustrated in figure 4.3.

Figure 4.3. Views are rendered using a two-pass traversal of the view tree. Pass one collects dimension specifications (left); pass two does the positioning on the screen (right).

The layout and measuring of views happens transparently to the developer, unless you’re implementing your own View, in which case you must override onMeasure and onLayout and hence actively take part in the rendering passes. Knowing about the complexity of view rendering makes one thing obvious: drawing views is expensive, especially if many views are involved and the view tree grows large. Unfortunately, your application will spend a fair amount of time in Android’s drawing procedures. Views are invalidated and redrawn all the time, either because they’re obscured by other views or they change state. There isn’t much you can do about this, but what you can do is be aware of the overhead when writing your code and try to reduce unnecessary rendering. Table 4.1 lists some best practices for trying to optimize performance when working with views.

Table 4.1. Best practices when working with Views

Advice	Why
The cheapest View is the one that’s never drawn	If a View is hidden by default, and only appears in reaction to a user interface event such as a tap/click, you may want to consider using a ViewStub instead (a placeholder view). You can also dynamically add/remove a view from the rendering chain by setting its visibility to View.GONE.
Avoid View cluttering	Along the lines of the previous advice, think twice about using a view and simplify your UI when you can. Doing so will keep screen layouts clean, and improve performance.
Try to reuse Views where possible	Often you can avoid extra inflation and drawing by caching and reusing views. This is important when rendering lists, where many items are displayed at once and state changes frequently (like when scrolling the list). The convertView and ViewHolder pattern can help here, and is covered in technique 1 of this chapter.
Avoid excessive nesting of layouts	Some developers use nested LinearLayouts to arrange elements relative to each other. Don’t do that. The same result can usually be achieved by using a single RelativeLayout or TableLayout.
Avoid duplication	If you find yourself copying view definitions in order to use them in more than one layout, consider using the <include> tag instead. Similarly, nesting layouts of the same kind is in most cases useless duplication, and can be avoided using the <merge> tag.

View performance should always be on your mind when working with views and layouts. Some things may be obvious to you if you already have experience with Android, but we wouldn’t have mentioned them if we didn’t see applications violating these rules on a regular basis. A good idea is to always double-check your layouts for structural weaknesses using the layoutopt tool that ships with the SDK. It’s by no means the only thing you should rely on, but it’s fairly clever about finding smells in your layouts.

Mobile applications are all about user interaction: your application will likely spend most of its time in drawing its various interface elements and reacting to user input, so it’s important that you have a solid understanding of what drives your UI. Now that we’ve seen how views and layouts are organized in memory, and what algorithms Android uses to measure and position views before it draws them on the screen, we’ll next turn to more detail about layouts themselves.

4.3. Arranging views in layouts

Whenever you implement the user interface for an Activity, you’re dealing with that Activity’s layout. As we’ve already noted, layouts arrange views on screen. A layout is like a blueprint for a screen: it shows which elements the screen consists of, how they’re arranged, what they look like, and so on. Hence, when implementing a screen for your application, thinking about layout is one of the first things you should do. Knowing your layout managers is crucial if you work with designers. You’ll probably get mockups or wireframes for each screen, and you should know how to map a design to Android’s layout managers.