A

Mini Project
On

RANDOMIZED ON-SCREEN KEYBOARD

Submitted by
Deepak Undrakonda (08K91A0513) Sandeep Taduri (08K91A0557) Sandeep Appalashetty (08K91A0556) Anvesh Vempati (08K91A0504)

TKR COLLEGE OF ENGINEERING & TECHNOLOGY

(Accredited by NBA, Approved by AICTE and Affiliated to JNTUH)

1.

ABSTRACT

Keystroke logging (often called as Keylogging) is the action of tracking the keys struck on a keyboard, typically in a covert manner so that the person using the keyboard is unaware that their actions are being monitored. There are numerous keylogging methods, ranging from hardware & software-based approaches to electromagnetic and acoustic analysis. Malicious people can make use of keyloggers to capture personal information being input into a computer system such as credit card details, login information, etc. There are some existing solutions for this problem of keylogging, such as: On-screen keyboard, Anti-spywares, etc. But they are restricted to their functionalities, for example hardware keyloggers are not detected by Anti-spywares, On-screen keyboard cannot completely resolve the problem of some software keyloggers which maps the pixel position of every mouse click thereby revealing the data. We have come up with an idea which is an enhancement of the Onscreen keyboard in which the keys are randomly arranged every time it is initialized & with every click on a virtual key. This enhancement provides security from typical keylogger up to a major extent.

Functionalities:
Enter login credentials from the virtual keyboard Uses custom built Random Function to arrange the key on the virtual keyboard Provides secure environment to enter login credentials

Technical Environment:
Technology: Java, HTML, CSS, SQL. Operating System: Any OS

2. Introduction
Purpose
Keyloggers, both hardware and software, are basically designed to capture what a user types on the keyboard. On the web application side, one method to avoid keystroke capture is to use a virtual keyboard for entering the login credentials and other sensitive data. A virtual keyboard is analogous to a graphical keypad where a user clicks on the characters rather than types them on the keyboard. This approach may not be practical for every user, for obvious reasons. However, that even this approach is not completely secure, as some keyloggers are designed to capture screenshots on every mouse-click. Thus, the password of the user can still be found out when a virtual keyboard is used by looking at the screenshots and getting all the characters clicked corresponding to the mouse click. To avoid this, we have incorporated two new security mechanisms to enhance the security

2.1

Scope
Online banking and online shopping are used often in our day-to-day

lives. This demands a sophisticated security measures to provide security to the users. Our On-line Virtual keyboard provides the advanced features which provide uncompromised security to their users. So the scope of this application is very wide. It can be embedded into any website where sensitive information should be entered. The wide ranges of websites in which it can be used are as follows Online Banking Websites such as SBI, HDFC, Andhra Bank, etc..,

E-Shopping Websites such as ebay, Amazon, FlipCart, etc..,

 Social Networking and E-mail websites such as Facebook, Yahoo, Gmail, etc.., and all other websites where sensitive and personal information is stored

2.3 Project Overview

Virtual keyboards may be used in some cases to reduce the risk of keystroke logging. For example, SBIs online banking service uses a virtual keyboard for the username and password entry. It is more difficult for malware to monitor the display and mouse to obtain the data entered via the virtual keyboard, than it is to monitor real keystrokes. However it is possible, for example by recording screenshots at regular intervals or upon each mouse click. To be of any use, these virtual keyboards must be an integral part of an application or web page. A generic virtual keyboardwhich will work with any program, including those that are not explicitly written for itwill not defeat a key logging program because the virtual keyboard will generate the same keyboard events as a real keyboard, and those events can be trapped and logged just as real keyboard inputs can. SBIs login screen, showing virtual keyboard

Our On-Screen Virtual Keyboard provides additional security from hardware keyloggers and software keyloggers by using new functionalities which are not provided by the on-screen keyboards which are currently used.

2.4 Project Description

It is a variant of virtual on-screen keyboard, it was developed using JAVA, HTML and CSS technologies. The main goal of the project is to provide as much security as possible from the keyloggers. We have used mouse hovering technique to take input from the keyboard to provide security from the keyloggers which uses mouse click events to capture the screen shots. The keys are randomized with every click on the key, to provide security from pixel mapping keyloggers and the keys are set to blank for a while, when the input is taken for further security.

3. System Analysis
3.1 Problem Definition
To address the security problems caused by the keyloggers which are used to track the sensitive information such as login credentials, credit card details etc..,

3.2 Existing System

The existing system is a basic form of on-screen virtual keyboards which is vulnerable to advanced keyloggers such as visual keyloggers.

3.3 Proposed System

We propose a new and advanced kind of on-screen virtual keyboard which includes additional functionalities which provides security from all types of existing keyloggers.

3.4 User Classes and Characteristics

The application can be embedded any websites where there is a necessity to secure the sensitive data entered by the user. The End users of this application are the users of the particular websites.

3.5 Development Environment:

Hardware Environment
Processor: P4 or above Ram: 256MB or Above Hard Disk: 20GB or above

Software Environment Java Eclipse Helios IDE Operating System: Windows XP.

3.6 Design and Implementation Constraints

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 application. Software is designed in such a way that it can be extended to the real time business.

3.7 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. We are going to explain each and every step clearly about our product so that any user can easily understand it.

4. Requirement Specifications
4.1 Software Requirements:
Operating System: Any Operating System Applications: JAVA enabled Internet Browser.

4.2 Hardware Requirements:

Processor: Pentium III or above

RAM: 256Mb or above Hard Disk: 20Gb or above

Mouse

5. System Profile
Java is Gosling at Sun a programming language originally has since developed merged derives by James into Oracle much of Microsystems (which platform. The

Corporation) and released in 1995 as a core component of Sun Microsystems' Java language its syntax from Cand C++ but has a simpler object model and fewer lowlevel facilities. Java applications are typically compiled to bytecode (class file) that can run on any Java Virtual Machine (JVM) regardless of computer architecture. Java is a general-purpose, concurrent, class-based, objectoriented language that is specifically designed to have as few implementation dependencies as possible. It is intended to let application

developers "write once, run anywhere" (WORA), meaning that code that runs on one platform does not need to be recompiled to run on another. Java is currently one of the most popular programming languages in use, particularly for client-server web applications, with a reported 10 million users.[9][10] The original and reference implementation Java compilers, virtual machines, and class libraries were developed by Sun from 1995. As of May 2007, in compliance with the specifications of the Java Community Process, Sun relicensed most of its Java technologies under the GNU General Public License. Others have also developed alternative implementations of these Sun technologies, such as the GNU Compiler for Java and GNU Classpath.

Principles There were five primary goals in the creation of the Java language: 1. 2. 3. 4. 5. Versions Major release versions of Java, along with their release dates:

It should be "simple, object-oriented and familiar" It should be "robust and secure" It should be "architecture-neutral and portable" It should execute with "high performance" It should be "interpreted, threaded, and dynamic"

JDK 1.0 (January 23, 1996) JDK 1.1 (February 19, 1997) J2SE 1.2 (December 8, 1998) J2SE 1.3 (May 8, 2000) J2SE 1.4 (February 6, 2002) J2SE 5.0 (September 30, 2004) Java SE 6 (December 11, 2006)

Java SE 7 (July 28, 2011)

Java platform One characteristic of Java is portability, which means that computer programs written in the Java language must run similarly on any hardware/operating-system platform. This is achieved by compiling the Java language code to an intermediate representation called Java bytecode, instead of directly to platform-specific machine code. Java bytecode instructions are analogous to machine code, but are intended to be interpreted by a virtual machine (VM) written specifically for the host hardware. End-users commonly browser for Java applets. Standardized libraries provide a generic way to access host-specific features such as graphics, threading, and networking. A major benefit of using bytecode is porting. However, the overhead of interpretation means that interpreted programs almost always run more slowly than programs compiled to native executables would. Just-in-Time (JIT) compilers were introduced from an early stage that compile bytecodes to machine code during runtime. Implementations Sun Microsystems officially licensed the Java Standard Edition platform for Linux,[23] Mac OS X,[24] and Solaris. In the past Sun licensed Java to Microsoft but the license expired without renewal.[25] Because Windows does not ship with a Java software platform, a network of third-party vendors and licensees[26] develop them for Windows and other operating system/hardware platforms. Sun's trademark license for usage of the Java brand insists that all implementations be "compatible". This resulted in a legal dispute with Microsoft after Sun claimed that the Microsoft implementation did not use a Java Runtime Environment (JRE) installed on their own machine for standalone Java applications, or in a Web

support RMI or JNI and had added platform-specific features of their own. Sun sued in 1997, and in 2001 won a settlement of US$20 million, as well as a court order enforcing the terms of the license from Sun.[27] As a result, Microsoft no longer ships Java with Windows, and in recent versions of Windows, Internet Explorer cannot support Java applets without a thirdparty plugin. Sun, and others, have made available free Java run-time systems for those and other versions of Windows. Platform-independent Java is essential to the Java EE strategy, and an even more rigorous validation is required to certify an implementation. This environment enables portable server-side applications, such as Web services, Java Servlets, and Enterprise JavaBeans, as well as with embedded systems based on OSGi, Sun using Embedded is working to Java environments. create a fully Through theGlassFish project, functional,

unified open source implementation of the Java EE technologies. Sun also distributes a superset of the JRE called the Java Development Kit (commonly known as the JDK), which includes development tools such as the Java compiler, Javadoc, Jar, and debugger. Performance Main article: Java performance Programs written in Java have a reputation for being slower and requiring more memory than those written in C.[28] However, Java programs' execution speed improved significantly with the introduction of Just-in-time compilation in 1997/1998 for Java 1.1,[29] the addition of language features supporting better code analysis (such as inner classes, StringBuffer class, optional assertions, etc.), and optimizations in the Java Virtual Machine itself, such as HotSpot becoming the default for Sun's JVM in 2000. Currently (February 2012), microbenchmarks show Java 7 is approximately 1.5 times slower than C.[30] Some platforms offer direct hardware support for Java; there are microcontrollers that can run Java in hardware instead of a software Java

Virtual Machine, and ARM based processors can have hardware support for executing Java bytecode through its Jazelle option. Automatic memory management Java uses an automatic garbage collector to manage memory in the object lifecycle. The programmer determines when objects are created, and the Java runtime is responsible for recovering the memory once objects are no longer in use. Once no references to an object remain, the unreachable memory becomes eligible to be freed automatically by the garbage collector. Something similar to a memory leak may still occur if a programmer's code holds a reference to an object that is no longer needed, typically when objects that are no longer needed are stored in containers that are still in use. If methods for a nonexistent object are called, a "null pointer exception" is thrown.[31][32] One of the ideas behind Java's automatic memory management model is that programmers can be spared the burden of having to perform manual memory management. In some languages, memory for the creation of objects is implicitly allocated on the stack, or explicitly allocated and deallocated from the heap. In the latter case the responsibility of managing memory resides with the programmer. If the program does not deallocate an object, a memory leak occurs. If the program attempts to access or deallocate memory that has already been deallocated, the result is undefined and difficult to predict, and the program is likely to become unstable and/or crash. This can be partially remedied by the use of smart pointers, but these add overhead and complexity. Note that garbage collection does not prevent "logical" memory leaks, i.e. those where the memory is still referenced but never used. Garbage collection may happen at any time. Ideally, it will occur when a program is idle. It is guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new object; this can cause a program to stall momentarily. Explicit memory management is not possible in Java.

Java does not support C/C++ style pointer arithmetic, where object addresses and unsigned integers (usually long integers) can be used interchangeably. This allows the garbage collector to relocate referenced objects and ensures type safety and security. As in C++ and some other object-oriented languages, variables of

Java's primitive data types are not objects. Values of primitive types are either stored directly in fields (for objects) or on the stack (for methods) rather than on the heap, as commonly true for objects (but see Escape analysis). This was a conscious decision by Java's designers for performance reasons. Because of this, Java was not considered to be a pure objectoriented programming language. However, as of Java 5.0, autoboxing enables programmers to proceed as if primitive types were instances of their wrapper class. Java contains multiple types of garbage collectors. By default, HotSpot uses the Concurrent Mark Sweep collector, also known as the CMS Garbage Collector. However, there are also several other garbage collectors that can be used to manage the Heap. For 90% of applications in Java, the CMS Garbage Collector is good enough.[33] Syntax Main article: Java syntax The syntax of Java is largely derived from C++. Unlike C++, which combines the syntax for structured, generic, and object-oriented programming, Java was built almost exclusively as an object-oriented language. All code is written inside a class, and everything is an object, with the exception of the primitive data types (integers, floating-point numbers, boolean values, and characters), which are not classes for performance reasons. Unlike C++, Java does not support operator overloading or multiple

inheritance for classes. This simplifies the language and aids in preventing potential errors and anti-pattern design.

Java uses similar commenting methods to C++. There are three different styles of comments: a single line style marked with two slashes (//), a multiple line style opened with /* and closed with */, and the Javadoc commenting style opened with /** and closed with */. The Javadoc style of commenting allows the user to run the Javadoc executable to compile documentation for the program.

Hello world The traditional Hello world program can be written in Java as:[34] class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); // Display the string. } } To compare this to other programming languages see the list of hello world program examples. Source files must be named after the public class they contain, appending the suffix .java, for example, HelloWorldApp.java. It must first be compiled into bytecode, using a Java compiler, producing a file named HelloWorldApp.class. Only then can it be executed, or 'launched'. The Java source file may only contain one public class but can contain multiple classes with less than public access and any number of public inner classes. A class that is not declared public may be stored in any .java file. The compiler will generate a class file for each class defined in the source file. The name of the class file is the name of the class, with .class appended. For class file generation, anonymous classes are treated as if their name were the concatenation of the name of their enclosing class, a $, and an integer. The keyword public denotes that a method can be called from code in other classes, or that a class may be used by classes outside the class hierarchy. The class hierarchy is related to the name of the directory in which the .java file is located.

The keyword static in front of a method indicates a static method, which is associated only with the class and not with any specific instance of that class. Only static methods can be invoked without a reference to an object. Static methods cannot access any class members that are not also static. The keyword void indicates that the main method does not return any value to the caller. If a Java program is to exit with an error code, it must call System.exit() explicitly. The method name "main" is not a keyword in the Java language. It is simply the name of the method the Java launcher calls to pass control to the program. Java classes that run in managed environments such as applets and Enterprise JavaBean do not use or need a main() method. A Java program may contain multiple classes that have main methods, which means that the VM needs to be explicitly told which class to launch from. The main method must accept an array of String objects. By convention, it is referenced as args although any other legal identifier name can be used. Since Java 5, the main method can also use variable arguments, in the form of public static void main(String... args), allowing the main method to be invoked with an arbitrary number ofString arguments. The effect of this alternate declaration is semantically identical (the args parameter is still an array of String objects), but allows an alternative syntax for creating and passing the array. The Java launcher launches Java by loading a given class (specified on the command line or as an attribute in a JAR) and starting its public static void main(String[])method. Stand-alone programs must declare this method explicitly. The String[] args parameter is an array of String objects containing any arguments passed to the class. The parameters to main are often passed by means of a command line. Printing is part of a Java standard library: The System class defines a public static field called out. The out object is an instance of the PrintStream class and provides many methods for printing data to standard out, including println(String) which also appends a new line to the passed string. The string "Hello, world!" is automatically converted to a String object by the compiler. A more comprehensive example // OddEven.java import javax.swing.JOptionPane;

public class OddEven { /** * "input" is the number that the user gives to the computer */ private int input; // a whole number("int" means integer)

/** * This is the constructor method. It gets called when an object of the OddEven type * is being created. */ public OddEven() { /* * In most Java programs constructors can initialize objects with default values, or create * other objects that this object might use to perform its functions. In some Java programs, the * constructor may simply be an empty function if nothing needs to be initialized prior to the * functioning of the object. constructor would suffice, even if In this program's case, an empty

* it is empty. A constructor must exist, however if the user doesn't put one in then the compiler * will create an empty one. */ }

/** * This is the main method. It gets called when this class is run through a Java interpreter. * @param args command line arguments (unused) */ public static void main(final String[] args) { /* * This line of code creates a new instance of this class called "number" (also known as an * Object) and initializes it by calling the constructor. The next line of code calls * the "showDialog()" method, which brings up a prompt to ask you for a number */ OddEven number = new OddEven(); number.showDialog(); }

public void showDialog() { /* * "try" makes sure nothing goes wrong. If something does, * the interpreter skips to "catch" to see what it should do. */ try { /* * The code below brings up a JOptionPane, which is a dialog box

* The String returned by the "showInputDialog()" method is converted into * an integer, making the program treat it as a number instead of a word. * After that, this method calls a second method, calculate() that will * display either "Even" or "Odd." */ this.input Integer.parseInt(JOptionPane.showInputDialog("Please Enter Number")); this.calculate(); } catch (final NumberFormatException e) { /* * Getting in the catch block means that there was a problem with the format of * the number. Probably some letters were typed in instead of a number. */ System.err.println("ERROR: Invalid input. Please type in a numerical value."); } } = A

/** * When this gets called, it sends a message to the interpreter. * The interpreter usually shows it on the command prompt (For Windows users) * or the terminal (For *nix users).(Assuming it's open)

*/ private void calculate() { if ((this.input % 2) == 0) { JOptionPane.showMessageDialog(null, "Even"); } else { JOptionPane.showMessageDialog(null, "Odd"); } } } The import statement imports the JOptionPane class from the javax.swing package. The OddEven class declares a single private field of type int named input. Every instance of the OddEven class has its own copy of the input field. The private declaration means that no other class can access (read or write) the input field. OddEven() is a public constructor. Constructors have the same name as the enclosing class they are declared in, and unlike a method, have no return type. A constructor is used to initialize an object that is a newly created instance of the class. The calculate() method is declared without the static keyword. This means that the method is invoked using a specific instance of the OddEven class. (The reference used to invoke the method is passed as an undeclared parameter of type OddEven named this.) The method tests the expression input % 2 == 0 using the if keyword to see if the remainder of dividing the input field belonging to the instance of the class by two is zero. If this expression is true, then it prints Even; if this expression is false it prints Odd. (Theinput field can be equivalently accessed as this.input, which explicitly uses the undeclared this parameter.) OddEven number = new OddEven(); declares a local object reference variable in the main method named number. This variable can hold a reference to an object of typeOddEven. The declaration initializes number by first creating an instance of the OddEven class, using the new keyword and

the OddEven() constructor, and then assigning this instance to the variable. The statement number.showDialog(); calls the calculate method. The instance of OddEven object referenced by the number local variable is used to invoke the method and passed as the undeclared this parameter to the calculate method. input = Integer.parseInt(JOptionPane.showInputDialog("Please Enter A Number")); is a statement that converts the type of String to the primitive data typeint by using a utility function in the primitive wrapper class Integer. Special classes Applet Main article: Java applet Java applets are programs that are embedded in other applications, typically in a Web page displayed in a Web browser. // Hello.java import javax.swing.JApplet; import java.awt.Graphics;

