Wednesday, 15 February 2017

Android Application Architecture...

Android Application Architecture

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. 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="Tutorial.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>



Here is the description for all tags :-
<manifest>
This is the root node of each AndroisManifest.xml. It contains the package-attribute, which points to any package in out Activity. Other Activities-path will base relative to its value.
<manifest xmlns:android="http://schemas.android.com/
apk/res/android" package="org.anddev.android.smstretcher">
<uses-permission>
Describes a security permission, which your package must be granted in order for it to operate correctly (i.e. when you want to send SMS or use the Phone-Contacts). The permissions get granted by the user during installation of your application. Quantity:
<uses-permission android:name=" android.permission.RECEIVE_SMS"/>
<permission>
Declares a security permission that can be used to restrict which applications can access components or features in your (or another) package. Quantity:
<instrumentation>
Declares the code of an instrumentation component that is available to test the functionality of this or another package. See Instrumentation for more details. Quantity
<application>
Root element containing declarations of the application-level components contained in the package. This element can also include global and/or default attributes for the application, such as a label, icon, theme, required permission, etc. Quantity: 0 or 1.
<application android:icon="@drawable/icon">
You can place 0+of each of the following children:
<activity>
An Activity is the primary thing for an application to interact with the user. The initial screen the user sees when launching an application is an activity, and most other screens they use will be implemented as separate activities declared with additional activity tags.
<activity android:name=".Welcome"
android:label="@string/app_name">
Note: Every Activity must have an <activity> tag in the manifest whether it is exposed to the world or intended for use only within its own package. If an Activity has no matching tag in the manifest, you won't be able to launch it. Optionally, to support late runtime lookup, you can include 1+ <intent-filter> elements to describe the actions the activity supports.
<intent-filter>
Declares what kind of Intents a component supports. In addition to the various kinds of values that can be specified under this element, attributes can be given here to supply a unique label, icon, and other information for the action being described.
<intent-filter>
<action>
An action-type that the component supports. Example:
<action android:name="android.intent.action.MAIN" />
<category>
A category-type that the component supports. Example:
<category android:name="android.intent.category.
LAUNCHER" />
<data>
An MIME type, URI scheme, URI authority, or URI path that the component supports. You can also associate 1+ pieces of meta-data with your activity:
<meta-data>
Adds a new piece of meta data to the activity, which clients can retrieve through ComponentInfo.metaData.
<receiver>
An IntentReceiver allows an application to be told about changes to data or actions that happen, even if it is not currently running. As with the activity tag, you can optionally include 1+ <intent-filter> elements that the receiver supports or <meta-data> values, just all the same as with <activity>.
<receiver android:name=".SMSReceiver">
<service>
A Service is a component that can run in the background for an arbitrary amount of time. As with the activity tag, you can optionally include one or more <intent-filter> elements that the service supports or <meta-data> values; see the activity's <intent-filter> and <meta-data> descriptions for more information.
<provider>
A ContentProvider is a component that manages persistent data and publishes it for access by other applications. You can also optionally attach one or more <meta-data> values, as described in the activity's <meta-data> description. Of course all <tags> have to be </closed> or closed <directly/>.
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. 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 for which your application is valid. This will prevent your application being installed on devices with older SDK versions.

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));.
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. 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 .

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.

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 resource or save data
  • onResume() - called if the Activity is re-started, can be used to initialize 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>

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.

No comments:

Post a Comment