Android application structure

14,546 views 29 slides Aug 22, 2011
Slide 1
Slide 1 of 29
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29

About This Presentation

No description available for this slideshow.


Slide Content

Alexey Ustenko
programmer
@ustav

Application
Structure

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.
Here are the four types of application components:
 Activities
 Services
 Content providers
 Broadcast receivers

Activities
An activity represents a single screen with a user interface.
Services
A service is a component that runs in the background to perform long-running
operations or to perform work for remote processes. A service does not provide a
user interface.
Content providers
A content provider manages a shared set of application data. You can store the
data in the file system, an SQLite database, on the web, or any other persistent
storage location your application can access. Through the content provider, other
applications can query or even modify the data (if the content provider allows it).
Broadcast receivers
A broadcast receiver is a component that responds to system-wide broadcast
announcements. Many broadcasts originate from the system—for example, a
broadcast announcing that the screen has turned off, the battery is low, or a picture
was captured. Applications can also initiate broadcasts.

Activating Components
A unique aspect of the Android system design is that any
application can start another application’s component.
Three of the four component types—activities, services, and
broadcast receivers—are activated by an asynchronous message
called an intent.

The Manifest File
Your application must declare all its components in this file, which must be at
the root of the application project directory.
The manifest does a number of things in addition to declaring the
application's components, such as:

Identify any user permissions the application requires
 Declare the minimum API Level required by the application
 Declare hardware and software features used or required by the application
 API libraries the application needs to be linked against
And more

Declaring components
The primary task of the manifest is to inform the system about the application's
components. For example, a manifest file can declare an activity as follows:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.test.appstructure"
android:versionCode ="1"
android:versionName ="1.0">
<uses-sdk android:minSdkVersion ="4" />
<application android:icon="@drawable/icon" android:label="@string/app_name">
<activity android:name=".MainActivity"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Activities, services, and content providers that you include in your source but
do not declare in the manifest are not visible to the system and, consequently,
can never run.

Application Resources
For every resource that you include in your Android project,
the SDK build tools define a unique integer ID, which you
can use to reference the resource from your application code
or from other resources defined in XML.
One of the most important aspects of providing resources
separate from your source code is the ability for you to
provide alternative resources for different device
configurations.

Android Projects
An application project is the main type of project and the
contents are eventually built into an .apk file that you install
on a device.
Test Projects
These projects contain code to test your application projects
and are built into applications that run on a device.
Library Projects
These projects contain shareable Android source code and
resources that you can reference in Android projects. Library
projects cannot be installed onto a device, however, they are
pulled into the .apk file at build time.

Contains your stub Activity file, which is stored
at src/your/package/ActivityName.java.
All other source code files (such as .java
or .aidl files) go here as well.

Contains the Java files generated by
ADT, such as your R.java file and
interfaces created from AIDL files.

You can use it to store raw asset files.
Files that you save here are compiled
into an .apk file as-is, and the original
filename is preserved.

Contains private libraries.

Contains application
resources, such as
drawable files, layout files,
and string values

For XML files that are compiled
into animation objects

For XML files that describe colors

For bitmap files (PNG, JPEG, or GIF),
9-Patch image files, and XML files that
describe Drawable shapes or a
Drawable objects that contain multiple
states (normal, pressed, or focused)

XML files that are compiled into
screen layouts (or part of a screen)

For XML files that define application menus

For arbitrary raw asset files. Saving asset
files here instead of in the assets/ directory
only differs in the way that you access them.
These files are processed by aapt and must
be referenced from the application using a
resource identifier in the R class. For
example, this is a good place for media,
such as MP3 or Ogg files.

For XML files that are compiled into many
kinds of resource. Unlike other resources in
the res/ directory, resources written to XML
files in this folder are not referenced by the
file name. Instead, the XML element type
controls how the resources is defined within
them are placed into the R class.

For miscellaneous XML files that configure
application components.
For example, an XML file that defines a
PreferenceScreen, AppWidgetProviderInfo,
or Searchability Metadata.

The control file that describes the nature of the
application and each of its components. For
instance, it describes: certain qualities about the
activities, services, intent receivers, and content
providers; what permissions are requested; what
external libraries are needed; what device features
are required, what API Levels are supported or
required; and others.

This file contains project settings, such as the
build target. This files is integral to the project,
as such, it should be maintained in a Source
Revision Control system. Do not edit the file
manually.

This file defines how ProGuard optimizes and
obfuscates your code

Security
The Android operating system is a multi-user Linux system in
which each application is a different user.
Each process has its own virtual machine (VM), so an
application's code runs in isolation from other applications.
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.

/Android/data/<package_name>/your_files
Storage
Where to place your files on SD Card

Build process
Apk file contents

http://developer.android.com