public class Hello extends JApplet { public void paintComponent(final Graphics g) { g.drawString("Hello, world!", 65, 95); } } The import statements direct the Java compiler to include the javax.swing.JApplet and java.awt.Graphics classes in the compilation. The import statement allows these classes to be referenced in the source code using the simple class name (i.e. JApplet) instead of the fully qualified class name (i.e. javax.swing.JApplet). The Hello class extends (subclasses) the JApplet (Java Applet) class; the JApplet class provides the framework for the host application to display and control the lifecycle of the applet. The JApplet class is a JComponent

(Java Graphical Component) which provides the applet with the capability to display a graphical user interface (GUI) and respond to userevents. The Hello class overrides the paintComponent(Graphics) method (additionally indicated with the annotation, supported as of JDK 1.5, Override) inherited from theContainer superclass to provide the code to display the applet. The paintComponent() method is passed a Graphics object that contains the graphic context used to display the applet. The paintComponent() method calls the graphic context drawString(String, int, int) method to display the "Hello, world!" string at a pixel offset of (65, 95) from the upper-left corner in the applet's display. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!-- Hello.html --> <html> <head> <title>Hello World Applet</title> </head> <body> <applet code="Hello.class" width="200" height="200"> </applet> </body> </html> An applet is placed in an HTML document using the <applet> HTML element. The applet tag has three attributes set: code="Hello" specifies the name of the JApplet class andwidth="200" height="200" sets the pixel width and height of the applet. Applets may also be embedded in HTML using either the object or embed element,[35] although support for these elements by Web browsers is inconsistent.[36] However, the applet tag is deprecated, so the object tag is preferred where supported. The host application, typically a Web browser, instantiates the Hello applet and creates an AppletContext for the applet. Once the applet has initialized itself, it is added to the AWT display hierarchy.

The paintComponent() method is called by the AWT event dispatching thread whenever the display needs the applet to draw itself. Servlet Main article: Java Servlet Java Servlet technology provides Web developers with a simple, consistent mechanism for extending the functionality of a Web server and for accessing existing business systems. Servlets are server-side Java EE components that generate responses (typically HTML pages) to requests (typically HTTP requests) from clients. A servlet can almost be thought of as an applet that runs on the server sidewithout a face. // Hello.java import java.io.*; import javax.servlet.*;

public class Hello extends GenericServlet { public void service(final ServletResponse response) ServletRequest request,final

throws ServletException, IOException { response.setContentType("text/html"); final PrintWriter pw = response.getWriter(); try { pw.println("Hello, world!"); } finally { pw.close(); } } }

The import statements direct the Java compiler to include all of the public classes and interfaces from the java.io and javax.servlet packages in the compilation. The Hello class extends the GenericServlet class; the GenericServlet class provides the interface for the server to forward requests to the servlet and control the servlet's lifecycle. The Hello class overrides the service(ServletRequest, ServletResponse) method defined by the Servlet interface to provide the code for the service request handler. The service() method is passed a ServletRequest object that contains the request from the client and a ServletResponse object used to create the response returned to the client. The service() method declares that it throws the exceptions ServletException and IOException if a problem prevents it from responding to the request. The setContentType(String) method in the response object is called to set the MIME content type of the returned data to "text/html". The getWriter() method in the response returns a PrintWriter object that is used to write the data that is sent to the client. The println(String) method is called to write the "Hello, world!" string to the response and then the close() method is called to close the print writer, which causes the data that has been written to the stream to be returned to the client. JavaServer Pages Main article: JavaServer Pages JavaServer Pages (JSP) are server-side Java EE components that generate responses, typically HTML pages, to HTTP requests from clients. JSPs embed Java code in an HTML page by using the special delimiters <% and %>. A JSP is compiled to a Java servlet, a Java application in its own right, the first time it is accessed. After that, the generated servlet creates the response. Swing application Main article: Swing (Java) Swing is a graphical user interface library for the Java SE platform. It is possible to specify a different look and feel through the pluggable look and feel system of Swing. Clones ofWindows, GTK+ and Motif are supplied by Sun. Apple also provides an Aqua look and feel for Mac OS X. Where prior implementations of these looks and feels may have been considered lacking, Swing in Java SE 6 addresses this problem by using more native GUI widget drawing routines of the underlying platforms.

