ANDROID

1. ANDROID

1.1. Android Operation System

Android is an operating system based on Linux with a Java programming interface. It provides tools, e.g. a compiler, debugger and a device emulator as well as its own Java Virtual machine (Dalvik Virtual Machine - DVM).
Android is officially guided by the Open Handset Alliance but in reality Google leads the project.
Android supports 2-D and 3-D graphics using the OpenGL libraries and supports data storage in a SQLite database.
Every Android applications runs in its own process and under its own user id which is generated automatically by the Android system during deployment. Therefore the application is isolated from other running applications and a misbehaving application cannot easily harm other Android applications.

1.2. Important Android components

An Android application consists out of the following parts:

• Activity - represents the presentation layer of an Android application, e.g. a screen which the user sees. An Android application can have several activities and it can be switched between them during runtime of the application.
  
• Views - the User interface of an Activities is built with widget classes which inherent from "android.view.View". The layout of the views is managed by "android.view.ViewGroups". Views often have attributes which can be used to change their appearance and behavior.
  
• Services - perform background tasks without providing an UI. They can notify the user via the notification framework in Android.
  
• Content Provider - provides data to applications, via a content provider your application can share data with other applications. Android contains a SQLite DB which can serve as data provider
  
• Intents - are asynchronous messages which allow the application to request functionality from other services or activities. An application can call directly a service or activity (explicit intent) or ask the Android system for registered services and applications for an intent (implicit intents). For example the application could ask via an intent for a contact application. Applications register themselves to an intent via an IntentFilter. Intents are a powerful concept as they allow the creation of loosely coupled applications.
  
• Broadcast Receiver - receives system messages and implicit intents, can be used to react to changed conditions in the system. An application can register as a broadcast receiver for certain events and can be started if such an event occurs.
  
• Widgets - interactive components primary used on the Android homescreen to display certain data and to allow the user to have quick access the the information
  

Other Android components are Live Folders and Android Live Wallpapers. Live Folders display data on the homescreen without launching the corresponding application.

1.3. Dalvik Virtual Machine

Android uses a special virtual machine, e.g. the Dalvik Virtual Machine. Dalvik uses special bytecode. Therefore you cannot run standard Java bytecode on Android. Android provides a tool "dx" which allows to convert Java Class files into "dex" (Dalvik Executable) files. Android applications are packed into an .apk (Android Package) file by the program "aapt" (Android Asset Packaging Tool) To simplify development Google provides the Android Development Tools (ADT) for Eclipse . The ADT performs automatically the conversion from class to dex files and creates the apk during deployment.

1.4. Security and permissions

Android defines certain permissions for certain tasks. For example if the application wants to access the Internet it must define in its configuration file that it would like to use the related permission. During the installation of an Android application the user receives a screen in which he needs to confirm the required permissions of the application.

2. Android Application Architecture

2.1. AndroidManifest.xml

An Android application is described in the file "AndroidManifest.xml". This file must declare all activities, services, broadcast receivers and content provider 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="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 following Java elements. It also must be unique as the Android Marketplace only allows application for a specfic 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.
"activity" defines an activity in this example pointing to the class "de.vogella.android.temperature.Convert". 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 @ values 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.

2.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)); Please do not try to modify "R.java" manually.
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().

2.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.

2.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 negativ 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 view groups, 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.

2.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 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 ressource or save data
  
• onResume() - called if the Activity is re-started, can be used to initiaze fields
  

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>
   

2.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. the Location Service . As Activities and Services extend the class "Context" you can directly access the context via "this".