Providing a good user experience is critical to mobile applications. UI Application development in Android requires that you have a good understanding of Layouts. In this blog post, we shall cover all about Android Layouts with code samples.

Android Layout is like a container; all the screen will use either of the one layout and all the view (components) on that screen are part of the layout. The fact that mobile screen is small in size it is very important to properly design the UI.

Let us look at the various layouts offered:

• Linear Layout

This layout as name says is used to place the views in the linear flow one after the other. We can specify the manner in which view are placed linearly i.e. horizontally or vertically.

Let us have a look at the Linear Layout

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
    	>
 <TextView
 android:layout_width="fill_parent"
 android:layout_height="wrap_content"
    	 android:text="First Text View"
    	 />

 <TextView
    	 android:layout_width="fill_parent"
    	 android:layout_height="wrap_content"
    	 android:text="Second Text View"
    	 />
 </LinearLayout>

As shown the above Linear Layout have two Text Views and have orientation set to vertical (android:orientation=“vertical”), hence the two Text Views will be drawn vertically one below the other.

Figure 1: Linear Layout Vertical Orientation

Look at the above XML for Linear Layout, width for layout along with Text View with the layout is set to fill_parent (android:layout_width=“fill_parent”). And since Linear Layout is the top most layout and width set to fill parent it will be stretched to cover entire screen. Similarly both the Text Views also have width set to fill parent, and since they are child to Linear Layout they are stretched to entire screen width.

Now let us change the orientation of linear layout to horizontal (android:orientation=“horizontal”).  Just changing the orientation to horizontal will draw Text View next to each other, but since each of the text view is set to have width as fill parent and by default both are written from left to right (Gravity) only one Text View (First Text View) will be visible. To overcome this set width for both the Text View to wrap_content (android:layout_width=“wrap_content”).

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="horizontal"
    	android:layout_width="fill_parent"
    	android:layout_height="fill_parent"
    	>
<TextView
    		android:layout_width="wrap_content"
    		android:layout_height="wrap_content"
    		android:text="First Text View"
      />

    		<TextView
    		android:layout_width="wrap_content"
    		android:layout_height="wrap_content"
    	android:text="Second Text View"
    		android:paddingLeft="10px"
    		/>
  </LinearLayout>

Note: Since we have set width for both the Text View as wrap_content, 2^nd Text View will start as soon as 1^st end. Hence in the above xml we have provided left padding for 2^nd Text View in order to have some space between the 2 Text View.

Figure 2 Linear Layout Horizontal Orientation

• Table Layout

Using this layout we can place view/components in tabular format.  The best example to understand this layout is Login Screen. Below XML shows Table layout

<?xml version="1.0" encoding="utf-8"?>
<TableLayout android:id="@+id/TableLayout01"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
xmlns:android="http://schemas.android.com/apk/res/android">

		<TableRow android:id="@+id/TableRow01">
			<TextView android:id="@+id/TextView01"
			android:text="User Name:"
			android:width="100px"/>

			<EditText android:id="@+id/EditText01"
			android:width="220px"/>
		</TableRow>

		<TableRow android:id="@+id/TableRow02">
			<TextView android:id="@+id/TextView02"
			android:text="Password:"
			/>

			<EditText android:id="@+id/EditText02"
			android:inputType="textPassword"/>
		</TableRow>

		<TableRow android:id="@+id/TableRow03">
			<Button android:id="@+id/Button01"
			android:layout_width="wrap_content"
			android:layout_height="wrap_content" android:text="Login"/>

			<Button android:id="@+id/Button02"
			android:layout_width="wrap_content"
			android:layout_height="wrap_content" android:text="Reset"
			android:width="100px"/>
</TableRow>
</TableLayout>

As shown Table consist of three rows (Table Row) and each row as two views/components. Number of columns in table is determined by the maximum number of components in a single row.

Figure 3 : Table Layout

One more important point to note here is that even after specifying width of Reset button in xml to 100 pixel  (android:width=“100px”), it’s width is same as that of Edit Text. This is because width of Column is determined by the maximum width of the component in that column and here Reset button is same the column as Edit Text which has width set to 220 pixel.

• Relative Layout

This layout is flexible layout of all. This layout as name suggest allow placing components relative to other component or layout. Let us see at the example

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout android:id="@+id/RelativeLayout01"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
xmlns:android="http://schemas.android.com/apk/res/android">
<TextView android:id="@+id/TextView01"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="User Name:"
android:width="100px"/>
<EditText android:id="@+id/EditText01"
android:layout_width="220px"
android:layout_height="wrap_content"
android:layout_toRightOf="@+id/TextView01"
android:layout_below="@+id/RelativeLayout01"
/>

<EditText android:id="@+id/EditText02"
android:layout_width="220px"
android:layout_height="wrap_content"
android:layout_below="@+id/EditText01"
android:layout_alignLeft="@+id/EditText01"
/>

<TextView android:id="@+id/TextView02"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Password:"
android:width="100px"
android:layout_below="@+id/EditText01"
android:layout_toLeftOf="@+id/EditText02"
/>

<Button android:text="Login"
android:id="@+id/Button01"
android:layout_width="100px"
android:layout_height="wrap_content"
android:layout_below="@id/EditText02"
android:layout_alignLeft="@id/EditText02"
/>

<Button android:text="Reset"
android:id="@+id/Button02"
android:layout_width="100px"
android:layout_height="wrap_content"
android:layout_below="@id/EditText02"
android:layout_alignRight="@id/EditText02"
/>

</RelativeLayout>

As shown,  EditText 01 has attributes android:layout_toRightOf=“@+id/TextView01″ and android:layout_below=“@+id/RelativeLayout01” for placing Edit Text next to Text View (User Name) . Similarly check EditText02 as attributes android:layout_below=“@+id/EditText01″ and android:layout_alignLeft=“@+id/EditText01″ for placing Edit Text box below the Edit Text 01.

Figure 4 Relative Layout

• Absolute Layout

As name suggest this layout is used to place views/components at the exact location on the screen using x and y. Let us see example

<?xml version="1.0" encoding="utf-8"?>
<AbsoluteLayout android:id="@+id/AbsoluteLayout01"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
xmlns:android="http://schemas.android.com/apk/res/android">
<EditText
android:id="@+id/EditText01"
android:layout_width="200px" android:layout_height="wrap_content"
android:layout_x="12px"
android:layout_y="12px"/>
<Button android:text="Search"
android:id="@+id/Button01"
android:layout_width="100px" android:layout_height="wrap_content"
android:layout_x="220px"
android:layout_y="12px"/>
</AbsoluteLayout>

Figure 5 Absolute Layout

As seen we have specified android:layout_x and android:layout_y for both the components  their by providing the absolute location for the components.

• Frame Layout

Frame Layout is one of the simplest layouts. It is like a single screen and all the views/components child to this layout will be drawn on same screen anchored to the top left corner of the screen. So it is likely that one view can overall another one and hides it unless it is transparent. Let see the example

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout android:id="@+id/FrameLayout01"
android:layout_width="fill_parent" android:layout_height="fill_parent"
xmlns:android="http://schemas.android.com/apk/res/android">

<ImageView android:id="@+id/ImageView01"
android:src="@drawable/taj_mahal"
android:scaleType="center"
android:layout_width="fill_parent" android:layout_height="fill_parent"/>

<TextView android:text="Taj Mahal"
android:id="@+id/TextView01"
android:layout_width="wrap_content" android:layout_height="wrap_content"
android:layout_marginBottom="20dip"
android:layout_gravity="center_horizontal|bottom"
android:padding="10dip"
android:textColor="#FFFFFF"
android:background="#AA0000"
/>
</FrameLayout>

Figure 6 Frame Layout

Note: taj_mahal.jpg is in drawable folder

Conclusion

We looked at the basic android layouts and tried to understand them with their respective examples.

Enterprise software is now going mobile. More and more work, which needed your presence in office/home, can be done on-the-go. With introduction of addictive UIs on smart phones, the market for Mobile based Software has grown into a new niche.

Smart phone applications can be categorized in to Native Applications and Web Applications. Native apps are downloaded on the device may or may not require internet connectivity. Most of the games and utilities like calculator, unit-converter fall in this category. Web Apps are applications that run on the device’s inbuilt browser. It does not need downloading, but requires continuous internet connectivity in most cases.

Both types of applications on Mobile can be developed by following these interdependent life cycle stages:

1. Design: A typical smart phone dimensions of 320×480 gives a very limited real estate to stuff-in the amazing functionalities they can support. Designers really need to master the art of small.

Native

The design needs to be in alignment with various UI standards and can closely follow Human Interface Guidelines(HIG) from Apple. Though they have defined it for iPhone, many of them in my opinion are pure common sense. Hence, HIG is applicable for all devices, specifically for the Native apps. The smart-phone vendors (RIM, Apple etc.) have gone a long way in providing standard and useful applications to their users via their own app-stores.

Web Based

In web based application development, for multiple devices for e.g. for iPhone and Blackberry Bold, design issues need to be taken care at the CSS level. For lower versions of Blackberry though UI has to be generated by a different code set.

2. Server side: APIs not only cater to web based mobile applications, native applications too need to shift the data intensive computation to server side. So there is not much difference between the server side programming for Web and Native apps. Bringing website functionality to mobile is not mere reuse of APIs. It involves optimization of existing APIs for performance. It may also involve revisiting the code for adding device specific checks, abstraction and exception handling etc.

3. Client side: iPhone, Blackberry, Android, Windows Mobile, Symbian have their own SDKs for development of Native Apps. While iPhone requires experience on Objective C and Mac OS, Blackberry and Android can be handled by Java developers while Windows mobile application can be created using Visual Studio 2008.

Native

Advanced hardware like inbuilt camera, accelerometers etc can also be harnessed for making the mobile application feature-rich – like Auto-orientation, motion based gaming etc. The inbuilt GPS and assisted GPS can be leveraged for creating location based services. Though a plethora of applications are already providing LBS, I find it to be a tip of the iceberg. Adding LBS can make a lot of applications information rich, for end users as well as for vendors, distributors and advertisers.

Web Based

Web based applications on almost all devices, sparing iPhone in some cases; do not need specified SDKs for development. The major issue for web based apps is handling the large number of device-browser combinations that a user may use. What works for IE on BB may not work for FF on the same device. To resolve the issue of developing and maintaining code for different devices XHTML-MP is gaining wide popularity among developers.

4. Testing: Other than functionality and UI related testing, Mobile app QA requires testing for performance and connectivity related issues.

Native

Mobile software requires to be tested in real (non-simulated) Wi-Fi, GPRS, 3G etc. with different service providers. Something that works on AT&T may be blocked by T-Mobile. Also, an internet savvy application may behave differently in different geographies. Based on expected usage, the application should be tested for all the geographies. One may take assistance from www.deviceanywhere.com.

Web Based

Web apps always need to be tested on variety of browsers (Mobile browsers) for rendering issues. iPhone supports Safari, while BB supports IE and Firefox and also has it’s own browser. Rigorous manual testing can reveal functionality glitches and alignment issues. Generally for all types of browsers, testing and debugging using Firebug and HTTP watch can be quite helpful.

One should plan the development of mobile applications with these distinct yet interdependent processes in mind. It should really help in developing a standard application in minimum time.

-Ujjwal Trivedi