This example Swing application creates a single window with "Hello, world!" inside: // Hello.java (Java SE 5) import javax.swing.*;

public class Hello extends JFrame { public Hello() { super("hello"); super.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLO SE); super.add(new JLabel("Hello, world!")); super.pack(); super.setVisible(true); }

public static void main(final String[] args) { new Hello(); } } The first import includes all of the public classes and interfaces from the javax.swing package. The Hello class extends the JFrame class; the JFrame class a window with a title bar and a close control. implements

The Hello() constructor initializes the frame by first calling the superclass constructor, passing the parameter "hello", which is used as the window's title. It then calls thesetDefaultCloseOperation(int) method inherited from JFrame to set the default operation when the close control on the title bar is selected toWindowConstants.EXIT_ON_CLOSE this causes the JFrame to be disposed of when the frame is closed (as opposed to merely hidden), which allows the Java Virtual Machineto exit and the

program to terminate. Next, a JLabel is created for the string "Hello, world!" and the add(Component) method inherited from the Container superclass is called to add the label to the frame. The pack() method inherited from the Window superclass is called to size the window and lay out its contents. The main() method is called by the Java Virtual Machine when the program starts. It instantiates a new Hello frame and causes it to be displayed by calling thesetVisible(boolean) method inherited from the Component superclass with the boolean parameter true. Once the frame is displayed, exiting the main method does not cause the program to terminate because the AWT event dispatching thread remains active until all of the Swing top-level windows have been disposed. Class libraries The Java Class Library are the compiled bytecodes of source code developed by the JRE implementor to support application development in Java. Examples of these libraries are:

The core libraries, which include: Collection libraries that implement data structures such as lists, dictionaries, trees, sets, queues and double-ended queue, or stacks

XML Processing Security

(Parsing,

Transforming,

Validating)

libraries

Internationalization and localization libraries

The integration libraries, which allow the application writer to communicate with external systems. These libraries include:

The Java Database Connectivity (JDBC) API for database

access Java Naming and Directory Interface (JNDI) for lookup and discovery

RMI and CORBA for distributed application development JMX for managing and monitoring applications User interface libraries, which include:

The (heavyweight, or native) Abstract Window Toolkit (AWT), which provides GUI components, the means for laying out those components and the means for handling events from those components

The (lightweight) Swing libraries, which are built on AWT but provide (non-native) implementations of the AWT widgetry

APIs for audio capture, processing, and playback A platform dependent implementation of Java Virtual Machine that is the means by which the byte codes of the Java libraries and third party applications are executed Plugins, which enable applets to be run in Web browsers Java Web Start, which allows Java applications to be efficiently distributed to end-users across the Internet Licensing and documentation.

6. Analysis
6.1 System Design:
System design is transition from a user oriented document to programmers or data base personnel. 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.

6.1.1 Software Analysis:

In designing the software following principles are followed:
Modularity and partitioning: software is designed such that, each

system should consists of hierarchy of modules and serve to partition into separate function.
Coupling: modules should have little dependence on other modules

of a system.
Cohesion: modules should carry out in a single processing function. Shared use: avoid duplication by allowing a single module is called

by other that need the function it provides

6.2 Feasibility Study:

The next step in analysis is to verify the feasibility of the proposed system. All projects are feasible given unlimited resources and infinite time. But in reality both resources and time are scarce. Project should confirm to time bounce and should be optimal in there consumption of resources. This place a constant is approval of any project. Feasibility has applied to our project pertains to the following areas: Technical feasibility Operational feasibility Economical feasibility

6.2.1 Technical Feasibility:

To determine whether the proposed system is technically feasible, we should take into consideration the technical issues involved behind the system. Our project uses the web technologies, which is rampantly employed these days worldwide. The world without the internet is incomprehensible today. That goes to proposed system is technically feasible.

