Android user interface (UI and GUI) components
Activity
An Activity represents the presentation layer
of an Android application. A simplified description is that an Activity
represents a screen in your Android application. Compared to desktop
development, Activities are equivalent to Forms.
- Activity is Your application’s presentation
layer.
- An Android application can have several
Activities.
- An activity provides a user interface for a
single screen in your application .
- Activities can move into the background and
then be resumed with their state restored .
- You’ll learn more about Activities later in
coming articles.
View’s and View Groups.
An activity contains views and View Groups. A
view is a widget that has an appearance on screen.
Examples of views (GUI graphical user
interface components) are buttons, labels, and text boxes. A view derives from
the base class android.view.View . Views have attributes which can be used to
configure their appearance and behavior.
A View Group is a special view that can
contain other views (called children.) The view group is the base class for
layouts and views containers. This class also defines the
ViewGroup.LayoutParams class which serves as the base class for layout
parameters .
- A ViewGroup is responsible for
arranging other Views.
- View Groups can be nested to create
complex layouts. You should not nested View Groups too deeply as this has a
negative impact on the performance.
Intents
A powerful application message passing
framework. Intents are used extensively throughout Android. You can use Intents
to start and stop Activities and Services, to broadcast messages system-wide or
to an explicit Activity, Service, or Broadcast Receiver, or to request an
action be performed on a particular piece of data.
- Intents are asynchronous messages which
allow the application to request functionality from other components of the
Android system.
- Intent example is the application can call a
component directly (explicit Intent) or ask the Android system to evaluate
registered components based on the Intent data) implicit Intents ).
- For example the application could implement
sharing of data via Intent and all components which allow sharing of data would
be available for the user to select. Applications register themselves to an
Intent via an Intent Filter.
- Intents allow to combine loosely coupled
components to perform certain tasks.
Services
The invisible workers of your application.
Service components run without a UI, updating your data sources and Activities,
triggering Notifications, and broadcasting Intents.
They’re used to perform long running tasks, or
those that require no user interaction (such as network lookups or tasks that
need to continue even when your application’s Activities aren’t active or
visible.)
- Services perform background tasks without
providing a user interface.
- They can notify the user via the
notification framework in Android.
Content Provider
Shareable persistent data storage. Content
Providers manage and persist application data and typically interact with SQL
databases. They’re also the preferred means to share data across application
boundaries. You can configure your application’s Content Providers to allow
access from other applications, and you can access the Content Providers
exposed by others.
- Android devices include several native
Content Providers that expose useful databases such as the media store and
contacts.
- Your application can share data with other
applications.
- Android contains an SQLite database which is
frequently used in conjunction with a Content Provider.
- The SQLite database would store the data,
which would be accessed via the Content Provider.
Broadcast Receiver
Intent listeners. Broadcast Receivers enable
your application to listen for Intents that match the criteria you specify.
Broadcast Receivers start your application to react to any received Intent,
making them perfect for creating event-driven applications.
- Broadcast Receiver registered to receive
system messages and Intents.
- Broadcast Receiver will get notified by the
Android system, if the specified situation happens.
- Broadcast Receiver could get called once the
Android system completed some event .
HomeScreenWidgets
Visual application components that are
typically added to the device home screen.
A special variation of a Broadcast Receiver,
widgets enable you to create dynamic, interactive application components for
users to embed on their home screens.
- Widgets are interactive components
which are primarily used on the Android home screen.
- They typically display some kind of data and
allow the user to perform actions via them. --- - For example a Widget could
display a short summary of new emails and if the user selects an email, it
could start the email application with the selected email.
Notifications
Notifications enable you to alert users
to application events without stealing focus or interrupting their current
Activity.
They’re the preferred technique for
getting a user’s attention when your application is not visible or active,
particularly from within a Service or Broadcast Receiver. For example, when a
device receives a text message or an email, the messaging and Gmail
applications use Notifications to alert you by flashing lights, playing sounds,
displaying icons, and scrolling a text summary. You can trigger
Other Android user
interface (UI and GUI) components
Android provides many more components but the
list above describes the most important ones. Other Android components are Live
Folders and Live Wallpapers. Live Folders display data on the home screen
without launching the corresponding application while Live Wallpapers allow to
create animated backgrounds.
Android custom components
Android offers a sophisticated and powerful
componentized model for building your UI, based on the fundamental layout
classes: View and View Group.
As previously noted, the Linux kernel provides a
multitasking execution environment allowing multiple processes to execute
concurrently. It would be easy to assume, therefore, that each Android
application simply runs as a process directly on the Linux kernel. In actual
fact, each application running on an Android device does so within its own
instance of the Dalvik virtual machine.
Running applications in virtual machines provides a number of
advantages. Firstly, applications are essentially sandboxed, in that they
cannot detrimentally interfere (intentionally or otherwise) with the operating
system, other applications or directly access the device hardware. Secondly,
this enforced level of abstraction makes applications platform neutral in that
they are never tied to any specific hardware.
The Dalvik virtual machine was developed by Google and relies on
the underlying Linux kernel for low level functionality. It is more efficient
than the standard Java VM in terms of memory usage, and specifically designed
to allow multiple instances to run efficiently within the resource constraints
of a mobile device.
In order to execute within a Dalvik VM, application code must be
transformed from standard Java class files to the Dalvik executable (.dex)
format which has a 50% smaller memory footprint than standard Java bytecode.
Standard Java class files can usually (though not always) be converted to Dex
format using the dx tool included with the Android SDK.
The Android Core Libraries (also referred to as the Dalvik Libraries)
fall into three main categories, each of which merits an individual
description:
Dalvik VM Specific Libraries
This is a set of libraries used predominantly for interacting
directly with an instance of the Dalvik VM and are unlikely to be used by most
Android application developers.
Java Interoperability Libraries
Android applications are predominantly developed using the Java
programming language. The Standard Java development environment includes a vast
array classes that are contained in the core Java runtime libraries. These
libraries provide support for tasks such as string handling, networking and
file manipulation (to name but a few) and are both familiar and widely used by
Java developers regardless of platform.
The Java Interoperability Libraries are an open source
implementation (based on the Apache Harmony project) of a subset of the
standard Java core libraries that have been adapted and transformed for use by
applications running within a Dalvik VM.
Android Libraries
This category encompasses those Java-based libraries that are
specific to Android development. Examples of libraries in this category include
the application framework libraries in addition to those that facilitate user
interface building, graphics drawing and database access.
A summary of some key core Android libraries available to the
Kindle Fire developer is as follows:
§ android.app – Provides access to the application model and is the
cornerstone of all Android applications.
§ android.content – Facilitates the content access, publishing and
messaging between applications and application components.
§ android.database – Used to access data published by content providers
and includes SQLite database management classes.
§ android.graphics – A low level 2D graphics drawing API including
colors, points, filters, rectangles and canvases.
§ android.hardware – Presents an API providing access to hardware such as
the accelerometer and light sensor.
§ android.opengl – A Java interface to the OpenGL ES 3D graphics
rendering API.
§ android.os – Provides applications with access to standard
operating system services including messages, system services and inter-process
communication.
§ android.media – Provides classes to enable playback of audio and
video.
§ android.net – A set of APIs providing access to the network stack.
Includes android.net.wifi which provides access to the device’s wireless stack.
§ android.provider – A set of convenience classes that provide access to
standard Android content provider databases such as those maintained by the calendar
and contact applications.
§ android.text – Used to render and manipulate text on a device
display.
§ android.util – A set of utility classes for performing tasks such
as string and number conversion, XML handling and date and time manipulation.
§ android.view – The fundamental building blocks of application user
interfaces.
§ android.widget - A rich collection of pre-built user interface components such as buttons, labels, list views, layout managers,
radio buttons etc.
§ android.webkit – A set of classes intended to allow for web browsing
capabilities to be built into applications.
Having covered the Java-based core libraries in the Android
runtime, it is now time to turn our attention to the C/C++ based libraries
contained in this layer of the Android software stack.
C/C++ Libraries
The Android runtime core libraries outlined in the preceding
section are Java based and provide the primary APIs for developers writing
Android applications. It is important to note, however, that the core libraries
do not actually perform much of the actual work and are, in fact, essentially
Java “wrappers” around a set of C/C++ based libraries. When making calls, for
example, to the android.opengl library to draw 3D graphics on the device
display, the library actually ultimately makes calls to the OpenGL ES C++
library which, in turn, works with the underlying Linux kernel to perform the
drawing tasks. C/C++ libraries are included to fulfill a wide and diverse range
of functions including 2D and 3D graphics drawing, Secure Sockets Layer (SSL)
communication, SQLite database management, audio and video playback, bitmap and
vector font rendering, display subsystem and graphic layer management and an
implementation of the standard C system library (libc).
In practice the typical Android application developer
will access these libraries solely through the Java based Android core library
APIs. In the event that direct access to these libraries is needed, this can be
achieved using the Android Native Development Kit (NDK), the purpose of
which is to call native methods of non-Java programming languages (such as C
and C++) from within Java code using the Java Native Interface (JNI).
Android Emulator:
The Android SDK includes a virtual mobile device emulator that
runs on your computer. The emulator lets you prototype, develop and test Android
applications without using a physical device.
The Android emulator mimics all of the hardware and software
features of a typical mobile device, except that it cannot place actual phone
calls. It provides a variety of navigation and control keys, which you can
"press" using your mouse or keyboard to generate events for your
application. It also provides a screen in which your application is displayed,
together with any other active Android applications.
To let you model and test your application more easily, the
emulator utilizes Android Virtual Device (AVD) configurations. AVDs let you
define certain hardware aspects of your emulated phone and allow you to create
many configurations to test many Android platforms and hardware permutations.
Once your application is running on the emulator, it can use the services of
the Android platform to invoke other applications, access the network, play
audio and video, store and retrieve data, notify the user, and render graphical
transitions and themes.
The emulator also includes a variety of debug capabilities, such
as a console from which you can log kernel output, simulate application
interrupts (such as arriving SMS messages or phone calls), and simulate latency
effects and dropouts on the data network.
No comments:
Post a Comment