APPLICATION ARCHITECTURE of android

3. APPLICATION ARCHITECTURE

3.1 ANDROIDMANIFEST.XML

An Android application is described in the file AndroidManifest.xml . This file must declare all Activities, Services, BroadcastReceivers and ContentProvider of the application. It must also contain the required permissions for the application. For example if the application requires network access it must be specified here. AndroidManifest.xml can be thought as the deployment descriptor for an Android application.

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android"       package=" a.b.c "       android:versionCode="1"       android:versionName="1.0">     <application android:icon="@drawable/icon"                  android:label="@string/app_name">                                                    <activity android:name=".Convert"                   android:label="@string/app_name">             <intent-filter>                 <action android:name="android.intent.action.MAIN" />                 <category android:name="android.intent.category.LAUNCHER" />             </intent-filter>         </activity>     </application>     <uses-sdk android:minSdkVersion="9" /> </manifest>

                              

               The package attribute defines the base package for the following Java elements. It also must be unique as the Android Marketplace only allows application for a specific package once. Therefore a good habit is to use your reverse domain name as a package to avoid collisions with other developers. android:versionName and android:versionCode specify the version of your application. versionName is what the user sees and can be any string. versionCode must be an integer and the Android Market uses this to determine if you provided a newer version to trigger the update on devices which have your application installed. You typically start with "1" and increase this value by one if you roll-out a new version of your application.

The tag <activity> defines an Activity , in this example pointing to the class " a.b.c ". An intent filter is registered for this class which defines that this Activity is started once the application starts (action android:name="android.intent.action.MAIN" ). The category definition category android:name="android.intent.category.LAUNCHER" defines that this application is added to the application directory on the Android device. The @string/app_name value refer to resource files which contain the actual values. This makes it easy to provide different resources, e.g. strings, colors, icons, for different devices and makes it easy to translate applications.

The "uses-sdk" part of the "AndroidManifest.xml" defines the minimal SDK version your application is valid for. This will prevent your application being installed on devices with older SDK versions.

3.2 R.java, Resources and Assets

The directory gen in an Android project contains generated values. R.java is a generated class which contains references to resources of the res folder in the project. These resources are defined in the res directory and can be values, menus, layouts, icons or pictures or animations. For example a resource can be an image or an XML file which defines strings.

If you create a new resource, the corresponding reference is automatically created in R.java . The references are static int values, the Android system provides methods to access the corresponding resource. For example to access a String with the reference id R.string.yourString use the method getString(R.string.yourString)); . R.java is automatically maintained by the Eclipse development environment, manual changes are not necessary.

While the directory res contains structured values which are known to the Android platform the directory assets can be used to store any kind of data. In Java you can access this data via the AssetsManager and the method getAssets().

3.3. REFERENCE TO RESOURCES IN XML FILES

In your XML files, e.g. your layout files you can refer to other resources via the @ sign. For example if you want to refer to a color you defined as resources you can refer to it via @color/your_id or if you have defined a "hello" string as resource you can access it via @string/hello.

3.4  ACTIVITIES AND LAYOUTS

The user interface for Activities is defined via layouts. At runtime, layouts are instances of android.view.ViewGroups . The layout defines the UI elements, their properties and their arrangement.

UI elements are based on the class android.view.View . ViewGroup is a subclass of the class View and a layout can contain UI components ( Views ) or other layouts ( ViewGroups ). You should not nestle ViewGroups too deeply as this has a negative impact on performance.

A layout can be defined via Java code or via XML. You typically uses Java code to generate the layout if you don't know the content until runtime; for example if your layout depends on content which you read from the Internet.

XML based layouts are defined via a resource file in the folder /res/layout . This file specifies the ViewGroups , Views , their relationship and their attributes for a specific layout. If a UI element needs to be accessed via Java code you have to give the UI element an unique id via the android:id attribute. To assign a new id to an UI element use @+id/yourvalue . By conversion this will create and assign a new id yourvalue to the corresponding UI element. In your Java code you can later access these UI elements via the method findViewById(R.id.yourvalue). Defining layouts via XML is usually the preferred way as this separates the programming logic from the layout definition. It also allows the definition of different layouts for different devices. You can also mix both approaches.

3.5 ACTIVITIES AND LIFECYCLE

The operating system controls the life cycle of your application. At any time the Android system may stop or destroy your application, e.g. because of an incoming call. The Android system defines a life cycle for activities via pre-defined methods. The life cycle is shown below…

Entire lifecycle

Visible Phase

onStop()

onRestart() onStart()

Foreground Phase onResume() onPause()

onCreate()

onDestroy()

              

Method	Purpose
onCreate()	Called when the Activity is created. Setup is done here.Also provided is access to any previously store state in the form of Bundle
onRestart	Called if the Activity is being restarted, if it’s still in the stack,rather than starting new.
onStart()	Called when the Activity is becoming visible on the screen to the user.
onResume()	Called when the Activity starts interacting with the user. (This methos is always called, whether starting or restarting)
onPause()	Called when the Activity is pausing or reclaiming CPU and other resources. This method is where you should save state information so that when an Activity is restarted, it can start from the same state it was when it quit.
onStop()	Called to stop the Activity and transition it to a nonvisible phase and subsequent lifecycle events.
onDestroy()	Called when the Activity is being completely removed from system memory. This method is called either because onFinish(), is directly invoked or the system decided to stop the Activity to free up resources.

Each of the lifecyclemethods Android provides has a distinct purpose, and each everything during part of the foreground, visible or entire lifecycle phase.

·         In the forefround phase, the Activity is viewable on the screen and is on top of everything else (when the user is interacting with the Activity to perform a task).

·         In the Visible phase, the Activity is on the screen, but it might be not on top and interacting with the user (when a dialog or floating window is on top of the Activity, for example).

·         The entire lifecycle phase to the methods that might be called when the application is not on the screen. Before it is created and after it’s gone (prior to being shut down).

The activity will also be restarted if a so called "configuration change" happens. A configuration change for example happens if the user changes the orientation of the device (vertical or horizontal). The activity is in this case restarted to enable the Android platform to load different resources for these configuration, e.g. layouts for vertical or horizontal mode. In the emulator you can simulate the change of the orientation via CNTR+F11 .

You can avoid a restart of your application for certain configuration changes via the configChanges attribute on your activity definition in your AndroidManifest.xml . The following activity will not be restarted in case of orientation changes or position of the physical keyboard (hidden / visible).                 

<activity android:name=".ProgressTestActivity"      android:label="@string/app_name"      android:configChanges="orientation|keyboardHidden|keyboard"> </activity>

                      

3.6  CONTEXT

The class android.content.Context provides the connections to the Android system. It is the interface to global information about the application environment. Context also provides access to Android Services , e.g. theLocation Service. As Activities and Services extend the class Context you can directly access the context via this.