In the first blog on the Android, I have provided a brief introduction of Android. Now starting discussion on the application fundamentals.
As I mentioned in the introduction blog, Android applications are developed using JAVA language.
How an Android application exists within the system?
- The Android SDK tools compile the code—along with any data and resource files—into an Android package, an archive file with an
.apk suffix. It is equivalent to .jar file. - All the code in a single
.apk file is considered to be one application and is the file that Android-powered devices use to install the application. - The Android operating system is a multi-user Linux system in which each application is a different user.
- By default, the system assigns each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
- Each process has its own virtual machine (VM), so an application's code runs in isolation from other applications.
- By default, every application runs in its own Linux process. Android starts the process when any of the application's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover memory for other applications.
In this way, the Android system implements the principle of least privilege. That is, each application, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an application cannot access parts of the system for which it is not given permission.
Now a question arising that how one application can share data with another application?
There are ways for an application to share data with other applications and for an application to access system services:
- It's possible to arrange for two applications to share the same Linux user ID, in which case they are able to access each other's files. To conserve system resources, applications with the same user ID can also arrange to run in the same Linux process and share the same VM (the applications must also be signed with the same certificate).
- An application can request permission to access device data such as the user's contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All application permissions must be granted by the user at install time.
That is the introduction and behavior of an Android application. Now we will discuss on the Application components
Application Components
Application components are the essential building blocks of an Android application. Each component is a different point through which the system can enter your application. These components are:
- Activity
- Service
- Broadcast Receiver
- Content Providers
The means of communication between the above mentioned components is through
- Intents
- Intent Filters
The User Interface elements are by using what are called:
- Views
- Notifications
1. Activity
It is the basic building block of every visible android application. It provides the means to render a UI. Every screen in an application is an activity by itself. Though they work together to present an application sequence, each activity is an independent entity.
In brief:
• Launch an Activity by calling startActivity(Intent)
• Subactivities: startActivityForResult
– Takes an Intent as input, as well as an integer code.
– When subactivityexits, returns a result code.
– Original activity’s onActivityResultmethod is called.
– Note –this is asynchronous (non-blocking).
• Activities form a stack
– New activities appear at the top of the stack (i.e. on screen)
– Pressing back button goes to previous activity (usually)
Life cycle:
Three states:
– Active = In the foreground, running.
– Paused = Still visible, but obscured by another Activity which takes up part of the screen (or is transparent). It is same as active, but may be killed if running very low on memory.
– Stopped = Not visible on the screen.
Key Loops:
• Entire lifetime: onCreate() – onDestroy()
• Visible lifetime: onStart() – onStop()
• Foreground lifetime: onResume() – onPause() Once onPause is called, activity may be killed!
2. Service
A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it. Each service extends the Service base class.
Life Cycle: The diagram on the left shows the lifecycle when the service is created with startService() and the diagram on the right shows the lifecycle when the service is created with bindService().
startService():
runs until someone stops it or it stops itself
bindService():
is operated programmatically using an interface it defines and exports (can also start the service)
– Do some background work on request:
• Just call startService() –much like an Activity
• Service has onStartCommand() [or onStart()] to handle this.
• Service will keep running even after command is executed: best practice to stop with stopSelf(startId) at end.
– Ongoing communication
• Example: Music player
• Use bindService() to make a persistent connection.
• Client gets an object to make calls to service.
.
3. Broadcast Receiver
A broadcast receiver is a component that does nothing but receive and react to broadcast announcements. Many broadcasts originate in system code — for example, announcements that the timezone has changed, that the battery is low, that a picture has been taken, or that the user changed a language preference. Applications can also initiate broadcasts — for example, to let other applications know that some data has been downloaded to the device and is available for them to use.
An application can have any number of broadcast receivers to respond to any announcements it considers important. All receivers extend the BroadcastReceiver base class.
Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or they may use the NotificationManager to alert the user. Notifications can get the user's attention in various ways — flashing the backlight, vibrating the device, playing a sound, and so on. They typically place a persistent icon in the status bar, which users can open to get the message.
• Intents can be broadcast
–by the system (ACTION_BATTERY_LOW)
–by you (ACTION_MY_TASK_DONE)
• onReceive() is the only callback method
–runs with foreground priority
• must return within short period of time
–typically show a notification or start a service
• Receiver registration
–manifest (using intent-filters)
• can launch your app even if not currently running
• some system broadcasts can’t be registered for here!
–code (Context.registerReceiver())
• must manage registration manually (call unregisterReceiver())
• only works when component is active
4. Content Providers
A content provider makes a specific set of the application's data available to other applications. The data can be stored in the file system, in an SQLite database, or in any other manner that makes sense.
When you want to access data in a content provider, you use the ContentResolver object in your application's Context to communicate with the provider as a client. The ContentResolver object communicates with the provider object, an instance of a class that implements ContentProvider. The provider object receives data requests from clients, performs the requested action, and returns the results.
You don't need to develop your own provider if you don't intend to share your data with other applications. However, you do need your own provider to provide custom search suggestions in your own application. You also need your own provider if you want to copy and paste complex data or files from your application to other applications.
Android itself includes content providers that manage data such as audio, video, images, and personal contact information. You can see some of them listed in the reference documentation for the android.provider package. With some restrictions, these providers are accessible to any Android application.
Intents and Intent Filters
Three of the core components of an application: activities, services, and broadcast receivers — are activated through messages, called intents. For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things. For example, it might convey a request for an activity to present an image to the user or let the user edit some text. For broadcast receivers, the Intent object names the action being announced. For example, it might announce to interested parties that the camera button has been pressed.
To inform the system which implicit intents they can handle, activities, services, and broadcast receivers can have one or more intent filters. Each filter describes a capability of the component, a set of intents that the component is willing to receive. Intent filters are the means through which a component advertises its own capabilities to handle specific job/operations to the android platform.
In the next part we will discuss on the User Interface.
f6aab9c1-c91c-499b-ba2b-c753877d260e|0|.0
Categories:
Android
29. February 2012
Tags: