CHAPTER 1: INTRODUCTION

1
 Pocket Phonics
1. INTRODUCTION

One of the fastest growing industries now a day is mobile industry. There are many competitors
in this area who are doing research and development on new platforms & user experience. Here
are examples for those SDKS: Symbian, Windows mobile SDK, iPhone SDK and Android from
Google which is supported for Google phones. These phones are described as next Generation
mobiles [As described by Google]. It already hit the US market and going to be launched in all
other nations’ sooner.

The Android SDK includes a comprehensive set of development tools. These include a
debugger, libraries, a handset emulator (based on QEMU), documentation, sample code, and
tutorials. Currently supported development platforms include x86-architecture computers
running Linux (any modern desktop Linux distribution), Mac OS X 10.4.8 or later, Windows XP
or Vista. Requirements also include Java Development Kit, Apache Ant, and Python 2.2 or later.
The officially supported integrated development environment (IDE) is Eclipse (3.2 or later)
using the Android Development Tools (ADT) Plug in, though developers may use any text editor
to edit Java and XML files then use command line tools to create, build and debug Android
applications.

2
CHAPTER 2: SYSTEM ANALYSIS

3
Purpose:
The application’s consists of user friendly environment by providing menu, with entries for
alphabets, numbers and rhymes. When we click on particular alphabet it will show Phonics of
Alphabets with pictures and also for numbers, rhymes. Apart from this also play sound for
respective alphabet, number and rhymes.

Document conventions:
To prepare this SRS we had used the lettering style of Times New Roman and Font size for sub
headings is 14 with bold. The matter which is mentioned in this SRS is 12 with a lettering style
Times New Roman. Then headings are of lettering style Times New Roman with Font size 12.
Then the important points in our SRS are shown in italics.

Intended Audience and Reading Suggestions:

This SRS can be read by all developers. The rest of the part of the SRS mentions the benefits
of our project, how to use the project, how the project was developed, what are the major
things taken in to consideration.

Project Scope:
This Pocket Phonic Application is Android Mobile Application. It helps users to learn about the
basics of English such as alphabets, numbers and rhymes. As it’s an android app, also affordable,
so people can use this application to make their kids learn and play. Also, our app will be useful
for the parents who don’t know about basics of English or uneducated but can make their
children to learn.

4
Problem Definition:

Existing System:

In this Existing System we can use the Phonics chart to show the children. It consists of
Alphabets and words following the pictures. By using this Phonics charts Children can learn the
Alphabetical phonics. But the parents who are uneducated cannot teach them. And we won’t
have facility of reading for numbers, alphabets and rhymes in the existing system.

Proposed System:

This generation mobiles users are increasing day by day, so we thought of proposing an
Android mobile Application for learning the basics of the English language such as alphabets,
numbers and rhymes along with the reading facility , so that users who don’t know basics or
uneducated can learn or make others to learn. The application’s consists of user friendly
environment by providing menu, with entries for alphabets, numbers and rhymes. When we click
on particular alphabet it will show Phonics of Alphabets with pictures and also for numbers,
rhymes. Apart from this also play sound for respective alphabet, number and rhymes.

Overall description
Product Perspective:

The Android SDK includes a comprehensive set of development tools. Requirements include
Java Development Kit, the officially supported integrated development environment (IDE) is
Eclipse (3.2 or later) using the Android Development Tools (ADT) Plug in, though developers
may use any text editor to edit Java and XML files then use command line tools to create, build
and debug Android applications. Information System is developed on android platform so that it
can be deployed on any android powered mobile phone. The application uses Google Apps. The
application should be authenticated to avail mobile App in the project.

5
User Classes and Characteristics:
End user of the application is the mobile phone user. Who with just a button press can
avail games information in android mobile.

The Operating Environment:

Software Requirements used are Windows XP and any other latest editions.

Java 1.6 and Android SDK.

Hardware Requirements used are P4processor, 512MB of Main Memory

(RAM) and 40GB hard disk and base memory.

Design and Implementation Constraints:

Design constraints developers. All modules are coded thoroughly based on
requirements from software organization. The software is designed in such a way that the
user can easily interact with the screen. Software is designed in such a way that it can be
extended to the real time business.

User Documentation
In our user manual we are going to keep the information regarding our product,
which can be understandable by a new person who is going to use it. If a new person is
using it, online help will be provided in that.

6
 Phonics Screen:

System Features:

Modules:

 Menu Provider :
This particular module helps in providing user friendly environment to the
users of our app, by showing them the menu items alphabets, numbers and rhymes.

 Items Provider :
This particular module helps in providing the list of alphabets with images
and text, the list of numbers with images and text, also the list of rhymes with text.

 Media Player:
This particular module helps in providing the text to speech facility for the
item provider. That is on select of item such as alphabet, number and rhymes will play a
sound for respective item.

7
4: External Interface Requirements
4.1 User Interfaces:
This application include GUI standards or product family style guides that are to
be followed, screen layout constraints, buttons and functions that will appear on every
screen, error message display standards, and so on.

4.2 Hardware Interfaces:

We require Internet connection for interacting with Web Service and local
computers for any help or any other requirement. We also need system with P2 or above
processor; 128MB+ RAM and database memory.

SOFTWARE AND HARDWARE REQUIREMENTS:

Technical Environment:

Technologies: Java, Android.

Operating System: Microsoft Windows, Linux or Mac any version

Hardware Requirements:

Processor: P4 or above

Ram: 512MB or Above

Hard Disk: 20GB or above

8
CHAPTER 3: FEASIBILITY STUDY

9
3. FEASIBILITY STUDY

All projects are feasible – given unlimited resources and infinite time! Unfortunately, the
development of computer-based system or product is more likely plagued by a scarcity of
resources and difficult delivery dates. It is both necessary and prudent to evaluate the feasibility
of a project at the earliest possible time. Months or years of effort, thousands or millions of
dollars, and untold professional embarrassment can be averted if an ill-conceived system is
recognized early in the definition phase.

Feasibility and risk analysis are related in many ways. If project risk is great the
feasibility of producing quality software is reduced. During product engineering, however, we
concentrate our attention on four primary areas of interest:

3.1. Technical Feasibility

This application in going to be used in an Internet environment called www (World Wide
Web). So, it is necessary to use a technology that is capable of providing the networking facility
to the application. This application as also able to work on distributed environment. Application
on developed with J2EE (Java 2 Enterprise Edition platform) Technology. One major advantage
in application is platform neutral. We can deploy and used it in any operating system.

GUI is developed using HTML.to capture the information from the customer. HTML is
used to display the content on the browser. It uses HTTP protocol. It is an interpreted language.
It is very easy to develop a page/document using HTML some RAD (Rapid Application
Development) tools are provided to quickly design/develop our application. So many objects
such as button, text fields, and text area etc are providing to capture the information from the
customer.

We can use this application in any OS. They can have their own security and
transactional advantages. But are the responsible for selecting suitable and secured OS, which is
suitable to our application.

10
 The back-end MySQL and front-end application are platform independent. So we can
port this enterprise application in any environment. Both are having their individual
configuration to get better performance and backup issues.

3.2 Economical Feasibility

To decide whether a project is economically feasible, we have to consider various factors as:

 Cost benefit analysis

 Long-term returns
 Maintenance costs

In present system we developing the games. So he/she needs to spend some time to
complete this protocol.

If it is developed to games through internet, He can load from anywhere in the world.

