What is Android:-
Android is a software stack for mobile devices that includes an operatingsystem, middleware
and key applications.
and key applications.
The Android SDK provides the tools and APIs necessary to begin developing applicat ions on the
Android platform using the Java programming language
Features of Android:-
Application framework:- enabling reuse and replacement of components
Dalvik virtual machine:- optimized for mobile devices
Integrated browser:- based on the open source WebKit engine
Optimized graphics:- powered by a custom 2D graphics library; 3D graphics based on the OpenGL
ES 1.0 specification (hardware acceleration optional)
SQLite:- for structured data storage
Media support:- for common audio, video, and st ill image formats (MPEG4, H.264, MP3, AAC,
AMR, JPG, PNG, GIF)
GSM :-Telephony (hardware dependent)
Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
Camera, GPS, compass, and accelerometer (hardware dependent)
Rich development environment:-including a device emulator, tools for debugging, memory and
performance profiling, and a plugin for the Eclipse IDE
Architecture Of Android:-
Application Components
Activity:-
An activity presents a visual user interface for one focused endeavor the user can undertake.
Though they work together to form a cohesive user interface, each act ivity is independent of
the others.
Each one is implemented as a subclass of the Activity base class.
An application might consist of just one activity or it may contain several.
Typically, one of the act ivit ies is marked as the first one that should be presented to the user
when the applicat ion is launched. Moving f rom one act ivity to another is accomplished by
having the current activity start the next one.
Each activity is given a default window to draw in.
Typically, the window fills the screen, but it might be smaller than the screen and float on top
of other windows.
An act ivity can also make use of addit ional windows for example, a pop-up dialog or a
window that presents users with vital information.
The visual content of the window is provided by a hierarchy of views obj ects derived from
the base View class.
Each view cont rols a part icular rectangular space within the window. Parent views contain and
organize the layout of their children. Leaf views (those at the bot tom of the hierarchy) draw in
the rectangles they control and respond to user actions directed at that space.
Thus, views are where the activity's interaction with the user takes place.
For example, a view might display a small image and init iate an act ion when the user taps that
image. Example of Views are but tons, text fields, scroll bars, menu items, check boxes, and
more.
A view hierarchy is placed within an act ivity's window by
the Activity.setContentView() method. The content view is the View obj ect at the root of the
hierarch
Though they work together to form a cohesive user interface, each act ivity is independent of
the others.
Each one is implemented as a subclass of the Activity base class.
An application might consist of just one activity or it may contain several.
Typically, one of the act ivit ies is marked as the first one that should be presented to the user
when the applicat ion is launched. Moving f rom one act ivity to another is accomplished by
having the current activity start the next one.
Each activity is given a default window to draw in.
Typically, the window fills the screen, but it might be smaller than the screen and float on top
of other windows.
An act ivity can also make use of addit ional windows for example, a pop-up dialog or a
window that presents users with vital information.
The visual content of the window is provided by a hierarchy of views obj ects derived from
the base View class.
Each view cont rols a part icular rectangular space within the window. Parent views contain and
organize the layout of their children. Leaf views (those at the bot tom of the hierarchy) draw in
the rectangles they control and respond to user actions directed at that space.
Thus, views are where the activity's interaction with the user takes place.
For example, a view might display a small image and init iate an act ion when the user taps that
image. Example of Views are but tons, text fields, scroll bars, menu items, check boxes, and
more.
A view hierarchy is placed within an act ivity's window by
the Activity.setContentView() method. The content view is the View obj ect at the root of the
hierarch
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
Each service extends the Service base class.
A prime example is a media player playing songs from a play list . The player applicat ion would
probably have one or more act ivit ies that allow the user to choose songs and start playing
them. However, the music playback itself would not be handled by an act ivity because users
will expect the music to keep playing even after they leave the player and begin something
different . To keep the music going, the media player act ivity could start a service to run in the
background. The system would then keep the music playback service running even after the
activity that started it leaves the screen.
It's possible to connect to (bind to) an ongoing service (and start the service if it 's not already
running). While connected, you can communicate with the service through an interface that the
service exposes.
Like act ivit ies and the other components, services run in the main thread of the applicat ion
process. So that they won't block other components or the user interface, they often spawn
another thread for time-consuming tasks (like music playback).
indefinite period of time.
For example, a service might play background music as the user attends to other matters
Each service extends the Service base class.
A prime example is a media player playing songs from a play list . The player applicat ion would
probably have one or more act ivit ies that allow the user to choose songs and start playing
them. However, the music playback itself would not be handled by an act ivity because users
will expect the music to keep playing even after they leave the player and begin something
different . To keep the music going, the media player act ivity could start a service to run in the
background. The system would then keep the music playback service running even after the
activity that started it leaves the screen.
It's possible to connect to (bind to) an ongoing service (and start the service if it 's not already
running). While connected, you can communicate with the service through an interface that the
service exposes.
Like act ivit ies and the other components, services run in the main thread of the applicat ion
process. So that they won't block other components or the user interface, they often spawn
another thread for time-consuming tasks (like music playback).
BroadCastRecivers:-
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 bat tery is low, that a picture has been taken, or that the user changed a
language preference.
Applicat ions can also init iate broadcasts for example, to let other applicat ions know that
some data has been downloaded to the device and is available for them to use.
An applicat ion 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 act ivity in
response to the informat ion they receive, or they may use the NotificationManager to alert the
user.
announcements.
Many broadcasts originate in system code for example, announcements that the timezone has
changed, that the bat tery is low, that a picture has been taken, or that the user changed a
language preference.
Applicat ions can also init iate broadcasts for example, to let other applicat ions know that
some data has been downloaded to the device and is available for them to use.
An applicat ion 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 act ivity in
response to the informat ion they receive, or they may use the NotificationManager to alert the
user.
Content Providers:-
A content provider makes a specific set of the applicat ion's data available to other
applicat ions. The data can be stored in the file system, in an SQLite database, or in any other
manner that makes sense.
The content provider extends the ContentProvider base class to implement a standard set of
methods that enable other applications to retrieve and store data of the type it controls.
However, applicat ions do not call these methods direct ly. Rather they use
a ContentResolver object and call its methods instead. A ContentResolver can talk to any
content provider; it cooperates with the provider to manage any interprocess communicat ion
that's involved
applicat ions. The data can be stored in the file system, in an SQLite database, or in any other
manner that makes sense.
The content provider extends the ContentProvider base class to implement a standard set of
methods that enable other applications to retrieve and store data of the type it controls.
However, applicat ions do not call these methods direct ly. Rather they use
a ContentResolver object and call its methods instead. A ContentResolver can talk to any
content provider; it cooperates with the provider to manage any interprocess communicat ion
that's involved
This is "small" Introduction About Android" each one will explain neatly in next tutorial
No comments:
Post a Comment