6.2.2 Operational Feasibility:

To determine the operational feasibility of the system we should take into consideration the awareness level of the users. This system is operational feasible since the users are familiar with the technologies and hence there is no need to gear up the personnel to use.

6.2.3 Economic Feasibility:

To decide whether a project is economically feasible, we have to consider various factors as: Cost benefit analysis Long-term returns

 Maintenance costs

The proposed

application is computer based. It requires average

computing capabilities and access to internet, which are very basic requirements hence it doesnt incur additional economic overheads, which renders the system economically feasible.

6.3 Diagrams: Use case:

do as directed in the input screen

get the list of all z contacts stored in your phone

display the list of contacts

user
choose a single/required contact from the list

apply selected contact to lockscreen using calls

Sequence:

phone application

database

user
1 . navigate activity screens

2 . display necessary information 3 . get the contact list 4 . query the database

5 . forward the list of contacts

6 . display the contact list

7 choose a contact 8 . request action 9 . apply selected contact to lock screen 10 . save any changes

phone application

database

user
1 . navigate activity screens

2 . display necessary information 3 . get the contact list 4 . query the database

5 . forward the list of contacts

6 . display the contact list

7 choose a contact 8 . request action 9 . apply selected contact to lock screen 10 . save any changes

11 . notify changes 12 . display changes

Activity:

navigate activity screens

get the contact list

Query using android API

display the contact list

choose a contact from the list

apply the selected contact to the lock screen

Class diagram:

Infosetup boolean debug: string tag: onCreate() onpreferenceClick()

Infoservice string tag: string nextAlarm: boolean debug: onReceive() onCreate()

lockscreenmonitor boolean debug: string tag: intentFilter() BroadcastReciever()

lockscreen string tag: Textview mHeadersim1: onKeydown() onfocus()

7. 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.

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. 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. Introducing errors and testing for error handling.

TEST CASES
Test case 1: Random Function Priority (H, L): High

Test Objective: To Verify the efficiency of Random Function Test Description: To check whether the keys are randomized without any specific pattern such that the position of a particular key cannot be predicted to obtain its next location. Requirements Verified: Yes

Actions
The user credentials will provide

Expected Results
authentication Keys should be randomized every time without any specific pattern Conditions pass: Yes Fail: No

Pass: Yes Problems / Issues: NIL Notes: Successfully Executed

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.

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",

7. Android
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 WebKit engine Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional) SQLite for structured data storage Media support for common audio, video, and 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 plugin for the Eclipse IDE

7.3 Android application

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 PacketVideo's OpenCORE; 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 LibWebCore - 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 FreeType - bitmap and vector font rendering 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 plugin. To do so, follow the steps given in Installing the ADT Plugin.

7.6 Developing in eclipse with ADT:

The Android Development Tools (ADT) plugin 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 plugin 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, manage port-forwarding, set breakpoints, and view thread and process informationd irectly 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 plugin 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 your 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. 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. 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 applicaiton.

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 AVDsread 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. 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 plugin 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:

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:

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 objectoriented 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 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 StringBuffer 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: 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(); 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 HashMap 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.

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: 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: 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 initializers, 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 subclass, 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 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 inmemory 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: 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 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 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. 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:

Dont Drop Data:

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 onPause() 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 behavior 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.

Dont 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.

Dont 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. 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.

Dont over load a single activity screen:

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 drawables are flexible enough to display properly on a variety of device screens. 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.

Dont assume touchscreen 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. 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.

9. Output Screens

10. CONCLUSION

Contact Owner is a very simple application that serves a sole purpose. With that being said it's an important application if your phone
is your lifeline and you want to ensure that at least the possibility of getting it returned if it's lost is a possibility.

11. BIBLIOGRAPHY

SOFTWARE ENGINEERING
By Roger.S.Pressman

JAVA HOW TO PROGRAM

By Dietel & Dietel

Android
http://developer.android.com/index.html