3.3 Operational Feasibility

In our application front end is developed using GUI. So, it is very easy to the load the
games to enter the necessary information.

11
CHAPTER 4: SYSTEM DESIGN

12
System Design:

System design is transition from a user oriented document to programmers or data base
personnel. The design is a solution, how to approach to the creation of a new system. This is
composed of several steps. It provides the understanding and procedural details necessary for
implementing the system recommended in the feasibility study. Designing goes through logical
and physical stages of development, logical design reviews the present physical system, prepare
input and output specification, details of implementation plan and prepare a logical design
walkthrough.

The database tables are designed by analyzing functions involved in the system and format of
the fields is also designed. The fields in the database tables should define their role in the system.
The unnecessary fields should be avoided because it affects the storage areas of the system. Then
in the input and output screen design, the design should be made user friendly. The menu should
be precise and compact.

Software Design

In designing the software following principles are followed:

1. Modularity and partitioning: software is designed such that, each system should consists of
hierarchy of modules and serve to partition into separate function.

2. Coupling: modules should have little dependence on other modules of a system.

3. Cohesion: modules should carry out in a single processing function.

4. Shared use: avoid duplication by allowing a single module is called by other that need the
function it provides

13
4.1 UML Diagrams:

4.1.1 Introduction to UML:

UML is the language used in the information technology industries versions of blue print. It
is a method for describing the system architecture in details using this blue print. It becomes
much easier to build or maintain a system and to ensure that the system we hold up to
requirement changes.

4.2.2 Definition:

UML is general purpose visual modelling language that is used to

 Specify
 Visualize
 Construct
 Document
The artifacts of the software system.

4.2.3 Reasons to model:

 To communicate the desired structure and behaviour of the system.

 To visualize and control the system’s architecture.
 To better understand the system and expose opportunities for specification and reuse.
 To manage risk.
4.2.4 Applications of UML:

 The UML is intended primarily for software intensive systems. It has been used
effectively for such domain as
 Enterprise information systems
 Banking and financial services
 Telecommunications
 Transportation
 Defences/Aerospace

14
  Retail
 Medical Electronics
 Scientific
 Distributed Web-based Services
4.2.5 A Conceptual Model of the UML Model:

Model is a blue simplification of reality. A model provides the blue prints of a system. We
build models so that we can better understand the system we are developing. We build models of
complex systems because we cannot comprehend such a system in its entirety.

Modelling helps us to visualize a system as it is or as we want it to be. They give us a

template that guides us in constructing system and documents the decisions we have made.

Principles of Modelling:

The choice of what models to create has a profound influence on how a problem is attacked

and how a solution is shaped.

Every model may be expressed at different levels of precision.

The best models are connected to reality.

No single model is sufficient. Every nontrivial system is best approached through a small

set of nearly independent models.

4.2.6 Building Blocks of the UML:

The three kinds of building blocks in UML are

A. Things

B. Relationships

C. Diagrams

15
A. Things in UML

There are four kinds of things in UML

1. Structural things

2. Behavioural things

3. Grouping things

4. Annotational things

Structural Things:

Structural things are the nouns of UML models. These are mostly the static parts of a
model, representing elements that are either conceptual or physical. There are seven kinds of
structural things. They are

Class:

Class is a description of a set of objects that share the same attributes, operations,
relationships and semantics. A class implements one or more interfaces.

Graphically, a class is rendered as a rectangle, usually including its name, attributes and
operations.

Interface:

Interface is a collection of operations that specify a service of a class or component.

An interface describes the externally visible behaviour of that element. An interface might
represent the complete behaviour of a class or component. Graphically, an interface is rendered
as a circle together with its name.

16
Collaboration:

Collaboration defines an interaction and is a society of roles and other elements that work
together to provide some cooperative behaviour. So, collaborations have structural as well as
behavioural, dimensions. These collaborations represent the implementation of patterns that
make up a system. Graphically, collaboration is rendered as an ellipse with dashed lines, usually
including only its name.

Use Case:

Use case is a description of set of sequence of actions that a system performs that yields an
observable result of value to a particular actor. A use case is used to structure the behavioural
things in a model. A use case is realized by collaboration. Graphically a use case is rendered as
an ellipse with solid lines, usually including only its name.

Active Class:

Active class is a class whose objects own one or more processes or threads and therefore
can initiate control activity. It is a class whose objects represent elements whose behaviour is
concurrent with another element.

Component:

A component is a physical and replaceable part of a system that conforms to and provides
the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with
tabs.

Node:

A node is a physical element that exists at run time and represent computational resource,
generally having at least some memory and often, processing capability. Graphically, a node is
rendered as a cube, usually including only its name.

17
Behavioural Things:

Behavioural things are the dynamic parts of UML models. They are the verbs,
representing behaviour over time and space. There are two types of behavioural things. They are

Interaction:

Interaction is a behaviour that comprises a set of messages exchanged among a set of

objects within a particular context to accomplish a specific purpose

State Machine:

A state machine is a behaviour that specifies a sequence of states, an object, or an

interaction goes through during its life time in response to events, together with its responses to
those events.

Grouping Things:

Grouping things are the organizational parts of UML models. These are the models into
which a model can be decomposed.

Package:

A package is a general purpose mechanism for organizing elements into groups. Structural
things, behavioural things, and even other grouping things may be placed in a package.

Annotational Things:

Annotational things are the explanatory parts of UML models. These are the comments
you may apply to describe, illuminate and remark about any element in a model.

18
4.2.7 Relationships in UML:

There are four kinds of Relationships in UML.

1. Dependency

2. Generalization

3. Association

4. Realization

Dependency:

Dependency is a semantic relationship between two things in which a change to one thing
may affect the semantics of the other thing. Graphically, a dependency is rendered as a dashed
line, possibly directed, and occasionally including a label.

Generalization:

A generalization is a specialization / generalization relationship in which objects of the

specialized element (child) are substitutable for objects of the generalized element (parent). In
this way, the child shares the structure and the behaviour of the parent. Graphically, a
generalization relationship is rendered as a solid line with a hollow arrow head pointing to the
parent.

Association:

An association is a structural relationship that describes a set of links, a link being a

connection among objects. Aggregation is a special kind of association, representing a structural
relationship between a whole and its parts. Graphically, an association is rendered as a solid line,
possibly directed, occasionally including a label.

Realization:

Realization is a semantic relationship between classifiers, wherein one classifier specifies a

contract that another classifier guarantees to carry out.

19
4.2.8 UML Diagrams:

A diagram is graphical representation of a set of elements; most often rendered as a

connected graph of vertices a thing. Diagrams in the UML are of 2 types

 Static diagrams
 Dynamic diagrams
Static diagrams are

 Class diagram
 Object diagram
 Component diagram
 Deployment diagram
Dynamic diagrams are

 Use case diagram

 Sequence diagram
 Collaboration diagram
 State chart diagram
 Activity diagram

20
USECASEDIAGRAM:

Text

Alphab Group of
ets Alphabets Image sound

Text

Number Group of Image

s Numbers
sound
user

Use Text
Group of
Rhymes Case
Rhymes

sound

Sequence Diagram:

The sequence diagram is an interaction diagram that emphasizes the time ordering of messages.
Graphically, a sequence diagram is a table that shows objects arranged along the X axis and
messages, ordered in increasing time, along the Y axis.

Common Properties:

The sequence diagram is just like as special kind of diagram and shares the same properties as all
other diagrams. But it differs from all other diagrams in its contents.

Contents:

Sequence diagram commonly contains the following things

21
Objects:

Objects are typically named or anonymous instances of class. But may also represent
instances of other things such as components, collaboration and nodes. Graphically, object is
rendered as a rectangle with underlining its name as shown in Fig.

c: company

 Links:
A link is a semantic connection among objects i.e., an object of an association is called as a link.
A link is rendered as a line as shown Fig.

 Messages: A message is a specification of a communication between objects that

conveys the information with the expectation that the activity will ensue.

22
Sequence Diagram:

Alphabets:

Alphabets

Actor
1: Click 2: Group Of
Alphabets images
3: View All

4: click image 5: Image display

6: Text and

Numbers:

Numbers

Actor
1: Click 2: Group Of
Numbers images
3: View All

4: click image 5: Image display

6: Text and

23
Rhymes:

Rhymes

Actor
1: Click on 2: Group Of
Rhymes images
3: View All

4: click image 5: Image display

6: Text and

Class Diagram:

A class diagram shows a set of classes, interfaces and collaborations and their
relationships. These diagrams are the most common diagram found in modeling object-oriented
systems.

Common Properties:

A class diagram is just like as special kind of diagram and shares the same properties as all
other diagrams. But it differs from all other diagrams in its contents.

Contents:

Class diagram commonly contains the following things.

 Class:

Class is a description of a set of objects that share the same attributes, operations,
relationships and semantics. A class implements one or more interfaces. Graphically, a

24
 class is rendered as a rectangle, usually including its name, attributes and operations as
shown in fig.

Window
Origin: char

Open ()

Close ()

move()

Class Diagram:

page

Alphabets
Numbers
Rhymes
OnClick();

Alphabets Numbers Rhymes

int img; int img; int img;
String text; String text; String text;
OnClick(); OnClick(); OnClick();

25
Object Diagram

P:page

Alphbets
Numbers
Rhymes
OnClick();

A:Alphabets N:Numbers R:Rhymes

int img; int img; int img;
String text; String text; String text;
OnClick(); OnClick(); OnClick();

Activity Diagram

Alphabets Numbers RHYMES

group Of group Of group Of

images images images

Images Text/sound
Text/sound Images Text/sound Images

State Diagram for pocket Dictionary

26
 Alphabe Number
Rhymes
ts s

group of group of group of

images images images

text text text

image Images Images
/sound /sound /sound

DATA FLOW DIAGRAM

The system specification is produced at the culmination of the analysis task. The function
and Performance allocated the software as part of the system engineering are refined by the
established a complete information of performance requirements and design constraints,
appropriate validation criteria, and others data pertaining to requirements. The tools that are used
in this system analysis are data flow diagram and data dictionary.

DATA FLOW DIAGRAMS

A Data Flow Diagram (DFD) is a graphical technique that depicts information flow and
the transforms that are applied as data move from input to output.

Data flow diagram is a logical model of a system. The model does not depend on
hardware, software, and data structure or file organization. It only shows the data flow between

27
modules to module of the entire system. Data flow diagrams can be completed using only four
notations as follows,

Data Flow Diagrams are of two types:

Physical Data Flow Diagrams

These are implementation-dependent i.e., they show the actual devices, departments,
people, etc., involved in the system.

Logical Data Flow Diagrams

These diagrams describe the system independently of how it is actually implemented,

they show what takes places, rather than how an activity is accomplished.

Data Flow

Data move in a specific direction from an origin to destination. The data flow is a “packet” of
data.

Process

People, procedures or devices that produce data. The physical component is not
identified.

Source or Destination of Data

External sources or destinations of data, which may be people or organizations or other

entities.

28
 Data Source

Here a process references the data in the system

Data Flow Diagram:

Given Input
Mobile

Play games
User
User

29
CHAPTER 5: INPUT/OUTPUT DESIGNS

30
5. INPUT/OUTPUT DESIGNS
Input design:

Considering the requirements, procedures to collect the necessary input data in most efficiently
designed. The input design has been done keeping in view that, the interaction of the user with
the system being the most effective and simplified way.

Also the measures are taken for the following

 Controlling the amount of input

 Avoid unauthorized access to the Universal Dossier
 Eliminating extra steps
 Keeping the process simple
 At this stage the input forms and screens are designed.

Output design:

All the screens of the system are designed with a view to provide the user with easy operations
in simpler and efficient way, minimum key strokes possible. Instructions and important
information is emphasized on the screen. Almost every screen is provided with no error and
important messages and option selection facilitates. Emphasis is given for speedy processing
and speedy transaction between the screens. Each screen assigned to make it as much user
friendly as possible by using interactive procedures. So to say user can operate the system
without much help from the operating manual.

31
CHAPTER 6: IMPLEMENTATION

32
6. IMPLEMENTATION

OVERVIEW OF SOFTWARE DEVELOPMENT TOOLS

6.1 JAVA 2 MICRO EDITION (J2ME)

J2ME stands for Java 2 Micro Edition. It is a stripped-down version of Java targeted at devices
which have limited processing power, storage capabilities and fairly low-bandwidth network
connections.

A Sample Wireless Stack would consist of:

 Configurations
 Profiles
 Java Virtual Machines

6.2 JAVA VIRTUAL MACHINE

A Java Virtual Machine (JVM) is a set of computer software programs and data structures which
use a virtual machine model for the execution of other computer programs and scripts. JVM
operate on Java byte code, which is normally (but not necessarily) generated from Java source
code; a JVM can also be used to implement programming languages other than Java. The
JVM is a crucial component of the Java platform. The use of the same byte code for all platforms
allows Java to be described as "compile once, run anywhere",

33
 CHAPTER 7: ANDROID

7. Android
34
7.1 Android

Android is a software stack for mobile devices that includes an operating system, middleware
and key applications. The android SDK provides the tools and APIs necessary to begin
developing applications on the Android platform using the Java programming language.

7.2 Features

Application framework enabling reuse and replacement of components

Dalvik virtual machine optimized for mobile devices

Integrated browser based on the open source Web Kit 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 still 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 plug in for the Eclipse IDE

7.3 Android application

35
Developers have full access to the same framework APIs used by the core applications. The
application architecture is designed to simplify the reuse of components; any application can
publish its capabilities and any other application may then make use of those capabilities (subject
to security constraints enforced by the framework). This same mechanism allows components to
be replaced by the user.

7.4 Libraries

Android includes a set of C/C++ libraries used by various components of the Android system.
These capabilities are exposed to developers through the Android application framework. Some
of the core libraries are listed below:

System C library - a BSD-derived implementation of the standard C system library (libc), tuned
for embedded Linux-based devices

Media Libraries - based on Packet Video’s Open CORE; the libraries support playback and
recording of many popular audio and video formats, as well as static image files, including
MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG

Surface Manager - manages access to the display subsystem and seamlessly composites 2D and
3D graphic layers from multiple applications

Lib Web Core - a modern web browser engine which powers both the Android browser and an
embeddable web view

SGL - the underlying 2D graphics engine

3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either
hardware 3D acceleration (where available) or the included, highly optimized 3D software
rasterizer.

Free Type - bitmap and vector font rendering

36
SQLite - a powerful and lightweight relational database engine available to all applications

7.5 Android Runtime

Android includes a set of core libraries that provides most of the functionality available in the
core libraries of the Java programming language.

