Introduction To Android Part II:
In last tutorial we covered the basic architecture of android and the workflow of Android mobile OS.
Let’s talk about Manifest File, Intent, Intent Filters, Activities and tasks, Launch modes, Stack, Process and Threads.
Manifest file contains the metadata about the components which we are using in an application. Each Android project includes a manifest file, “AndroidManifest.xml”, stored on the root of the project hierarchy. It includes components which we are using in our application, their attributes, what they affect our application.
So, manifest tag is used to indicate root. One basic aspect that is vital to understand while developing Android software is the process by which the Android runtime finds the startup class in an Android application package. The keys to this process lie within the application manifest.
The Generated Application Manifest File: AndroidManifest.xml(Example)
<?xml version=”1.0″ encoding=”utf-8″?>
<application android:label=”@string/app_name” android:icon=”@drawable/icon”>
<action android:name=”android.intent.action.MAIN” />
<category android:name=”android.intent.category.LAUNCHER” />
Intents are used as a message-passing mechanism that lets you declare your intention that an action be performed, usually with (or on) a particular piece of data.
An intent is an Intent object that holds the content of the message. For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things. So overall, we can use Intents to support interaction between any of the application components available on an Android device, no matter which application they’re part of. This turns a collection of independent components into a single, interconnected system.
When a component such as an Activity wants to call upon an Intent, it can do so in one of two ways:
■ Implicit Intent invocation
■ Explicit Intent invocation
An implicit Intent invocation is one in which the platform determines which component is the best to run the Intent. This happens through a process of Intent resolution using the action, data, and categories.
Explicit invocation is done by specifying either the Class or ComponentName of the receiver (where ComponentName is a String for the package and a String for the class).
If Intent is a request for an action to be performed on a set of data, how does Android know which application (and component) to use to service the request? Intent Filters are used to register Activities, Services, and Broadcast Receivers as being capable of performing an action on a particular kind of data.
An Intent object can explicitly name a target component. If it does, Android finds that component (based on the declarations in the manifest file) and activates it. But if a
target is not explicitly named, Android must locate the best component to respond to the intent. It does so by comparing the Intent object to the intent filters of potential targets.
Activities and Tasks-
A task is what the user experiences as an “application.” It’s a group of related activities, arranged in a stack. The root activity in the stack is the one that began the task.
- The activity at the top of the stack is one that’s currently running —the one that is the focus for user actions.
- When one activity starts another, the new activity is pushed on the stack; it becomes the running activity. The previous activity remains in the stack. When the user presses the BACK key, the current activity is popped from the stack, and the previous one resumes as the running activity.
- Activities in the stack are never rearranged, only pushed and popped.
- A task is a stack of activities, not a class or an element in the manifest file. So there’s no way to set values for a task independently of its activities. Values for the task as a whole are set in the root activity.
- All the activities in a task move together as a unit. The entire task (the entire activity stack) can be brought to the foreground or sent to the background.
- The association of activities with tasks, and the behavior of an activity within a task, is controlled by the interaction between flags set in the Intent object that started the activity and attributes set in the activity’s <activity> element in the manifest.
In this regard, the principal Intent flags are
The principal <activity> attributes are:
- By default, all the activities in an application have an affinity for each other —that is, there’s a preference for them all to belong to the same task.
- However, an individual affinity can be set for each activity with the taskAffinity attribute of the <activity> element.
- Activities defined in different applications can share an affinity, or activities defined in the same application can be assigned different affinities.
- The affinity comes into play in two circumstances: When the Intent object that launches an activity contains the FLAG_ACTIVITY_NEW_TASK flag, and when an activity has its allowTaskReparenting attribute set to “true”.
The FLAG_ACTIVITY_NEW_TASK flag
- If the Intent object passed to startActivity() contains the FLAG_ACTIVITY_NEW_TASK flag, the system looks for a different task to house the new activity.
- If there’s already an existing task with the same affinity as the new activity, the activity is launched into that task. If not, it begins a new task.
The allowTaskReparenting attribute-
- If an activity has its allowTaskReparenting attribute set to “true”, it can move from the task it starts in to the task it has an affinity for when that task comes to the fore.
There are four different launch modes that can be assigned to an <activity> element’s launchMode attribute:
- “standard” (the default mode)
- Note that when a new instance of an Activity is created to handle a new intent, the user can always press the BACK key to return to the previous state (to the previous activity).
- But when an existing instance of an Activity handles a new intent, the user cannot press the BACK key to return to what that instance was doing before the new intent arrived.
Clearing the stack-
- If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it’s as the user left it, except that only the initial activity is present.
- That’s the default. There are some activity attributes that can be used to control this behavior and modify it.
- The alwaysRetainTaskState attribute If this attribute is set to “true” in the root activity of a task, the default behavior just described does not happen. The task retains all activities in its stack even after a long period.
- The clearTaskOnLaunch attribute If this attribute is set to “true” in the root activity of a task, the stack is cleared down to the root activity whenever the user leaves the task and returns to it. In other words, it’s the polar opposite ofalwaysRetainTaskState. The user always returns to the task in its initial state, even after a momentary absence.
- The finishOnTaskLaunch attribute This attribute is like clearTaskOnLaunch, but it operates on a single activity, not an entire task. And it can cause any activity to go away, including the root activity.
- When it’s set to “true”, the activity remains part of the task only for the current session. If the user leaves and then returns to the task, it no longer is present.
- There’s another way to force activities to be removed from the stack. If an Intent object includes the FLAG_ACTIVITY_CLEAR_TOP flag, and the target task already has an instance of the type of activity that should handle the intent in its stack, all activities above that instance are cleared away so that it stands at the top of the stack and can respond to the intent.
- If the launch mode of the designated activity is “standard”, it too will be removed from the stack, and a new instance will be launched to handle the incoming intent. That’s because a new instance is always created for a new intent when the launch mode is “standard”.
- FLAG_ACTIVITY_CLEAR_TOP is most often used in conjunction with FLAG_ACTIVITY_NEW_TASK. When used together, these flags are a way of locating an existing activity in another task and putting it in a position where it can respond to the intent.
- An activity is set up as the entry point for a task by giving it an intent filter with “android.intent.action.MAIN” as the specified action and android.intent.category.LAUNCHER” as the specified category.
- This second ability is important: Users must be able to leave a task and then come back to it later. For this reason, the two launch modes that mark activities as always initiating a task, “singleTask” and “singleInstance”, should be used only when the activity has a MAIN and LAUNCHER filter.
Process and Threads-
- When the first of an application’s components needs to be run, Android starts a Linux process for it with a single thread of execution. By default, all components of the application run in that process and thread.
- However, you can arrange for components to run in other processes, and you can spawn additional threads for any process.
- The process where a component runs is controlled by the manifest file. The component elements —<activity>, <service>, <receiver>, and <provider> —each have a process attribute that can specify a process where that component should run.
- They can also be set so that components of different applications run in the same process —provided that the applications share the same Linux user ID and are signed by the same authorities.
- The <application> element also has a process attribute, for setting a default value that applies to all components.
- All components are instantiated in the main thread of the specified process, and system calls to the component are dispatched from that thread. Separate threads are not created for each instance.
- Android may decide to shut down a process at some point, when memory is low and required by other processes that are more immediately serving the user.
- Application components running in the process are consequently destroyed.
- A process is restarted for those components when there’s again work for them to do.
- Threads are created in code using standard Java Thread objects. Android provides a number of convenience classes for managing threads —Looper for running a message loop within a thread, Handler for processing messages, and HandlerThread for setting up a thread with a message loop.
So from next we are going to start with simple application development in android !!!