4. Android Application Architecture

4.1. AndroidManifest.xml

The components and settings of an Android application are described in the file AndroidManifest.xml. For example all Activities and Services of the application must be declared in this file.
It must also contain the required permissions for the application. For example if the application requires network access it must be specified here.

    
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="de.vogella.android.temperature"
      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 Java objects referred to in this file. If a Java object lies within a different package, it must be declared with the full qualified package name.
Google Play requires that every Android application uses its own unique package. Therefore it is a good habit to use your reverse domain name as package name. This will avoid collisions with other Android applications.
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. The Android Market determine based on the versionCode, if it should perform an update of the applications for the existing installations. 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 Convert class in the de.vogella.android.temperature package. 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 refers to resource files which contain the actual value of the application name. The usage of resource file 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" file defines the minimal SDK version for which your application is valid. This will prevent your application being installed on devices with older SDK versions.

4.2. R.java and Resources

The " gen " directory in an Android project contains generated values. R.java is a generated class which contains references to certain resources of the project.
These resources must be defined in the "res" directory and can be XML files, icons or pictures. You can for example define values, menus, layouts or animations via XML files.
If you create a new resource, the corresponding reference is automatically created in R.java via the Eclipse ADT tools. These references are static int values and define ID's for the resources.
The Android system provides methods to access the corresponding resource via these ID's.
For example to access a String with the R.string.yourString ID, you would use the getString(R.string.yourString)) method.
R.java is automatically created by the Eclipse development environment, manual changes are not necessary and will be overridden by the tooling.

4.3. Assets

While the res directory contains structured values which are known to the Android platform, the assets directory can be used to store any kind of data. You access this data via the AssetsManager which you can access the getAssets() method.
AssetsManager allows to read an assets as InputStream with the open() method.

    
// Get the AssetManager
AssetManager manager = getAssets();

// Read a Bitmap from Assets
try {
 InputStream open = manager.open("logo.png");
 Bitmap bitmap = BitmapFactory.decodeStream(open);
 // Assign the bitmap to an ImageView in this layout
 ImageView view = (ImageView) findViewById(R.id.imageView1);
 view.setImageBitmap(bitmap);
} catch (IOException e) {
 e.printStackTrace();
}
   

4.4. Activities and Layouts

The user interface for Activities is defined via layouts. The layout defines the included Views (widgets) and their properties.
A layout can be defined via Java code or via XML. In most cases the layout is defined as an XML file.
XML based layouts are defined via a resource file in the /res/layout folder. This file specifies the ViewGroups, Views, their relationship and their attributes for this specific layout.
If a View needs to be accessed via Java code, you have to give the View a unique ID via the android:id attribute. To assign a new ID to a View use @+id/yourvalue. The following shows an example in which a Button gets the "button1" ID assigned.

    
<Button
 android:id="@+id/button1"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="Show Preferences" >
</Button>
   

By conversion this will create and assign a new yourvalue ID to the corresponding View. In your Java code you can later access a View 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.

4.5. Reference to resources in XML files

In your XML files, for example your layout files, you can refer to other resources via the @ sign.
For example, if you want to refer to a color which is defined in a XML resource, you can refer to it via @color/your_id. Or if you defined a "hello" string in an XML resource, you could access it via @string/hello.

4.6. Activities and Lifecycle

The Android system controls the lifecycle 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 lifecycle for Activities via predefined methods. The most important methods are:

• onSaveInstanceState() - called if the Activity is stopped. Used to save data so that the Activity can restore its states if re-started
• onPause() - always called if the Activity ends, can be used to release resource or save data
• onResume() - called if the Activity is re-started, can be used to initialize fields

4.7. Configuration Change

An Activity will also be restarted, if a so called "configuration change" happens. A configuration change happens if an event is triggered which may be relevant for the application. For example if the user changes the orientation of the device (vertically or horizontally). Android assumes that an Activity might want to use different resources for these orientations and restarts the Activity.
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>
   

4.8. 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. the Location Service. Activities and Services extend the Context class and can therefore be used as Context.