Every Android application runs in its own process, with its own instance of the Dalvik virtual
machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik
VM executes files in the Dalvik Executable format which is optimized for minimal memory
footprint. The VM is register-based, and runs classes compiled by a Java language compiler that
have been transformed into the .dex format by the included "dx" tool.

The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and
low-level memory management.

an Android code editor that helps you write valid XML for your Android manifest and resource
files.

It will even export your project into a signed APK, which can be distributed to users.

To begin developing Android applications in the Eclipse IDE with ADT, you first need to
download the Eclipse IDE and then download and install the ADT plug in. To do so, follow the
steps given in Installing the ADT Plugin.

7.6 Developing in eclipse with ADT:

The Android Development Tools (ADT) plug in for Eclipse adds powerful extensions to the
Eclipse integrated development environment. It allows you to create and debug Android
applications easier and faster. If you use Eclipse, the ADT plug in gives you an incredible boost
in developing Android applications:

It gives you access to other Android development tools from inside the Eclipse IDE. For
example, ADT lets you access the many capabilities of the DDMS tool: take screenshots,

37
manage port-forwarding, set breakpoints, and view thread and process information directly from
Eclipse.

It provides a New Project Wizard, which helps you quickly create and set up all of the basic files
you'll need for a new Android application.

It automates and simplifies the process of building your Android application.

It provides

7.7 Creating an Android project

The ADT plug in provides a New Project Wizard that you can use to quickly create a new
Android project (or a project from existing code). To create a new project:

1. Select File > New > Project.

2. Select Android > Android Project, and click Next.
3. Select the contents for the project:

Enter a Project Name. This will be the name of the folder where your project is created.
Under Contents, select Create new project in workspace. Select your project workspace
location.
Under Target, select an Android target to be used as the project's Build Target. The Build Target
specifies which Android platform you'd like your application built against.

Unless you know that you'll be using new APIs introduced in the latest SDK, you should select a
target with the lowest platform version possible, such as Android 1.1.

Note: You can change you’re the Build Target for your project at any time: Right-click the
project in the Package Explorer, select Properties, select Android and then check the desired
Project Target.
Under Properties, fill in all necessary fields.
Enter an Application name. This is the human-readable title for your application — the name that
will appear on the Android device.

38
Enter a Package name. This is the package namespace (following the same rules as for packages
in the Java programming language) where all your source code will reside.
Select Create Activity (optional, of course, but common) and enter a name for your main Activity
class.
Enter a Min SDK Version. This is an integer that indicates the minimum API Level required to
properly run your application. Entering this here automatically sets the minSdkVersion attribute
in the <uses-sdk> of your Android Manifest file. If you're unsure of the appropriate API Level to
use, copy the API Level listed for the Build Target you selected in the Target tab.

4.Click Finish.

Once you complete the New Project Wizard, ADT creates the following folders and files in your
new project:

src/

Includes your stub Activity Java file. All other Java files for your application go here.

<Android Version>/ (e.g., Android 1.1/)

Includes the android.jar file that your application will build against. This is determined by
the build target that you have chosen in the New Project Wizard.

gen/
This contains the Java files generated by ADT, such as your R.java file and interfaces
created from AIDL files.

assets/
This is empty. You can use it to store raw asset files. See Resources and Assets.

res/
A folder for your application resources, such as drawable files, layout files, string values,
etc. See Resources and Assets.

AndroidManifest.xml
The Android Manifest for your project. See The AndroidManifest.xml File.

39
Default. Properties
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. It should
never be edited manually — to edit project properties, right-click the project folder and
select "Properties".

7.7.1 Running your application:

Before you can run your application on the Android Emulator, you must create an Android
Virtual Device (AVD). An AVD is a configuration that specifies the Android platform to be used
on the emulator. You can read more in the Android Virtual Devices document, but if you just
want to get started, follow the simple guide below to create an AVD.

If you will be running your applications only on actual device hardware, you do not need an
AVD — see Developing On a Device for information on running your application.

7.7.2 Creating an AVD:

With ADT 0.9.3 and above, the Android SDK and AVD Manager provides a simple graphical
interface for creating and managing AVDs. (If you're using ADT version 0.9.1 or older, you
must use the android tool to create your AVDs—read the AVD guide to Creating an AVD.)

To create an AVD with the AVD Manager:

Select Window > Android SDK and AVD Manager, or click the Android SDK and AVD
Manager icon (a black device) in the Eclipse toolbar.

In the Virtual Devices panel, you'll see a list of existing AVDs. Click New to create a new AVD.

Fill in the details for the AVD.

Give it a name, a platform target, an SD card image (optional), and a skin (HVGA is default).

Click Create AVD.

40
Your AVD is now ready and you can close the AVD Manager. In the next section, you'll see
how the AVD is used when launching your application on an emulator.

For more information about AVDs, read the Android Virtual Devices documentation.

7.7.3 Running your application:

Note: Before you can run your application, be sure that you have created an AVD with a
target that satisfies your application's Build Target. If an AVD cannot be found that meets the
requirements of your Build Target, you will see a console error telling you so and the launch
will be aborted.

To run (or debug) your application, select Run > Run (or Run > Debug) from the Eclipse main
menu. The ADT plug in will automatically create a default launch configuration for the project.

When you choose to run or debug your application, Eclipse will perform the following:

Compile the project (if there have been changes since the last build).

Create a default launch configuration (if one does not already exist for the project).

Install and start the application on an emulator or device (based on the Deployment Target
defined by the run configuration).

By default, Android application run configurations use an "automatic target" mode for selecting
a device target. For information on how automatic target mode selects a deployment target, see
Automatic and manual target modes below.

If debugging, the application will start in the "Waiting for Debugger" mode. Once the debugger
is attached, Eclipse will open the Debug perspective.

To set or change the launch configuration used for your project, use the launch configuration
manager. See Creating a Launch Configuration for information.

7.7.4 Creating a run configuration:

41
The run configuration specifies the project to run, the Activity to start, the emulator options to
use, and so on. When you first run a project as an Android Application, ADT will automatically
create a run configuration. The default run configuration will launch the default project Activity
and use automatic target mode for device selection (with no preferred AVD). If the default
settings don't suit your project, you can customize the launch configuration or even create a new.

To create or modify a launch configuration, follow these steps as appropriate for your Eclipse
version: Open the run configuration manager.

In Eclipse 3.3 (Europa), select Run > Open Run Dialog (or Open Debug Dialog)
In Eclipse 3.4 (Ganymede), select Run > Run Configurations (or Debug Configurations)

Expand the Android Application item and create a new configuration or open an existing one.

To create a new configuration:

Select Android Application and click the New launch configuration icon above the list (or,
right-click Android Application and click New).
Enter a Name for your configuration.
In the Android tab, browse and select the project you'd like to run with the configuration.
To open an existing configuration, select the configuration name from the list nested below
Android Application.

Adjust your desired launch configuration settings. In the Target tab, consider whether you'd like
to use Manual or Automatic mode when selecting an AVD to run your application. See the
following section on Automatic and manual target modes).

You can specify any emulator options to the Additional Emulator Command Line Options field.
For example, you could add -scale 96dpi to scale the AVD's screen to an accurate size, based on
the dpi of your computer monitor. For a full list of emulator options, see the Android Emulator
document.

7.8 Designing:

Designing for performance:

