AndroidManifest.xml
An Android application is described 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". For this class an intent filter is registered 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.
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 files which defines strings.
If you create a new resources, 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().
If you create a new resources, 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().
The user interface for Activities is defined via layouts.
Layouts are at runtime instances of "android.view.ViewGroups". The
layout defines the UI elements, their properties and their
arragement. UI elements are based on the class "android.view.View".
ViewGroup is a subclass of View A
and a layout can contain UI
components (Views) or other layouts
(ViewGroups). You should not
nestle ViewGroups to 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 to define different layouts for different devices. You can also mix both approaches.
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 to define different layouts for different devices. You can also mix both approaches.
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 an activities via pre-defined methods. The most important methods
are:
The activity will also be restarted if a so called "configuration change" happens. A configuration change for examples 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).
-
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 examples 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>
No comments:
Post a Comment