07-06-2013, 03:39 PM
FULL PAPER ON ANDROID
[attachment=54956]
ABSTRACT
The unveiling of the Android platform on was announced with the founding of the Open Handset Alliance, a consortium of 48 hardware, software, and telecom companies devoted to advancing open standards for mobile devices. Google has made most of the Android platform available under the Apache free-software and open source license.
Android is a freely downloadable open source software stack for mobile devices that includes an operating system, middleware and key applications based on Linux and Java.
Google developed Android collaboratively as part of the Open Handset Alliance, a group of more than 30 mobile and technology companies working to open up the mobile handset environment. Android's development kit supports many of the standard packages used by Jetty, and so, due to that fact and Jetty's modularity and lightweight footprint, it was possible to port Jetty to it so that it will be able to run on the Android platform.
This paper on Android deals with the history of the Android, the early prototypes, basic building blocks of an android application and the features of the android.
Introduction
Android is a software platform and operating system for mobile devices, based on the Linux kernel, and developed by Google and later the Open Handset Alliance. It allows developers to write managed code in the Java language, controlling the device via Google-developed Java libraries. Applications written in C and other languages can be compiled to ARM native code and run, but this development path isn't officially supported by Google.
Android is available as open source. Google threw open the entire source code (including network and telephony stacks) that were not available previously, under an Apache license. Certain parts that relate to a specific hardware can't be made open and are not considered part of the Android platform. With Apache License, vendors are free to add proprietary extensions without submitting those back to the open source community. While Google's contributions to this platform are expected to remain open-sourced, the branches could explode using varieties of licenses.
Building blocks to an Android application
There are four building blocks to an Android application:
• Activity
• Broadcast Intent Receiver
• Service
• Content Provider
Activity
Activities are the most common of the four Android building blocks. An activity is usually a single screen in your application. Each activity is implemented as a single class that extends the Activity base class. Your class will display a user interface composed of Views and respond to events. Most applications consist of multiple screens. For example, a text messaging application might have one screen that shows a list of contacts to send messages to, a second screen to write the message to the chosen contact, and other screens to review old messages or change settings. Each of these screens would be implemented as an activity. Moving to another screen is accomplished by a starting a new activity. In some cases and activity may return a value to the previous activity -- for example an activity that lets the user pick a photo would return the chosen photo to the caller.
Intent and Intent Filters
Android uses a special class called Intent to move from screen to screen. Intent describes what an application wants done. The two most important parts of the intent data structure are the action and the data to act upon. Typical values for action are MAIN (the front door of the application), VIEW, PICK, EDIT, etc. The data is expressed as a URI. For example, to view contact information for a person, you would create intent with the VIEW action and the data set to a URI representing that person.
There is a related class called an Intent Filter. While an intent is effectively a request to do something, an intent filter is a description of what intents an activity (or Broadcast Receiver, see below) is capable of handling. An activity that is able to display contact information for a person would publish an Intent Filter that said that it knows how to handle the action VIEW when applied to data representing a person. Activities publish their Intent Filters in the AndroidManifest.xml file.
. The new activity is informed of the intent, which causes it to be launched. The process of resolving intents happens at run time when start Activity is called, which offers two key benefits:
• Activities can reuse functionality from other components simply by making a request in the form of an Intent
• Activities can be replaced at any time by a new Activity with an equivalent Intent Filter
BROADCAST INET RECEIVER
You can use a Broadcast Receiver when you want code in your application to execute in reaction to an external event, for example, when the phone rings, or when the data network is available, or when it's midnight. Broadcast Receivers do not display a UI, although they may use the Notification Manager to alert the user if something interesting has happened. Broadcast Receivers are registered in AndroidManifest.xml, but you can also register them from code using Context.registerReceiver (). Your application does not have to be running for its BroadcastReceivers to be called; the system will start your application, if necessary, when a BroadcastReceiver is triggered. Applications can also send their own intent broadcasts to others with Context.sendBroadcast ().
SERVICE
A Service is code that is long-lived and runs without a UI. A good example of this is a media player playing songs from a play list. In a media player application, there would probably be one or more activities that allow the user to choose songs and start playing them. However, the music playback itself should not be handled by an activity because the user will expect the music to keep playing even after navigating to a new screen. In this case, the media player activity could start a service using Context.startService () to run in the background to keep the music going. The system will then keep the music playback service running until it has finished. Note that you can connect to a service (and start it if it's not already running) with the Context.bindService () method. When connected to a service, you can communicate with it through an interface exposed by the service. For the music service, this might allow you to pause, rewind, etc.
CONTENT PROVIDER
Applications can store their data in files, an SQLite database, or any other mechanism that makes sense. A content provider, however, is useful if you want your application's data to be shared with other applications. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider.
Not every application needs to have all four, but your application will be written with some combination of these.
All the components needed for android application should listed in an xml file called AndroidManifest.xml. This is an XML file where you declare the components of your application and what their capabilities and requirements are.
Storing, Retrieving and Exposing Data
A typical desktop operating system provides a common file system that any application can use to store and read files that can be read by other applications. Android uses a different system on Android, all application data are private to that application. However, Android also provides a standard way for an application to expose its private data to other applications. This section describes the many ways that an application can store and retrieve data, expose its data to other applications, and also how you can request data from other applications that expose their data.
[attachment=54956]
ABSTRACT
The unveiling of the Android platform on was announced with the founding of the Open Handset Alliance, a consortium of 48 hardware, software, and telecom companies devoted to advancing open standards for mobile devices. Google has made most of the Android platform available under the Apache free-software and open source license.
Android is a freely downloadable open source software stack for mobile devices that includes an operating system, middleware and key applications based on Linux and Java.
Google developed Android collaboratively as part of the Open Handset Alliance, a group of more than 30 mobile and technology companies working to open up the mobile handset environment. Android's development kit supports many of the standard packages used by Jetty, and so, due to that fact and Jetty's modularity and lightweight footprint, it was possible to port Jetty to it so that it will be able to run on the Android platform.
This paper on Android deals with the history of the Android, the early prototypes, basic building blocks of an android application and the features of the android.
Introduction
Android is a software platform and operating system for mobile devices, based on the Linux kernel, and developed by Google and later the Open Handset Alliance. It allows developers to write managed code in the Java language, controlling the device via Google-developed Java libraries. Applications written in C and other languages can be compiled to ARM native code and run, but this development path isn't officially supported by Google.
Android is available as open source. Google threw open the entire source code (including network and telephony stacks) that were not available previously, under an Apache license. Certain parts that relate to a specific hardware can't be made open and are not considered part of the Android platform. With Apache License, vendors are free to add proprietary extensions without submitting those back to the open source community. While Google's contributions to this platform are expected to remain open-sourced, the branches could explode using varieties of licenses.
Building blocks to an Android application
There are four building blocks to an Android application:
• Activity
• Broadcast Intent Receiver
• Service
• Content Provider
Activity
Activities are the most common of the four Android building blocks. An activity is usually a single screen in your application. Each activity is implemented as a single class that extends the Activity base class. Your class will display a user interface composed of Views and respond to events. Most applications consist of multiple screens. For example, a text messaging application might have one screen that shows a list of contacts to send messages to, a second screen to write the message to the chosen contact, and other screens to review old messages or change settings. Each of these screens would be implemented as an activity. Moving to another screen is accomplished by a starting a new activity. In some cases and activity may return a value to the previous activity -- for example an activity that lets the user pick a photo would return the chosen photo to the caller.
Intent and Intent Filters
Android uses a special class called Intent to move from screen to screen. Intent describes what an application wants done. The two most important parts of the intent data structure are the action and the data to act upon. Typical values for action are MAIN (the front door of the application), VIEW, PICK, EDIT, etc. The data is expressed as a URI. For example, to view contact information for a person, you would create intent with the VIEW action and the data set to a URI representing that person.
There is a related class called an Intent Filter. While an intent is effectively a request to do something, an intent filter is a description of what intents an activity (or Broadcast Receiver, see below) is capable of handling. An activity that is able to display contact information for a person would publish an Intent Filter that said that it knows how to handle the action VIEW when applied to data representing a person. Activities publish their Intent Filters in the AndroidManifest.xml file.
. The new activity is informed of the intent, which causes it to be launched. The process of resolving intents happens at run time when start Activity is called, which offers two key benefits:
• Activities can reuse functionality from other components simply by making a request in the form of an Intent
• Activities can be replaced at any time by a new Activity with an equivalent Intent Filter
BROADCAST INET RECEIVER
You can use a Broadcast Receiver when you want code in your application to execute in reaction to an external event, for example, when the phone rings, or when the data network is available, or when it's midnight. Broadcast Receivers do not display a UI, although they may use the Notification Manager to alert the user if something interesting has happened. Broadcast Receivers are registered in AndroidManifest.xml, but you can also register them from code using Context.registerReceiver (). Your application does not have to be running for its BroadcastReceivers to be called; the system will start your application, if necessary, when a BroadcastReceiver is triggered. Applications can also send their own intent broadcasts to others with Context.sendBroadcast ().
SERVICE
A Service is code that is long-lived and runs without a UI. A good example of this is a media player playing songs from a play list. In a media player application, there would probably be one or more activities that allow the user to choose songs and start playing them. However, the music playback itself should not be handled by an activity because the user will expect the music to keep playing even after navigating to a new screen. In this case, the media player activity could start a service using Context.startService () to run in the background to keep the music going. The system will then keep the music playback service running until it has finished. Note that you can connect to a service (and start it if it's not already running) with the Context.bindService () method. When connected to a service, you can communicate with it through an interface exposed by the service. For the music service, this might allow you to pause, rewind, etc.
CONTENT PROVIDER
Applications can store their data in files, an SQLite database, or any other mechanism that makes sense. A content provider, however, is useful if you want your application's data to be shared with other applications. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider.
Not every application needs to have all four, but your application will be written with some combination of these.
All the components needed for android application should listed in an xml file called AndroidManifest.xml. This is an XML file where you declare the components of your application and what their capabilities and requirements are.
Storing, Retrieving and Exposing Data
A typical desktop operating system provides a common file system that any application can use to store and read files that can be read by other applications. Android uses a different system on Android, all application data are private to that application. However, Android also provides a standard way for an application to expose its private data to other applications. This section describes the many ways that an application can store and retrieve data, expose its data to other applications, and also how you can request data from other applications that expose their data.