In this blog post we would try and understand the basics of Application Manifest in the Android system.

The simplest of any Android application has  the following components:

1. Resources classified in the resource folder (res).
2. Some auto generated code like R.java.
3. ApplicationManifest.xml file.

This blog post will deal with the third component – Application manifest file.

Application Manifest is an xml file every Android application contains with the name ApplicationMainifest.xml in the root directory of the application.

-          The file is generated automatically on finish of wizard for android project creation.
-          File gives all the information pertaining to the successful execution of all the functionalities present in the application to the android system.
-          It is like a blue print of the application components or what you can call a make file in C++ projects like Qt, Objective C in IPhone.

Sample example:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
	package="com.android.sampleApp" android:versionCode="1"
	android:versionName="1.0"> - (1)
	<application android:icon="@drawable/icon" android:label="@string/app_name"
		android:permission="android.permission.BLUETOOTH"> - (2)
		<activity android:name=".SampleActivity" android:label="@string/app_name">
			<intent-filter>
				<action android:name="android.intent.action.MAIN" />
				<category android:name="android.intent.category.LAUNCHER" />
			</intent-filter>
		</activity> - (3)
	</application>
	<uses-sdk android:minSdkVersion="9" /> - (4)
	<permission android:name="com.android.myPermission"
		android:icon="@drawable/icon"
		android:label="My Permission"
		android:protectionLevel="dangerous"
		android:permissionGroup="com.android.SamplePermission"
		android:description="@string/some_description"></permission>
</manifest>

Versioning:

Refer line (1) in the code above.

<manifest> tag consists of application versioning information (android:versionCode and android:versionName) helps the android systems to maintain the upgrade/ downgrade of application.

Android system uses versionCode for understanding the upgrade of the application on the device and versionName is used only for the user notification purpose. versionName is displayed for the user to notify that a newer version of the application is available in the market.

Activity:

Refer line (3) in the code above.

Android application consists of four types of components:

1. Service – Non-visual component always running in background to perform long operations.
2. Content providers – It’s a data storage system eg: File storage systems and SQLite. Content providers provide a standard interface that helps in application doing standard operations on database system. E.g. address book, messages, emails etc.
3. Broadcast receivers – status messages / events / error handling etc. for an example error messages,
4. Activity – Activity are screens that user interacts with while using the application, it may be a form collecting keyboard inputs, clicks etc. It is same as a form is to a web application.

Activities need to be register for an application in the Manifest file for Android systems to include them in the run environment. An application may consist of one or more activities; there can be multiple activity tags in the application which may interact with each other.

<intent-filter> – Intent filters control which actions of android, user driven or application driven is going to launch the application. Activities can contains multiple intent filters. Contains:

-          <action> as MAIN (android:name=”android.intent.action.MAIN”) means that this activity is the entry point for the application.  This activity will be the top level screen (Home screen) in the application.

-          The manifest xml above show case how you can place your activity on the android home screen launcher. For that you have to put a <category> with Launcher (android:name=”android.intent.category.LAUNCHER”) telling the system that this activity should be top-level LAUNCHER.

Permission:

Refer line (2) in the code above.

Android OS model requires applications to highlight what features of OS or resources they are going to use. Take an example of an application that is going to make use of the Bluetooth for transfer of files or need internet access for connection to facebook, twitter etc.

Hence, this tag provides the information related to the access rights to the specific components or features of the application from the very same application or other applications. By default android applications do not have any permission to intervene the device data or components.

This can be provided either in <application> tag or <uses-permission>

For example:

1. Permissions to access BLUETOOTH of device is: <application android:permission=”android.permission.BLUETOOTH” />
2. To Receive SMS: <uses-permission android:name=”android.permission.RECEIVE_SMS” />

User can define their set of permissions under <permissions> tag.

SDK Version:

Refer line (4) in the code above.

Application which makes use of specific features like 3D transitions available in higher version Android SDK say 3.0 will not work on the devices having lower version say 2.3. Hence manifest file provides the information to the system while installation; checking for the availability of SDK version and install accordingly.

<manifest> tag holds <uses-sdk> containing minimum API level  integer (android:minSdkVersion) which helps the Android system to allow/disallow installation of the application depending upon the system’s API level.

Eg: For minSdkVersion = 9 minimum system’s API level is Android 2.3.3 SDK.

For detailed information on Manifest refer:  Application Manifest

A commonly used class in any application, whether it is a desktop application or a mobile application is an application level class. An application level class also called a controller is a single instance available across the application and visible to all modules within an application. This application controller can be used to maintain global state across an application, contain common methods, etc.

Android provides support in every application to create an application wide class. The base class for this is the android.app.Application class. The official documentation of the Application class is given below:

Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's <application> tag, which will cause that class to be instantiated for you when the process for your application/package is created.

Let us look at how to incorporate an Application class in our Android applications.

Step 1: Provide an implementation of the Application class

You need to extend the android.app.Application class and override the OnCreate method. This method is invoked by the Android runtime once when your application is started. So this is a good point to do application initialization and set some global settings like shared preferences, etc.

Shown below is a template for your own Application class:

public class ApplicationController extends Application {

	//Application wide instance variables
      //Preferable to expose them via getter/setter methods
@Override
	public void onCreate() {
		super.onCreate();
		//Do Application initialization over here
        }
        //Appplication wide methods
}

Step 2: Code your Application class

You can then introduce public methods in your Application class above. These public methods can then be called from anywhere in the Android application. We shall how to invoke them in Step 4.

Step 3: Specify our Application class in the Android manifest.xml file

Specify your application class in the Android manifest.xml file. Each Android manifest has the <application> tag and you need to provide the application class as an attribute of this element as shown below:

<application android:icon="@drawable/icon" android:label="@string/app_name" android:name=".android.controller.ApplicationController">

Step 4: Utilize the Application class from other places in your application

To access the Application class instance in any activity, you can use the code as shown below:

ApplicationController AC = (ApplicationController)getApplicationContext();

The main method is getApplicationContext(). This gives an instance to the Application class if defined in the application. You need to simply type cast it to your provided Application implementation class. Once you have this instance, you can invoke any public methods that you would have defined in the class. Additionally, if you provide getter/setter methods for application wide state variables, you can invoke them too.

Having an Application wide controller in your application is a commonly used design with significant benefits. Instead of rolling out your own custom implementation, Android provides a simple mechanism to introduce it in your applications, letting you focus on your Application wide logic while it takes care of its lifecycle methods. Start using the Application class to bring in structure to your applications today.

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