30-06-2012, 03:37 PM
Android Application Development
[attachment=26325]
Working Principle
2.1. DEVELOPING APPLICATIONS
2.1.1.Application Building Blocks
We can think of an Android application as a collection of components, of various kinds. These components are for the most part quite loosely coupled, to the degree where you can accurately describe them as a federation of components rather than a single cohesive application. Generally, these components all run in the same system process. It's possible (and quite common) to create multiple threads within that process, and it's also possible to create completely separate child processes if you need to. Such cases are pretty uncommon though, because Android tries very hard to make processes transparent to your code. Google provides three versions of SDK for Windows, for Mac OSX and one for Linux.The developer can use Android plugin for Eclipse IDE or other IDEs such as intelliJ. First step for Android developer is to decompose the prospective application into the components, which are supported by the platform. The major building blocks are these:
• Activity
• Intent Receiver
• Service
• Content Provider
Activity
User interface component, which corresponds to one screen at time. It means that for the simple application like Address Book, the developer should have oneactivity for displaying contacts, another activity component for displaying more detailed information of chosen name and etc.
Intent Receiver
Wakes up a predefined action through the external event. For example,for the application like Email Inbox, the developer should have intent receiver and register his code through XML to wake up an alarm notification, when the user receives email.
Service
A task, which is done in the background. It means that the user can start an application from the activity window and keep the service work, while browsing other applications. For instance, he can browse Google Maps application while holding a call or listening music while browsing other applications.
Content Provider
A component, which allows sharing some of the data with other processes and applications. It is the best way to communicate the applications between each other.Android will ship with a set of core applications including an email client,SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.
2.1.2.AndroidManifest.xml
The AndroidManifest.xml file is the control file that tells the system what to do with all the top-level components (specifically activities, services, intent receivers, and content providers described below) you've created. For instance, this is the "glue" that actually specifies which Intents your Activities receive. A developer should predefine and list all components, which he wants to use in the specific Android Manifest.xml file. It is a required file for all the applications and is located in the root folder. It is possible to specify all global values for the package,all the components and its classes used, intent filters, which describe where andwhen the certain activity should start, permissions and instrumentation like security control and testing.
Here is an example of AndroidManifest.xml file:
1. <?xml version="1.0" encoding="utf-8"?>
2. <manifest xmlns:android="http://schemas.androidapk/res/android"
3. package="dk.mdev.android.hello">
4. <application android:icon="@drawable/icon">
5. <activity class=".HelloAndroid" android:label="@string/app_name">
6. <intent-filter>
7. <action android:value="android.intent.action.MAIN" />
8. <category android:value="android.intent.category.LAUNCHER"/>
9. </intent-filter>
10. </activity>
11. </application>
12. </manifest>
The line 2 is a namespace declaration, which makes a standard Android attributes available for that application. In the line 4 there is a single <application> element, where the developer specifies all application level components and its properties used by the package. Activity class in the line 5 represents the initial screen the user sees and it may have one or more <intent-filter> elements to describe the actions that activity supports.
2.1.3.Application Lifecycle
In Android, every application runs in its own process, which gives better performance in security, protected memory and other benefits. Therefore, Android is responsible to run and shut down correctly these processes when it is needed. It is important that application developers understand how different application components (in particular Activity, Service, and BroadcastReceiver) impact the lifetime of the application's process. Not using these components correctly can result in the system killing the application's process while it is doing important work. To determine which processes should be killed when low on memory, Android places each process into an "importance hierarchy" based on the components running in them and the state of those components. These process types are (in order of importance).
1. A foreground process is one that is required for what the user is currently doing. Various application components can cause its containing process to be considered foreground in different ways. A process is considered to be in the foreground if any of the following conditions hold:
i. It is running an Activity at the top of the screen that the user is interacting with (its onResume() method has been called).
ii. It has a BroadcastReceiver that is currently running (its BroadcastReceiver.onReceive() method is executing).
iii. It has a Service that is currently executing code in one of its callbacks (Service.onCreate(), Service.onStart(), or Service.onDestroy()).
There will only ever be a few such processes in the system, and these will only be killed as a last resort if memory is so low that not even these processes can continue to run. Generally, at this point, the device has reached a memory paging state, so this action is required in order to keep the user interface responsive.
2. A visible process is one holding an Activity that is visible to the user on-screen but not in the foreground (its onPause() method has been called). This may occur, for example, if the foreground Activity is displayed as a dialog that allows the previous Activity to be seen behind it. Such a process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
3. A service process is one holding a Service that has been started with the startService() method. Though these processes are not directly visible to the user,they are generally doing things that the user cares about (such as background mp3 playback or background network data upload or download), so the system will always keep such processes running unless there is not enough memory to retain all foreground and visible process.
4. A background process is one holding an Activity that is not currently visible to the user (its onStop() method has been called). These processes have no direct impact on the user experience. Provided they implement their Activity life-cycle correctly (see Activity for more details), the system can kill such processes atany time to reclaim memory for one of the three previous processes types.
Usually there are many of these processes running, so they are kept in an LRU list to ensure the process that was most recently seen by the user is the last to be killed when running low on memory.
5. An empty process is one that doesn't hold any active application components. The only reason to keep such a process around is as a cache to improve startup time the next time a component of its application needs to run. As such, the system will often kill these processes in order to balance overall system resources between these empty cached processes and the underlying kernel caches.
[attachment=26325]
Working Principle
2.1. DEVELOPING APPLICATIONS
2.1.1.Application Building Blocks
We can think of an Android application as a collection of components, of various kinds. These components are for the most part quite loosely coupled, to the degree where you can accurately describe them as a federation of components rather than a single cohesive application. Generally, these components all run in the same system process. It's possible (and quite common) to create multiple threads within that process, and it's also possible to create completely separate child processes if you need to. Such cases are pretty uncommon though, because Android tries very hard to make processes transparent to your code. Google provides three versions of SDK for Windows, for Mac OSX and one for Linux.The developer can use Android plugin for Eclipse IDE or other IDEs such as intelliJ. First step for Android developer is to decompose the prospective application into the components, which are supported by the platform. The major building blocks are these:
• Activity
• Intent Receiver
• Service
• Content Provider
Activity
User interface component, which corresponds to one screen at time. It means that for the simple application like Address Book, the developer should have oneactivity for displaying contacts, another activity component for displaying more detailed information of chosen name and etc.
Intent Receiver
Wakes up a predefined action through the external event. For example,for the application like Email Inbox, the developer should have intent receiver and register his code through XML to wake up an alarm notification, when the user receives email.
Service
A task, which is done in the background. It means that the user can start an application from the activity window and keep the service work, while browsing other applications. For instance, he can browse Google Maps application while holding a call or listening music while browsing other applications.
Content Provider
A component, which allows sharing some of the data with other processes and applications. It is the best way to communicate the applications between each other.Android will ship with a set of core applications including an email client,SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.
2.1.2.AndroidManifest.xml
The AndroidManifest.xml file is the control file that tells the system what to do with all the top-level components (specifically activities, services, intent receivers, and content providers described below) you've created. For instance, this is the "glue" that actually specifies which Intents your Activities receive. A developer should predefine and list all components, which he wants to use in the specific Android Manifest.xml file. It is a required file for all the applications and is located in the root folder. It is possible to specify all global values for the package,all the components and its classes used, intent filters, which describe where andwhen the certain activity should start, permissions and instrumentation like security control and testing.
Here is an example of AndroidManifest.xml file:
1. <?xml version="1.0" encoding="utf-8"?>
2. <manifest xmlns:android="http://schemas.androidapk/res/android"
3. package="dk.mdev.android.hello">
4. <application android:icon="@drawable/icon">
5. <activity class=".HelloAndroid" android:label="@string/app_name">
6. <intent-filter>
7. <action android:value="android.intent.action.MAIN" />
8. <category android:value="android.intent.category.LAUNCHER"/>
9. </intent-filter>
10. </activity>
11. </application>
12. </manifest>
The line 2 is a namespace declaration, which makes a standard Android attributes available for that application. In the line 4 there is a single <application> element, where the developer specifies all application level components and its properties used by the package. Activity class in the line 5 represents the initial screen the user sees and it may have one or more <intent-filter> elements to describe the actions that activity supports.
2.1.3.Application Lifecycle
In Android, every application runs in its own process, which gives better performance in security, protected memory and other benefits. Therefore, Android is responsible to run and shut down correctly these processes when it is needed. It is important that application developers understand how different application components (in particular Activity, Service, and BroadcastReceiver) impact the lifetime of the application's process. Not using these components correctly can result in the system killing the application's process while it is doing important work. To determine which processes should be killed when low on memory, Android places each process into an "importance hierarchy" based on the components running in them and the state of those components. These process types are (in order of importance).
1. A foreground process is one that is required for what the user is currently doing. Various application components can cause its containing process to be considered foreground in different ways. A process is considered to be in the foreground if any of the following conditions hold:
i. It is running an Activity at the top of the screen that the user is interacting with (its onResume() method has been called).
ii. It has a BroadcastReceiver that is currently running (its BroadcastReceiver.onReceive() method is executing).
iii. It has a Service that is currently executing code in one of its callbacks (Service.onCreate(), Service.onStart(), or Service.onDestroy()).
There will only ever be a few such processes in the system, and these will only be killed as a last resort if memory is so low that not even these processes can continue to run. Generally, at this point, the device has reached a memory paging state, so this action is required in order to keep the user interface responsive.
2. A visible process is one holding an Activity that is visible to the user on-screen but not in the foreground (its onPause() method has been called). This may occur, for example, if the foreground Activity is displayed as a dialog that allows the previous Activity to be seen behind it. Such a process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
3. A service process is one holding a Service that has been started with the startService() method. Though these processes are not directly visible to the user,they are generally doing things that the user cares about (such as background mp3 playback or background network data upload or download), so the system will always keep such processes running unless there is not enough memory to retain all foreground and visible process.
4. A background process is one holding an Activity that is not currently visible to the user (its onStop() method has been called). These processes have no direct impact on the user experience. Provided they implement their Activity life-cycle correctly (see Activity for more details), the system can kill such processes atany time to reclaim memory for one of the three previous processes types.
Usually there are many of these processes running, so they are kept in an LRU list to ensure the process that was most recently seen by the user is the last to be killed when running low on memory.
5. An empty process is one that doesn't hold any active application components. The only reason to keep such a process around is as a cache to improve startup time the next time a component of its application needs to run. As such, the system will often kill these processes in order to balance overall system resources between these empty cached processes and the underlying kernel caches.