The Ingredients of an Android Application

Document technical information

Format pptx
Size 2.5 MB
First found May 22, 2018

Document content analysis

Language
English
Type
not defined
Concepts
no text concepts found

Persons

Organizations

Places

Transcript

The Ingredients of Android
Applications
Major high-level concepts involved in programming for the
Android platform
In a classical programming environment, the OS would load the
program code into a process and then start executing it.
A simple application in a process
To use a rich GUI system like Swing, start a UI system and then
write callbacks to code that process events.
A Java application, running in a Java virtual machine, in a process
Activities, Intents, and Tasks
• Android introduces a richer and more complex approach
by supporting multiple application entry points.
• Starts them in different places, depending on where the
user is coming from and what she wants to do next.
• Instead of relying on the user to directly start each
application, the components themselves invoke one
another to perform interactions on behalf of the user.
Android classes
Activities, Intents, and Tasks
• An Android activity is both a unit of user interaction
filling the screen of an Android mobile device—and a
unit of execution.
• An Android program starts by subclassing the Activity
class.
• Activities provide the reusable, interchangeable parts
of the flow of UI components across Android
applications.
Activities, Intents, and Tasks
• How, does one activity invoke another, and pass
information about what the user wants to do?
• The unit of communication is the Intent class.
• An Intent represents a function that one activity
requires another activity to perform
Activities, Intents, and Tasks
• Intents form the basis of a system of loose coupling
that allows activities to launch one another.
• When an application dispatches an intent, it’s possible
that several different activities might be registered to
provide the desired operation.
Activities, Intents, and Tasks
• Android programs look like we page applications
• A well-designed activity is resposible for managing a
single UI page and each has its own unique name.
• Android applications find their interactions invoked by
an intent.
• Activities provide UIs and the services.
• When the system starts this activity it calls the constructor for
TestActivity, a subclass of Activity, and then calls its onCreate
method.
• This causes the view hierarchy described in the main.xml file to
load and display.
• The onCreate method starts the life cycle of the Activity,
The Activity class
• one of the most important classes in the Android system,
promoting apps' modularity and allowing functionality to be
shared.
• interacts with the Android runtime to implement key aspects of
the application life cycle.
• Each activity is separate from other activities.
• one activity does not directly call methods in the code that
implements another activity.
The Activity class
• Other elements in the Android framework—such the Intent —are
used to manage communication instead.
• Instead of a user interface flow control based on method calls,
applications describe an Intent that they want to execute and ask
the system to find one that matches.
Other Android Components:
services, content providers, and broadcast receivers
The Service class supports background functions.
The ContentProvider class provides access to a data
store for multiple applications,
The Broadcast Receiver allows multiple parties to listen
for intents broadcast by applications.
• Content providers and intents are secondary APIs to
use in order to take advantage of Android's
strongest features and integrate seamlessly with
the Android platform.
Service Class
• Background tasks that may be active but not visible
on the screen.
• A music-playing application (service) continue to
play music while a user might be viewing web
pages.
• allow applications to share functions through longterm connections
Content Provider class
• A special Uniform Resource Identifier (URI) starting with
the content://, which is recognized across the local
device, gives you access to the content provider
data
• To use a ContentProvider, you specify a URI and
how to act on referenced data
• create (insert), read (query), update, and delete are
basic data handling activities
Content Provider class
• by providing a ContentProvider, application can
share data with other applications and manage the
data model of an application.
• ContentResolver class, enables other components
in an Android system to find content providers.
• Unique among the Inter Process Communication
(IPC) systems found on other platforms, such as
CORBA, RMI, and DCOM, which focus on remote
procedure calls.
• shares entire SQL databases across processes
Content Provider class
• Provides the central content provider API, which
you can subtype to manipulate specific types of
data.
• Activities access specific content provider instances
using the ContentResolver class and associated
URLs as follows:
Content Provider class
• When a developer calls the query method on a
content provider, the call returns a Cursor object that
implements the android.database.Cursor interface.
BroadcastReceiver
• implements another variant of Android’s high-level
interprocess communication (IPC) mechanism using
Intent objects.
• receives the action of Intent objects, similarly to an
Activity, but does not have its own user interface.
• might receive an alarm that causes an app to
become active at a particular time
Component Life Cycles
onCreate method starts an application.
• efficient use of each application’s memory, or heap
space,
• enable the state of entire processes to be preserved
and restored
• so that the Android system can run more applications
than can fit in memory.
Activity Life Cycle
• most complex component life cycle
The key elements of handling life cycle state transitions are:
• selecting which life cycle callbacks you need to
implement,
• and knowing when they are called.
Activity Life Cycle
Activity life cycle states
The runtime calls onSaveInstanceState method when it
determines that it might have to destroy the activity,
but wants to be able to restore it later.
The onRestoreInstanceState method is called when an
activity that was destroyed is being recreated.
Static Application Resources and Context
The app name, the intents it registers, the permissions it
needs and so on are stored in a file called the manifest.
These data are called resources.
Together, all this information forms the context of the
application, and Android provides access to it through
the Context class.
Application Manifests
Android requires applications to explicitly describe their contents
in an XML file called AndroidManifest.xml
includes
•content providers,
•services,
•required permissions,
•and other elements
The file organizes an Android application into a well-defined
structure that is shared by all applications and enables the Android
operating system to load and execute them in a managed
environment.
AndroidManifest.xml
we declare an intent
filter that tells
Android when this
Activity should be
run.
Android applications place images, icons, and user interface
layout files into a directory named res.
Applications access resources in these directories using the
method Context.getResources() and the R class.
directory gen, which contains a class always named R, which
resides in the Java application package named in the Android
manifest.
The Android Application Runtime Environment
Android executes multiple instances of the Dalvik VM, one for
each task.
Android must divide memory into multiple small heaps.
garbage-collected when heap space is tight, and then restored
when needed.
The Android Application Runtime Environment
Android’s approach to multiprocessing requires that each instance
of the VM be space-efficient.
This is achieved partly through the component life cycle, which
enables objects to be garbage-collected and recreated, and partly
by the VM itself.
Android uses the Dalvik VM to run a bytecode system developed
specifically for Android, called dex.
Zygote: Forking a New Process
inefficient for each new process to load all the necessary base
classes each time.
Android puts each application in a separate process,
it can take advantage of the fork operation in the underlying Linux
OS to spawn new processes from a template process that is in the
optimal state for launching a new VM instance.
This template process is called Zygote.
It is an instance of the Dalvik VM.
Sandboxing: Processes and Users
Android makes an interesting use Linux’s inherent multi-user
support:
Android creates a new user for each application vendor.
This means each application runs with different user privileges
(except for those signed by the same vendor).
Files owned by one application are, by default, inaccessible by
other applications
×

Report this document