42
An Android application should be fast. Well, it's probably more accurate to say that it should be
efficient. That is, it should execute as efficiently as possible in the mobile device environment,
with its limited computing power and data storage, smaller screen, and constrained battery life.

As you develop your application, keep in mind that, while the application may perform well
enough in your emulator, running on your dual-core development computer, it will not perform
that well when run a mobile device — even the most powerful mobile device can't match the
capabilities of a typical desktop system. For that reason, you should strive to write efficient code,
to ensure the best possible performance on a variety of mobile devices.

Generally speaking, writing fast or efficient code means keeping memory allocations to a
minimum, writing tight code, and avoiding certain language and programming idioms that can
subtly cripple performance. In object-oriented terms, most of this work takes place at the method
level, on the order of actual lines of code, loops, and so on.

Introduction:

There are two basic rules for resource-constrained systems:

Don't do work that you don't need to do.

Don't allocate memory if you can avoid it.

All the tips below follow from these two basic tenets.

Some would argue that much of the advice on this page amounts to "premature optimization."
While it's true that micro-optimizations sometimes make it harder to develop efficient data
structures and algorithms, on embedded devices like handsets you often simply have no choice.
For instance, if you bring your assumptions about VM performance on desktop machines to
Android, you're quite likely to write code that exhausts system memory. This will bring your
application to a crawl — let alone what it will do to other programs running on the system!

That's why these guidelines are important. Android's success depends on the user experience that
your applications provide, and that user experience depends in part on whether your code is

43
responsive and snappy, or slow and aggravating. Since all our applications will run on the same
devices, we're all in this together, in a way. Think of this document as like the rules of the road
you had to learn when you got your driver's license: things run smoothly when everybody
follows them, but when you don't, you get your car smashed up.

Before we get down to brass tacks, a brief observation: nearly all issues described below are
valid whether or not the VM features a JIT compiler. If I have two methods that accomplish the
same thing, and the interpreted execution of foo () is faster than bar (), then the compiled version
of foo () will probably be as fast or faster than compiled bar (). It is unwise to rely on a compiler
to "save" you and make your code fast enough.

Avoid creating objects:

Object creation is never free. A generational GC with per-thread allocation pools for temporary
objects can make allocation cheaper, but allocating memory is always more expensive than not
allocating memory.

If you allocate objects in a user interface loop, you will force a periodic garbage collection,
creating little "hiccups" in the user experience.

Thus, you should avoid creating object instances you don't need to. Some examples of things that
can help:

When extracting strings from a set of input data, try to return a substring of the original data,
instead of creating a copy. You will create a new String object, but it will share the char [] with
the data.

If you have a method returning a string, and you know that its result will always be appended to
a String Buffer anyway, change your signature and implementation so that the function does the
append directly, instead of creating a short-lived temporary object.

A somewhat more radical idea is to slice up multidimensional arrays into parallel single one-
dimension arrays:

44
An array of ints is a much better than an array of Integers, but this also generalizes to the fact
that two parallel arrays of ints are also a lot more efficient than an array of (int,int) objects. The
same goes for any combination of primitive types.

If you need to implement a container that stores tuples of (Foo, Bar) objects, try to remember
that two parallel Foo[] and Bar[] arrays are generally much better than a single array of custom
(Foo, Bar) objects. (The exception to this, of course, is when you're designing an API for other
code to access; in those cases, it's usually better to trade correct API design for a small hit in
speed. But in your own internal code, you should try and be as efficient as possible.)

Generally speaking, avoid creating short-term temporary objects if you can. Fewer objects
created mean less-frequent garbage collection, which has a direct impact on user experience.

Use native methods:

When processing strings, don't hesitate to use specialty methods like String.indexOf(),
String.lastIndexOf(), and their cousins. These are typically implemented in C/C++ code that
easily runs 10-100x faster than doing the same thing in a Java loop.

The flip side of that advice is that punching through to a native method is more expensive than
calling an interpreted method. Don't use native methods for trivial computation, if you can avoid
it.

Prefer Virtual Over Interface:

Suppose you have a HashMap object. You can declare it as a HashMap or as a generic Map:

Map myMap1 = new HashMap();

45
HashMap myMap2 = new HashMap();

Which is better?

Conventional wisdom says that you should prefer Map, because it allows you to change the
underlying implementation to anything that implements the Map interface. Conventional wisdom
is correct for conventional programming, but isn't so great for embedded systems. Calling
through an interface reference can take 2x longer than a virtual method call through a concrete
reference.

If you have chosen a Hash Map because it fits what you're doing, there is little value in calling it
a Map. Given the availability of IDEs that refactor your code for you, there's not much value in
calling it a Map even if you're not sure where the code is headed. (Again, though, public APIs
are an exception: a good API usually trumps small performance concerns.)

Prefer static over virtual:

If you don't need to access an object's fields, make your method static. It can be called faster,
because it doesn't require a virtual method table indirection. It's also good practice, because you
can tell from the method signature that calling the method can't alter the object's state.

Avoid internal getters/setters:

In native languages like C++ it's common practice to use getters (e.g. i = getCount()) instead of
accessing the field directly (i = mCount). This is an excellent habit for C++ because the compiler
can usually inline the access, and if you need to restrict or debug field access you can add the
code at any time.

On Android, this is a bad idea. Virtual method calls are expensive, much more so than instance
field lookups. It's reasonable to follow common object-oriented programming practices and have
getters and setters in the public interface, but within a class you should always access fields
directly.
46
Cache Field Lookup:

Accessing object fields is much slower than accessing local variables. Instead of writing:

for (int i = 0; i < this.mCount; i++)

dumpItem(this.mItems[i]);

You should write:

int count = this.mCount;

Item[] items = this.mItems;

for (int i = 0; i < count; i++)

dumpItems(items[i]);

(We're using an explicit "this" to make it clear that these are member variables.)

A similar guideline is never call a method in the second clause of a "for" statement. For example,
the following code will execute the getCount() method once per iteration, which is a huge waste
when you could have simply cached the value as an int:

for (int i = 0; i < this.getCount(); i++)

dumpItems(this.getItem(i));

It's also usually a good idea to create a local variable if you're going to be accessing an instance
field more than once. For example:

47
protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {

if (isHorizontalScrollBarEnabled()) {

int size = mScrollBar.getSize(false);

if (size <= 0) {

size = mScrollBarSize;

mScrollBar.setBounds(0, height - size, width, height);

mScrollBar.setParams(

computeHorizontalScrollRange(),

computeHorizontalScrollOffset(),

computeHorizontalScrollExtent(), false);

mScrollBar.draw(canvas);

That's four separate lookups of the member field mScrollBar. By caching mScrollBar in a local
stack variable, the four member field lookups become four stack variable references, which are
much more efficient.

Incidentally, method arguments have the same performance characteristics as local variables.

Declare Constants Final:

Consider the following declaration at the top of a class:

48
static int intVal = 42;

static String strVal = "Hello, world!";

The compiler generates a class initializer method, called <clinit>, that is executed when the class
is first used. The method stores the value 42 into intVal, and extracts a reference from the
classfile string constant table for strVal. When these values are referenced later on, they are
accessed with field lookups.

We can improve matters with the "final" keyword:

static final int intVal = 42;

static final String strVal = "Hello, world!";

The class no longer requires a <clinit> method, because the constants go into classfile static field
initializes, which are handled directly by the VM. Code accessing intVal will use the integer
value 42 directly, and accesses to strVal will use a relatively inexpensive "string constant"
instruction instead of a field lookup.

Declaring a method or class "final" does not confer any immediate performance benefits, but it
does allow certain optimizations. For example, if the compiler knows that a "getter" method can't
be overridden by a sub-class, it can inline the method call.

You can also declare local variables final. However, this has no definitive performance benefits.
For local variables, only use "final" if it makes the code clearer (or you have to, e.g. for use in an
anonymous inner class).

7.9 Designing for Responsiveness:

It's possible to write code that wins every performance test in the world, but still sends users in a
fiery rage when they try to use the application. These are the applications that aren't responsive

49
enough — the ones that feel sluggish, hang or freeze for significant periods, or take too long to
process input.

In Android, the system guards against applications that are insufficiently responsive for a period
of time by displaying a dialog to the user, called the Application Not Responding (ANR) dialog.
The user can choose to let the application continue, but the user won't appreciate having to act on
this dialog every time he or she uses your application. So it's important to design responsiveness
into your application, so that the system never has cause to display an ANR to the user.

Generally, the system displays an ANR if an application cannot respond to user input. For
example, if an application blocks on some I/O operation (frequently a network access), then the
main application thread won't be able to process incoming user input events. After a time, the
system concludes that the application has hung, and displays the ANR to give the user the option
to kill it.

Similarly, if your application spends too much time building an elaborate in-memory structure,
or perhaps computing the next move in a game, the system will conclude that your application
has hung. It's always important to make sure these computations are efficient using the
techniques above, but even the most efficient code still takes time to run.

In both of these cases, the fix is usually to create a child thread, and do most of your work there.
This keeps the main thread (which drives the user interface event loop) running, and prevents the
system from concluding your code has frozen. Since such threading usually is accomplished at
the class level, you can think of responsiveness as a class problem. (Compare this with basic
performance, which was described above as a method-level concern.)This document discusses
how the Android system determines whether an application is not responding and provides
guidelines for ensuring that your application is responsive.

What Triggers ANR:

In Android, application responsiveness is monitored by the Activity Manager and Window

Manager System services. Android will display the ANR dialog for a particular application when
it detects one of the following conditions:

50
No response to an input event (e.g. key press, screen touch) within 5 seconds

A Broadcast Receiver hasn't finished executing within 10 seconds

How to Avoid ANR:

Given the above definition for ANR, let's examine why this can occur in Android applications
and how best to structure your application to avoid ANR.

Android applications normally run entirely on a single (i.e. main) thread. This means that
anything your application is doing in the main thread that takes a long time to complete can
trigger the ANR dialog because your application is not giving itself a chance to handle the input
event or Intent broadcast.

Therefore any method that runs in the main thread should do as little work as possible. In
particular, Activities should do as little as possible to set up in key life-cycle methods such as on
Create () and on Resume (). Potentially long running operations such as network or database
operations, or computationally expensive calculations such as resizing bitmaps should be done in
a child thread (or in the case of databases operations, via an asynchronous request). However,
this does not mean that your main thread should block neither while waiting for the child thread
to complete nor should you call Thread. Wait () or Thread. Sleep (). Instead of blocking while waiting
for a child thread to complete, your main thread should provide a Handler for child threads to
post back to upon completion. Designing your application in this way will allow your main
thread to remain responsive to input and thus avoid ANR dialogs caused by the 5 second input
event timeout. These same practices should be followed for any other threads that display UI, as
they are also subject to the same timeouts.

The specific constraint on Intent Receiver execution time emphasizes what they were meant to
do: small, discrete amounts of work in the background such as saving a setting or registering a
Notification. So as with other methods called in the main thread, applications should avoid
potentially long-running operations or calculations in Broadcast Receivers. But instead of doing
intensive tasks via child threads (as the life of a Broadcast Receiver is short), your application
should start a Service if a potentially long running action needs to be taken in response to an

51
Intent broadcast. As a side note, you should also avoid starting an Activity from an Intent
Receiver, as it will spawn a new screen that will steal focus from whatever application the user is
currently has running. If your application has something to show the user in response to an Intent
broadcast, it should do so using the Notification Manager.

Reinforcing Responsiveness:

Generally, 100 to 200ms is the threshold beyond which users will perceive lag (or lack of
"snappiness," if you will) in an application. As such, here are some additional tips beyond what
you should do to avoid ANR that will help make your application seem responsive to users.

If your application is doing work in the background in response to user input, show that progress
is being made (Progress Bar and Progress Dialog are useful for this).

For games specifically, do calculations for moves in a child thread.

If your application has a time-consuming initial setup phase, consider showing a splash screen or
rendering the main view as quickly as possible and filling in the information asynchronously. In
either case, you should indicate somehow that progress is being made, lest the user perceive that
the application is frozen.

7.10 Designing for Seamlessness:

Even if your application is fast and responsive, certain design decisions can still cause problems
for users — because of unplanned interactions with other applications or dialogs, inadvertent loss
of data, unintended blocking, and so on. To avoid these problems, it helps to understand the
context in which your applications run and the system interactions that can affect your
application. In short, you should strive to develop an application that interacts seamlessly with
the system and with other applications.

52
A common seamlessness problem is when an application's background process — for example, a
service or broadcast receiver — pops up a dialog in response to some event. This may seem like
harmless behavior, especially when you are building and testing your application in isolation, on
the emulator. However, when your application is run on an actual device, your application may
not have user focus at the time your background process displays the dialog. So it could end up
that your application would display it's dialog behind the active application, or it could take
focus from the current application and display the dialog in front of whatever the user was doing
(such as dialing a phone call, for example). That behavior would not work for your application or
for the user.

To avoid these problems, your application should use the proper system facility for notifying the
user — the Notification classes. Using notifications, your application can signal the user that an
event has taken place, by displaying an icon in the status bar rather than taking focus and
interrupting the user.

Another example of a seamlessness problem is when an activity inadvertently loses state or user
data because it doesn't correctly implement the on Pause () and other lifecycle methods. Or, if
your application exposes data intended to be used by other applications, you should expose it via
a Content Provider, rather than (for example) doing so through a world-readable raw file or
database.

What those examples have in common is that they involve cooperating nicely with the system
and other applications. The Android system is designed to treat applications as a sort of
federation of loosely-coupled components, rather than chunks of black-box code. This allows
you as the developer to view the entire system as just an even-larger federation of these
components. This benefits you by allowing you to integrate cleanly and seamlessly with other
applications, and so you should design your own code to return the favor.

This document discusses common seamlessness problems and how to avoid them. It covers these
topics:

Don’t Drop Data:

53
Always keep in mind that Android is a mobile platform. It may seem obvious to say it, but it's
important to remember that another Activity (such as the "Incoming Phone Call" app) can pop up
over your own Activity at any moment. This will fire the onSaveInstanceState () and on Pause()
methods, and will likely result in your application being killed.

If the user was editing data in your application when the other Activity appeared, your
application will likely lose that data when your application is killed. Unless, of course, you save
the work in progress first. The "Android Way" is to do just that: Android applications that accept
or edit input should override the onSaveInstanceState () method and save their state in some
appropriate fashion. When the user revisits the application, she should be able to retrieve her
data.

A classic example of a good use of this behaviour is a mail application. If the user was
composing an email when another Activity started up, the application should save the in-process
email as a draft.

Don’t Expose Raw Data:

If you wouldn't walk down the street in your underwear, neither should your data. While it's
possible to expose certain kinds of application to the world to read, this is usually not the best
idea. Exposing raw data requires other applications to understand your data format; if you
change that format, you'll break any other applications that aren't similarly updated.

The "Android Way" is to create a Content Provider to expose your data to other applications via
a clean, well-thought-out, and maintainable API. Using a Content Provider is much like inserting
a Java language interface to split up and componentized two tightly-coupled pieces of code. This
means you'll be able to modify the internal format of your data without changing the interface
exposed by the Content Provider, and this without affecting other applications.

Don’t Interrupt The User:

If the user is running an application (such as the Phone application during a call) it's a pretty safe
bet he did it on purpose. That's why you should avoid spawning activities except in direct
response to user input from the current Activity.

54
That is, don't call start Activity () from Broadcast Receivers or Services running in the
background. Doing so will interrupt whatever application is currently running, and result in an
annoyed user. Perhaps even worse, your Activity may become a "keystroke bandit" and receive
some of the input the user was in the middle of providing to the previous Activity. Depending on
what your application does, this could be bad news.

Instead of spawning Activity UIs directly from the background, you should instead use the
Notification Manager to set Notifications. These will appear in the status bar, and the user can
then click on them at his leisure, to see what your application has to show him.

(Note that all this doesn't apply to cases where your own Activity is already in the foreground: in
that case, the user expects to see your next Activity in response to input.)

Go a Lot to Do? Do it in a Thread:

If your application needs to perform some expensive or long-running computation, you should
probably move it to a thread. This will prevent the dreaded "Application Not Responding" dialog
from being displayed to the user, with the ultimate result being the fiery demise of your
application.

By default, all code in an Activity as well as all its Views run in the same thread. This is the
same thread that also handles UI events. For example, when the user presses a key, a key-down
event is added to the Activity's main thread's queue. The event handler system needs to dequeue
and handle that event quickly; if it doesn't, the system concludes after a few seconds that the
application is hung and offers to kill it for the user.

If you have long-running code, running it inline in your Activity will run it on the event handler
thread, effectively blocking the event handler. This will delay input processing, and result in the
ANR dialogs. To avoid this, move your computations to a thread. This Design for
Responsiveness document discusses how to do that.

Don’t over load a single activity screen:

55
Any application worth using will probably have several different screens. When designing the
screens of your UI, be sure to make use of multiple Activity object instances.

Depending on your development background, you may interpret an Activity as similar to

something like a Java Applet, in that it is the entry point for your application. However, that's not
quite accurate: where an Applet subclass is the single entry point for a Java Applet, an Activity
should be thought of as one of potentially several entry points to your application. The only
difference between your "main" Activity and any others you might have is that the "main" one
just happens to be the only one that expressed an interest in the "android.intent.action.MAIN"
action in your Android Manifest.xml file.

So, when designing your application, think of your application as a federation of Activity
objects. This will make your code a lot more maintainable in the long run, and as a nice side
effect also plays nicely with Android's application history and "back stack" model.

Extended system themes:

When it comes to the look-and-feel of the user interface, it's important to blend in nicely. Users
are jarred by applications which contrast with the user interface they've come to expect. When
designing your UIs, you should try and avoid rolling your own as much as possible. Instead, use
a Theme. You can override or extend those parts of the theme that you need to, but at least you're
starting from the same UI base as all the other applications. For all the details, read Applying
Styles and Themes.

Design your UI to work with multiple screen resolutions:

Different Android-powered devices will support different screen resolutions. Some will even be
able to change resolutions on the fly, such as by switching to landscape mode. It's important to
make sure your layouts and drawable are flexible enough to display properly on a variety of
device screens.

56
Fortunately, this is very easy to do. In brief, what you must do is provide different versions of
your artwork (if you use any) for the key resolutions, and then design your layout to
accommodate various dimensions. (For example, avoid using hard-coded positions and instead
use relative layouts.) If you do that much, the system handles the rest, and your application looks
great on any device.

Assume the network is slow:

Android devices will come with a variety of network-connectivity options. All will have some
data-access provision, though some will be faster than others. The lowest common denominator,
however, is GPRS, the non-3G data service for GSM networks. Even 3G-capable devices will
spend lots of time on non-3G networks, so slow networks will remain a reality for quite a long
time to come.

That's why you should always code your applications to minimize network accesses and
bandwidth. You can't assume the network is fast, so you should always plan for it to be slow. If
your users happen to be on faster networks, then that's great — their experience will only
improve. You want to avoid the inverse case though: applications that are usable some of the
time, but frustratingly slow the rest based on where the user is at any given moment are likely to
be unpopular.

One potential gotcha here is that it's very easy to fall into this trap if you're using the emulator,
since the emulator uses your desktop computer's network connection. That's almost guaranteed to
be much faster than a cell network, so you'll want to change the settings on the emulator that
simulate slower network speeds. You can do this in Eclipse, in the "Emulator Settings" tab of
your launch configuration or via a command-line option when starting the emulator.

Don’t assume touch screen or key board:

Android will support a variety of handset form-factors. That's a fancy way of saying that some
Android devices will have full "QWERTY" keyboards, while others will have 40-key, 12-key, or
even other key configurations. Similarly, some devices will have touch-screens, but many won't.

57
When building your applications, keep that in mind. Don't make assumptions about specific
keyboard layouts -- unless, of course, you're really interested in restricting your application so
that it can only be used on those devices.

Do converse the device battery:

A mobile device isn't very mobile if it's constantly plugged into the wall. Mobile devices are
battery-powered, and the longer we can make that battery last on a charge, the happier everyone
is — especially the user. Two of the biggest consumers of battery power are the processor, and
the radio; that's why it's important to write your applications to do as little work as possible, and
use the network as infrequently as possible.

Minimizing the amount of processor time your application uses really comes down to writing
efficient code. To minimize the power drain from using the radio, be sure to handle error
conditions gracefully, and only fetch what you need. For example, don't constantly retry a
network operation if one failed. If it failed once, it's likely because the user has no reception, so
it's probably going to fail again if you try right away; all you'll do is waste battery power.

Users are pretty smart: if your program is power-hungry, you can count on them noticing. The
only thing you can be sure of at that point is that your program won't stay installed very long.

58
 CHAPTER 8: TESTING

8. TESTING

Software Testing

Testing
Software testing is a critical element of software quality assurance and represents the ultimate
review of specification, design and code generation.

59
8.1 TESTING OBJECTIVES
 To ensure that during operation the system will perform as per specification.
 TO make sure that system meets the user requirements during operation
 To make sure that during the operation, incorrect input, processing and output will
be detected
 To see that when correct inputs are fed to the system the outputs are correct
 To verify that the controls incorporated in the same system as intended
 Testing is a process of executing a program with the intent of finding an error
 A good test case is one that has a high probability of finding an as yet
undiscovered error

The software developed has been tested successfully using the following testing strategies and
any errors that are encountered are corrected and again the part of the program or the procedure
or function is put to testing until all the errors are removed. A successful test is one that uncovers
an as yet undiscovered error.

Note that the result of the system testing will prove that the system is working correctly. It will
give confidence to system designer, users of the system; prevent frustration during
implementation process etc.

8.2 TEST CASE DESIGN:

White box testing

White box testing is a testing case design method that uses the control structure of the procedure
design to derive test cases. All independents path in a module are exercised at least once, all
logical decisions are exercised at once, execute all loops at boundaries and within their
operational bounds exercise internal data structure to ensure their validity. Here the customer is
given three chances to enter a valid choice out of the given menu. After which the control exits
the current menu.

60
Black Box Testing

Black Box Testing attempts to find errors in following areas or categories, incorrect or missing
functions, interface error, errors in data structures, performance error and initialization and
termination error. Here all the input data must match the data type to become a valid entry.

The following are the different tests at various levels:

Unit Testing:

Unit testing is essentially for the verification of the code produced during the coding phase and the
goal is test the internal logic of the module/program. In the Generic code project, the unit testing is
done during coding phase of data entry forms whether the functions are working properly
or not. In this phase all the drivers are tested they are rightly connected or not.

Integration Testing:

All the tested modules are combined into sub systems, which are then tested. The goal is to
see if the modules are properly integrated, and the emphasis being on the testing interfaces
between the modules. In the generic code integration testing is done mainly on table
creation module and insertion module.

Validation Testing

This testing concentrates on confirming that the software is error-free in all respects. All the
specified validations are verified and the software is subjected to hard-core testing. It also
aimsatdetermining the degree of deviation that exists in the software designed from the
specification; they are listed out and are corrected.

System Testing

This testing is a series of different tests whose primary is to fully exercise the computer-based
system. This involves:

 Implementing the system in a simulated production environment and testing it.

61
  Introducing errors and testing for error handling.

Test Cases:

Test case 1: click on menu items Priority (H, L): High

Test Objective: user should be avail pocket phonics soft ware features in mobile phone.
Test Description: click menu item open group of images and click images and open
another image and then click it display the text and sound.
Requirements Verified: Yes
Test Environment: android sdk software …

62
Test Setup/Pre-Conditions:

Actions Expected Results

User should give the word and get the item Find the information through item click
text and sound.
Pass: Yes Conditions pass: Yes Fail: No
Problems / Issues: NIL
Notes: Successfully Executed

CHAPTER-9: OUTPUT SCREENS

63
64
65
66
67
68
 CHAPTER 10: CODING

Coding:

Grid Demo activity:

package com.coign;

import android.app.Activity;

import android.content.Context;

import android.content.Intent;

import android.os.Bundle;

import android.view.View;

69
import android.view.ViewGroup;

import android.widget.AdapterView;

import android.widget.BaseAdapter;

import android.widget.GridView;

import android.widget.ImageView;

import android.widget.AdapterView.OnItemClickListener;

public class GridDemoActivity extends Activity {

/** Called when the activity is first created. */

int
res[]={R.drawable.a,R.drawable.b,R.drawable.c,R.drawable.d,R.drawable.e,R.drawable.f,R.draw
able.g,R.drawable.h,R.drawable.i,R.drawable.j,R.drawable.k,R.drawable.l,R.drawable.m,R.draw
able.n,R.drawable.o,R.drawable.p,R.drawable.q,R.drawable.r,R.drawable.s,R.drawable.t,R.draw
able.u,R.drawable.v,R.drawable.w,R.drawable.x,R.drawable.y,R.drawable.z12};

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

GridView g=(GridView)findViewById(R.id.grid);

g.setAdapter(new MyAdapter(getApplicationContext()));

g.setOnItemClickListener(new OnItemClickListener(){

70
public void onItemClick(AdapterView<?> arg0, View arg1, int position,

long arg3) {

System.out.println("in grid pos isssssssssssssssssssssssssss"+position);

Intent in=new Intent(GridDemoActivity.this,seconds.class);

in.putExtra("pos",position);

startActivity(in);

}});

class MyAdapter extends BaseAdapter{

Context c;

public MyAdapter(Context con) {

c=con;

public int getCount() {

// TODO Auto-generated method stub

return res.length;

public Object getItem(int position) {

// TODO Auto-generated method stub

return position;

71
 }

public long getItemId(int position) {

// TODO Auto-generated method stub

return position;

public View getView(int position, View convertView, ViewGroup parent) {

// TODO Auto-generated method stub

ImageView iv=new ImageView(c);

iv.setImageResource(res[position]);

return iv;

Page.java

package com.coign;

import android.app.Activity;

import android.content.Intent;

import android.os.Bundle;

import android.view.View;

72
import android.view.View.OnClickListener;

import android.widget.Button;

public class page extends Activity{

public void onCreate(Bundle savedInstanceState){

super.onCreate(savedInstanceState);

setContentView(R.layout.page);

Button bt1=(Button)findViewById(R.id.Button01);

Button bt2=(Button)findViewById(R.id.Button02);

Button bt3=(Button)findViewById(R.id.Button03);

bt1.setOnClickListener(new OnClickListener(){

public void onClick(View v) {

// TODO Auto-generated method stub

Intent it =new Intent(page.this,GridDemoActivity.class);

startActivity(it);

});

bt2.setOnClickListener(new OnClickListener(){

public void onClick(View v) {

73
 // TODO Auto-generated method stub

Intent it =new Intent(page.this,numbers.class);

startActivity(it);

});

bt3.setOnClickListener(new OnClickListener(){

public void onClick(View v) {

// TODO Auto-generated method stub

Intent it =new Intent(page.this,poetry.class);

startActivity(it);

});

ss.java

package com.coign;

import android.app.Activity;

import android.content.Intent;

import android.media.MediaPlayer;

import android.os.Bundle;

74
import android.view.View;

import android.view.View.OnClickListener;

import android.widget.Button;

import android.widget.ImageButton;

import android.widget.TextView;

public class ss extends Activity{

int
res1[]={R.drawable.ones,R.drawable.two,R.drawable.three,R.drawable.four,R.drawable.five,R.d
rawable.six,R.drawable.seven,R.drawable.eight,R.drawable.nine,R.drawable.ten};

public void onCreate(Bundle savedInstanceState){

super.onCreate(savedInstanceState);

setContentView(R.layout.third);

Intent in=getIntent();

Bundle b=in.getExtras();

if(b!=null){

int id=b.getInt("userselection");

final int i=b.getInt("imgnumber");

final int i1=b.getInt("userselection");

final TextView tv=(TextView)findViewById(R.id.TextView01);

final ImageButton imageButton = (ImageButton) findViewById(R.id.ImageButton01);

75
 imageButton.setBackgroundResource(R.drawable.two2);

imageButton.setOnClickListener(new OnClickListener(){

public void onClick(View v) {

// TODO Auto-generated method stub

MediaPlayer mp = MediaPlayer.create(ss.this,R.raw.two);

mp.start();

tv.setText("TWO");

});

Button b2=(Button)findViewById(R.id.Button02);

b2.setOnClickListener(new OnClickListener(){

public void onClick(View v) {

// TODO Auto-generated method stub

Intent it=new Intent(ss.this,page.class);

startActivity(it);

}});

Button b1=(Button)findViewById(R.id.Button01);

76
 //Button b2=(Button)findViewById(R.id.Button02);

b1.setOnClickListener(new OnClickListener(){

public void onClick(View v) {

// TODO Auto-generated method stub

Intent it=new Intent(ss.this,numbers.class);

startActivity(it);

});

77
 CHAPTER 11: CONCLUSION

CONCLUSION:

This application is user friendly so that anyone can operate by using the menu provided for
alphabets, numbers and rhymes. Also, our app not only displays the alphabets, numbers and
rhymes in the form of images, but also play the sound for the respective letter, number and
rhymes.

78