CompuServe - a complaint portal

A PROJECT REPORT

Submitted by
Deepak Kumar Agrawal 1201326137

Debdeep Ganguly 1201326127

Amit Kumar Sinha 1201326120

Neha Kumari 1201326403

Lucy Kumari 1201326135

in partial fulfilment for the award of the degree

1
 of

BACHELOR OF TECHNOLOGY

In

COMPUTER SCIENCE AND ENGINEERING

GANDHI INSTITUTE FOR EDUCATION AND TECHNOLOGY

BHUBANESWAR

BIJU PATNAIK UNIVERSITY OF TECHNOLOGY, ODISHA

BIJU PATNAIK UNIVERSITY OF TECHNOLOGY: ODISHA

BONAFIDE CERTIFICATE

Certified that this project report “CompuServe”

Is the bonafide work of “Debdeep Ganguly” who carried out the project work under my
supervision.

2
 SIGNATURE SIGNATURE SIGNATURE

Prof. Sambit Kumar Mishra Prof. Nilamadhab Mishra Prof. Smaranika

Mahapatra

HEAD OF THE DEPARTMENT COORDINATOR PROJECT GUIDE

Department of Computer science & Engg.

Gandhi Institute for Education & Technology

Baniatangi, Khurda, Bhubaneswar

www.gietbbsr.com

CERTIFICATE OF EVALUATION

COLLEGE NAME: GANDHI INSTITUTE FOR EDUCATION & TECHNOLOGY

BRANCH: COMPUTER SCIENCE AND ENGINEERING

SEMESTER: 8TH

SL.NO Registration no. Name of the Student Title of the

project
The report
of the 1 1201326137 Deepak Kumar Agrawal CompuServe project
is
2 1201326127 Debdeep Ganguly CompuServe

3 1201326120 Amit Kumar Sinha CompuServe

Neha Kumari CompuServe

4 1201326403
3Lucy Kumari CompuServe
5 1201326135
 submitted by the above student in partial fulfillment for the awards of Bachelor of Technology in
Computer Science and Engineering, Biju Pattnaik University of Technology are evaluated and
confirmed to the reports of the work done.

Submitted for the University Examination held on 10th May 2016

INTERNAL EXAMINER EXTERNAL EXAMINER

ACKNOWLEDGEMENT
It is our pleasure to be indebted to various people, who directly or indirectly
contributed in the development of this work and who influenced our thinking,
behavior and acts during the course of study.

First of all, we like to thank, Prof. Smaranika Mohapatra, Internal guide,

Department of Computer Science & Engineering, who guided us to complete this
project.

We also take this opportunity to express a deep sense of gratitude to Prof. J P

Mishra, Vice-Chairman, Prof.(Dr.) B Pradhan, Director, Prof.(Dr.) Niranjan Sutar,
Principal, Prof.(Dr.) Binayak Sahu, Vice-Principal, GIET, Baniatangi, Bhubaneswar,
for his/her cordial support, valuable information and guidance, which helped us in
completing this task through various stages.

We wish to express our profound and sincere gratitude to Prof. Nilamadhab

Mishra, Project coordinator, Department of Computer Science & Engineering, who
guided us into the intricacies of this project nonchalantly with matchless
magnanimity.

We are thankful to Prof. Sambit Kumar Mishra, Head of the Dept. of

Computer Science & Engineering, for his support, cooperation, and motivation
provided to us during the training for constant inspiration, presence and blessings.

4
 We also extend our sincere appreciation to Faculty members who provided
valuable suggestions and precious time in accomplishing my minor project report.

Lastly, we would like to thank the almighty and our parents for their moral
support and friends with whom we shared our day-to-day experiences and received
lots of suggestions those improved the quality of work.

Deepak Kumar Agrawal 1201326137

Debdeep Ganguly 1201326127
Amit Kumar Sinha 1201326120
Neha Kumari 1201326403
Lucy Kumari 1201326135

ABSTRACT

The era of mobile technology opens the windows to the android app. The websites are
vanishing and the mobile phones are emerging. It’s the time to change from
conventional websites to apps, which has become the part of our daily routine. We
are introducing “Compuserve.apk” - the android application software which would be
a miniature of a customer service support portal. It works as a service based
customer management software. This app could be made in use with contractual
basis for serving a single vendor. It has been successful in implementing the purpose
of using apps on smartphones to fulfil the basic needs of life. Like for example this
app helps any smartphone user to opt for a maintenance service for complaints
registered. Instead of approaching the tech-support or any mobile service-shop, the
user simply gets his/her complaint serviced within a short period of time, through the
app. The main interface contains 4 options -Service, Devices, Help and Contact. As a
dummy app, it shows a message notification feedback on the user’s device whenever
he/she opts in for a service. This project could also easily be implemented within a
closed group with a local administrator handling requests through a local/private
server. The target level API for this app is Android Kitkat v4.4 but can also support
lower level API’s upto 8 a.k.a Gingerbread. JSON framework has been implemented
along with MySQL database. For validation at server side, PHP has been used.
Interface is very lucid and clear with simple interactive menu items. Usage is hassle-
free. project has been performed under the guidance of Prof. Smaranika Mahapatra,
5
Prof. Santosh Rath. They have been of a lot of help and support for its successful
completion. This project ensures on 3U aspects – Understandable, Utilizable and
Usable. Easy to understand, easy to implement.

Table of contents
1. INTRODUCTION
1.1 PURPOSE:
1.2 SCOPE:
2. SOFTWARE REQUIREMENTS SPECIFICATION
2.1 MOBILE APPLICATION:
3. DESIGN AND IMPLEMENTATION
3.1. ASSUMPTIONS AND DEPENDENCIES:
3.2. CONSTRAINTS:
3.3. DESIGN DETAILS:
4. TECHNICAL DETAILS
4.1. TECHNOLOGIES USED:
4.2. PROBLEMS FACED:
5. IMPLEMENTATION,TESTING & MAINTENANCE
5.1 JAVA:
5.2. ANDROID DEVELOPMENT TOOLS:
5.3. SECURITY AND PERMISSION CONCEPT IN ANDROID:
5.4. CODING STANDARDS OF LANGUAGE USED:

6. LESSONS LEARNED
5.1 IMPORTANCE OF RESEARCH:
5.2. TEAM WORK:
6
 5.3. TIME MANAGEMENT:
7. ACTIVITY FLOW- USE CASE, DFD’S & CLASS DIAGRAMS
8. SCREENSHOTS, DATA DICTIONARIES
9. CODE WORK
10. CONCLUSIONS AND FUTURE SCOPE
11. REFERENCES
12. MAJOR TASKS & CONTRIBUTIONS

7
1. Introduction

The android operating system is basically an operating system for mobiles. It is

mobile operating system that uses a modified version of the Linux kernel 2.6. Google
developed Android as part of the Open Handset Alliance, a group of more than 30
mobile and technology companies working to open up the mobile handset
environment. In this, it will be described that how security can be improving of
Android Operating System so that users can safely use the android smart phones.
Keywords: -Android history, architecture and security

HISTORY OF ANDROID:
Android Inc. Founded in Palo Alto, California, united states in October 2003 by Andy
Rubin [co-founder of danger], rich miner [co-founder of wildfire communication Inc.],
nick sears [once VP at T-Mobile], and Chris white [headed design and interface
development at web TV] to develop.

WHAT IS ANDROID:

It is an open source software platform and operating system for mobile devices Based
on the Linux kernel. Developed by Google and later the Open Handset Alliance (OHA).
Allows writing managed code in the Java language.

8
Android has its own virtual machine i.e. DVM (Dalvik Virtual Machine), which is used
for executing the android application.  Android is a free downloadable open source
software stack for mobile devices that include an Operating system.

Android os is developed under code name based on dessert items.

OPEN HANDSET ALLIANCE:

The open handset alliance (OHA) is a business alliance of firm to develop open
standard for mobile devices.

Devoted to advancing open standards for mobile devices

Develop technologies that will significantly lower the cost of developing and
distributing mobile devices and services.

ANDROID VERSION:
 Android 1.0 (Angel Cake)-The first version of the open source software was
released back in 2008.

 Android 1.1(Battenberg)-In Feb 2009, version 1.1

 Android 1.5 (Cupcake)-Launched in April 2009

 Android 1.6 (Donut)-released in September 2009

 Android 2.0/ 2.1 (Éclair)-released in 26th October 2009 and January 2010

 Android 2.2 (Froyo) –frozen yoghurt - Released in the summer of 2010

 Android 2.3 (Gingerbread) - Gingerbread landed by the end of 2010

9
  Android 3.0(Honeycomb) - For the first time Google released a software that
was totally focused on tablets. This version, released in July/august 2011

 Android 4.0 (Ice Cream Sandwich 4.0)-released in October 2011

 Android 4.1 (jelly bean4.1) -released in 26th June 2012

 Android 4.4 (KitKat) - released on October 2013.

 Android 5.1 (Lollipop) – released and working stable now.

After so many desserts named version of android is going to offer something with
even tastier desserts and sweet dishes.

ANDROID ARCHITECTURE:
10
The software stack is split into Four Layers:

• The application layer

• The application framework

• The libraries and runtime

• The kernel

11
LINUX KERNEL:
•The architecture is based on the Linux2.6 kernel.

• This layer is core of android architecture. It provides service like power

management, memory management, security etc.

It helps in software or hardware binding for better communication.

NATIVE LIBRARIES:
Android has its own libraries, which is written in C/C++. These libraries cannot be
accessed directly. With the help of application framework, we can access these
libraries. There are

many libraries like web libraries to access web browsers, libraries for android and
video formats etc.

ANDROID RUN TIME:

12
Dalvik virtual machine- The Android Runtime was designed specifically for Android to
meet the needs of running in an embedded environment where you have limited
battery, limited memory, limited CPU. Dalvik is the process virtual machine in
Google's android operating system. It is the software that runs the apps on android
devices. Dalvik is thus an integral part of android, which is typically used on mobile
devices such as mobile phones and tablet computers.  Programs are commonly
written in java and compiled to byte code.

CORE LIBRARIES-

•The core library contains all of the collection classes, utilities, IO, all the utilities and
tools that you’ve come to expected to use.

13
APPLICATION FRAMEWORK:

This is all written in a Java programming language and the application framework is
the toolkit that all applications use.

•These applications include the ones that come with a phone like the home
applications, or the phone application.

•It includes applications written by Google, and it includes apps that will be written by
you.

•So, all apps use the same framework and the same APIs.

14
These are as follows:

• Activity manager:-It manages the lifecycle of applications. It enables proper

management of all the activities. All the activities are controlled by activity manager.

• Resource manager:-It provides access to non-code resources such as graphics etc.

• Notification manager:-It enables all applications to display custom alerts in status

bar.

• Location manager:-It fires alerts when user enters or leaves a specified

geographical location.

• Package manager:-It is use to retrieve the data about installed packages on device.

• Window manager:-It is use to create views and layouts.

• Telephony manager:-It is use to handle settings of network connection and all

information about services on device.

APPLICATION LAYER: -

15
The final layer on top is Applications.

• It includes the home application, the contacts application, the browser, and apps.

• It is the most upper layer in android architecture.

• All the applications like camera, Google maps, browser, sms, calendars, contact
share native applications. These applications work with end user with the help of
application framework to operate.

SECURITY:

16
 Android is a multi-process system, in which each application (and parts of the
system) runs in its own process. Most security between applications and the system is
enforced at the process level through standard Linux facilities, such as user and group
IDs that are assigned to applications. Android is designed having multi-layer security
which provides flexibility for this platform. When attackers attempt attack on device,
android platform helps to reduce the portability of the attack. There are key
components of android security which are described as follows:

Design review: - when a security model is designed then it will be reviewed by the
developers so that risk level will be very less while using the model.  Code review
and penetrating testing: -the goal of this code review is that in which it will be
checked that how the system will become strong?

Open source and community review: - android uses open source technologies
that have significant external review such as Linux kernel.  Incident response:
-android team enables the rapid mitigation of vulnerabilities to ensure that potential
risks to all android users are minimized.

FEATURES OF ANDROID:

Background Wi-Fi location still runs even when Wi-Fi is turned off.

Developer logging and analyzing enhancements

It is optimized for mobile devices.

17
It enables reuse and replacement of components.

Java support, media support, multi touch, video calling, multi-tasking, voice based
features, screen capture, camera, Bluetooth, gps, compass and accelerometer,3G,4G.

ADVANTAGES:
• The ability for anyone to customize the Google Android platform

• It gives you better notification.

• It lets you choose your hardware.

• It has better app market (1,80,000 application)

• A more mature platform

• With the support of many applications, the user can change the screen display.

• With Google chrome you can open many windows at once.

• Supports all Google services: Android operating system supports all of Google
services ranging from Gmail to Google reader. All Google services can you have with
one operating system, namely Android.

DISADVANTAGES:
Android Market is less control of the manager, sometimes there are malware.
Wasteful Batteries, this is because the OS is a lot of "process" in the background
causing the battery quickly drains. Sometimes slow device company issued an

18
official version of Android your own. Extremely inconsistence in design among apps.
 Very unstable and often hang or crash.

LIMITATIONS OF ANDROID:

Development requirements in

• Java

• Android SDK

• Bluetooth limitations:

Android doesn't support:

 Bluetooth stereo.
 Contacts exchange.
 Modem pairing.
 Wireless keyboards
 Photoshop mobile isn't coming to android because of android limitations.
 Apps Android Market need to be programmed with a custom form of Java There
are no split or interval times available.
 Small memory size.
 Continuous Internet connection is required

1.1 PURPOSE:

This project uses the Google Android platform to build an application where
customers needing a service can announce the required service and customer device
service provider can quickly identify the opportunity and contact the customer. The
overall concept is where a customer would announce the required service (i.e. –
needs plumbing services to unclog a drain in the house, etc.) through the mobile app.
A service provider sitting at the server side, could open and see all customers
needing the service. The application will take all the customer details like address,
contact number, zip code, service type and service description where the service
provider could get extra information about the problem and then with a click initiate a
call or send a message to the customer and discuss the possibilities of providing the
service.

19
1.2 SCOPE:

CompuServe is a connecting platform for service providers and the service seekers to
communicate with each other. The main domains are the Web server and the Mobile
application. The service providers shall use their own web servers hosted in private
domains in order to view the problems, which were faced by the customers. This
application benefits both the service providers and seekers so that the problems can
be addressed quickly and accounts for a friendly relationship between both the
groups.

2. SOFTWARE REQUIREMENTS SPECIFICATION

 This section explains about the individual functionality and requirements of two

major sections Mobile Application

 Web server

These requirements are identified from the sequence diagrams that are drawn to
identify the flow of these two applications and the communication between them.

Hardware Requirements
20
Processor : Above 2.8ghz
RAM : 2 GB
OS : Windows / Linux/ MAC

Input device : Standard keyboard and mouse

Output device : VGA and high resolution monitor
HDD Space : 10 GB

Software Requirements

OS : Android
User Interface : XML
Programming Lang : JAVA

Tool : Eclipse with ADT plugin / Android Studio

Database : MySQL
Database setup & server : XAMPP server
Framework : JSON

21
2.1 MOBILE APPLICATION:
Application requires customers for User Name and password if they already have
opted for a service earlier or the user can newly register him/herself as a service
seeker. This type of user can have problems he receives a response from the service
provider using an android mobile phone through on screen notifications or sms. After
the service seeker logs in he/she should be able to see the following links

1. Request Service

2. Post a problem – Service seeker is allowed to post a problem

3. History- Problems posted till date and information related to it shall be seen

4. Help/Contact – Shall write about any suggestions or query on a service provider

5. App description.

2.2.1 Registration
Each user must fill all the fields and get registered through the application and later
he is sent an e-mail/otp code to the phone to verify his identity. As soon as he/she
clicks the link that is sent to his e-mail/confirms the numbers in the otp page then
he/she is redirected to their profile page where they are given access to take
advantage of the application according to the user type.

2.2.2 Managing User Accounts:

This section explains the functionality of the user accounts that is provided after
registration according to the user type.

22
2.2.2.1 Company Admin

User who created the company profile will have the admin rights. The admin shall

have the rights to view the customer requests, the details of all customers registered,

through a web server. This functionality could also be tested on a local server.

1. View – Customer queries, the type of service they need.

2. View – Customer details like address, contact number.

3. Organize requests – They can delete old and outdated requests that no

longer need attention or prioritize them.

4. View – See the type of requests customer needs.

5. Notify customers – They can send notifications to customers through sms

about the status of service.

6. History – All the work done by them till date shall be seen

3.DESIGN and IMPLEMENTATION

3.1. ASSUMPTIONS and DEPENDENCIES:

1. The Mobile Application is dependent on the Web server because the mobile

application cannot work without the data from the server and vice versa.

23
 2. The default settings on the mobile application will reflect on the server side.

Settings such as frequently used zip code and the mobile number can be made
default or primary means of identifying customers, thereby providing an easy
way for the service provider.

3. Each Service provider having their own private web servers.

Every service seeker using this application shall possess a smart phone with
Android Operating system on top of it.

3.2. CONSTRAINTS:
1. Huge data shall not be stored on the mobile phone. Whatever history about

service work has been done is fetched from web. As a matter of fact, the mobile

phone consists of limited memory and storing excess information is not at all a

good design.

2. User of the mobile should have internet access. The Service provider should

have the internet access in order to retrieve the service seeker’s information.

Whenever he/she updates his/her profile over the mobile, the changes should be

synchronized with the server.

3.3. DESIGN DETAILS:

The design details include the following

1. Static structure
24
 2. Behavior

3. User Interface

4. Components

These design details are individually given for both web application and mobile
application.

3.3.1. Web Server

3.3.1.1 Static Structure

The static structures of the web application represent the class diagram and for the
class diagram refer diagrams.

3.3.1.2 Behavior

The behavior of the web server explains you the various actions and the flow of it. For
the behavior refer diagrams.

3.3.1.3 User Interface

The user interface is one of the major things on the web application end, since many
users come to a conclusion on the standards and services of the application by
looking at it. Having a good UI is very important.

For the user interface please refer diagrams.

3.3.1.4 Components

This describes a class that includes the attributes and methods. It also says the
exceptions that may rise on the web application part. For a detailed description refer
diagrams.

25
3.3.2. Mobile Application
This part explains the behavior and design details of the mobile application. For

the class diagram and design details refer diagrams.

4. TECHNICAL Details
4.1. TECHNOLOGIES USED:
This section focuses on technologies used in Web interface and Mobile Interface.

4.1.1. JAVA:
As the android platform understands Java the application was built on it.

4.1.2. XML:
XML is a simple, very flexible text format which was designed to carry data, not to
display data.

4.1.3. MySQL Server:

MySQL is a simple database management system (DBMS). In our application, to
store and to retrieve the data from the database we use this technology. It is used for
both Web and mobile application.

26
4.1.4. Android:
The Android platform is a software stack for mobile devices including an operating
system, middleware and key applications. 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.
Developers can create applications for the platform using the Android SDK.
Applications are written using the Java programming language and run on Dalvik, a
custom virtual machine designed for embedded use, which runs on top of a Linux
kernel.

4.2. PROBLEMS FACED:

• Effect of inadequate practical platform support

• MYSQL connectivity with local server

• No availability of “free” private web server for hosting the app online

• Thereby testing the app on full functional basis was impossible

• Thus we had to cut down many features as possible

• External Database connection

• Deprecated RESTful API

• Drawing overlays

• Integrating the Web client and the android client

27
 5. IMPLEMENTATIONS, TESTING & MAINTENANCE

5.1 JAVA

Java is a very popular programming language developed by Sun Microsystems (now

owned by Oracle). Developed long after C and C++, Java incorporates many of the

powerful features of those powerful languages while addressing some of their

drawbacks. Still, programming languages are only as powerful as their libraries. These

libraries exist to help developers build applications. Some of the Javas important core

features are:

• Its easy to learn and understand.

• Its designed to be platform-independent and secure, using virtual machines.

• Its object-oriented.

Android relies heavily on these Java fundamentals. The Android SDK includes many

standard Java libraries (data structure libraries, math libraries, graphics libraries,

28
networking libraries and everything else you could want) as well as special Android

libraries that will help you develop awesome Android applications. Platform

Independence Importance with many programming languages, you need to use a

compiler to reduce your code down into machine language that the device can

understand. While this is well and good, different devices use different machine

languages. This means that you might need to compile your applications for each

different device or machine language in other words, your code isn’t very portable.

This is not the case with Java. The Java compilers convert your code from human

readable Java source files to something called bytecode in the 42 Java world. These

are interpreted by a Java Virtual Machine, which operates much like a physical CPU

might operate on machine code, to actually execute the compiled code. Although it

might seem like this is inefficient, much effort has been put into making this process

very fast and efficient. These efforts have paid off in that Java performance in

generally second only to C/C++ in common language performance comparisons.

Android applications run in a special virtual machine called the Dalvik VM. While the

details of this VM are unimportant to the average developer, it can be helpful to think

of the Dalvik VM as a bubble in which your Android application runs, allowing you to

not have to worry about whether the device is a Motorola Droid, an HTC Evo, or the

latest toaster running Android. You don’t care so long as the device is Dalvik VM

friendly and that’s the device manufacturers job to implement, not yours.

Why is Java Secure?

29
Let’s take this bubble idea a bit further. Because Java applications run within the

bubble that is a virtual machine, they are isolated from the underlying device

hardware. Therefore, a virtual machine can encapsulate, contain, and manage code

execution in a safe manner compared to languages that operate in machine code

directly. The Android platform takes things a step further. Each Android application

runs on the (Linux- based) operating system using a different user account and in its

own instance of the Dalvik VM. Android applications are closely monitored by the

operating system and shut down if they don’t play nice (e.g. use too much processing

power, become unresponsive, waste resources, etc.). Therefore, it’s important to

develop applications that are stable and responsive. Applications can communicate

with one another using well- defined protocol.

5.2 ANDROID DEVELOPMENT TOOLS

• Android SDK:

The Android Software Development Kit (Android SDK) contains the necessary tools to

create, compile and package Android applications. Most of these tools are command

line based. The primary way to develop Android applications is based on the Java

programming language.

• Android debug bridge (adb):

30
The Android SDK contains the Android debug bridge (adb), which is a tool that allows

you to connect to a virtual or real Android device, for the purpose of managing the

device or debugging your application.

• Android Developer Tools and Android Studio:

Google provides two integrated development environments (IDEs) to develop new

applications. The Android Developer Tools (ADT) are based on the Eclipse IDE. ADT is

a set of components (plugins), which extend the Eclipse IDE with Android

development capabilities. Google also supports an IDE called Android Studio for

creating Android applications. This IDE is based on the IntelliJ IDE.

Both IDEs contain all required functionality to create, compile, debug and deploy

Android applications. They also allow the developer to create and start virtual Android

devices for testing. Both tools provide specialized editors for Android specific files.

Most of Android’s configuration files are based on XML. In this case these editors allow

you to switch between the XML representation of the file and a structured user

interface for entering the data. Dalvik Virtual Machine the Android system uses a

special virtual machine, i.e., the Dalvik Virtual Machine (Dalvik) to run Java based

applications. Dalvik uses a custom bytecode format which is different from Java

bytecode.

Therefore, you cannot run Java class files on Android directly; they need to be

converted into the Dalvik bytecode format.

31
• Android Run Time (ART):

With Android 4.4, Google introduced the Android RunTime (ART) as optional runtime

for Android 4.4. It is expected that versions after 4.4 will use ART as default runtime.

ART uses Ahead of Time compilation. During the deployment process of an application

on an Android device, the application code is translated into machine code. This

results in approx. 30% larger compile code, but allows faster execution from the

beginning of the application.

5.3 SECURITY AND PERMISSION CONCEPT IN ANDROID

Security Concept in Android:

The Android system installs every Android application with a unique user and group

ID. Each application file is private to this generated user, e.g., other applications

cannot access these files. In addition, each Android application is started in its own

process.

Therefore, by means of the underlying Linux kernel, every Android application is

isolated from 44 other running applications. If data should be shared, the application

32
must do this explicitly via an Android component which handles the sharing of the

data, e.g., via a service or a content provider.

• Permission concept in Android:

Android contains a permission system and predefines permissions for certain tasks.

Every application can request required permissions and also define new permissions.

For example, an application may declare that it requires access to the Internet.

Permissions have different levels. Some permissions are automatically granted by the

Android system; some are automatically rejected. In most cases the requested

permissions are presented to the user before installing the application. The user

needs to decide if these permissions shall be given to the application.

If the user denies a required permission, the related application cannot be installed.

The check of the permission is only performed during installation; permissions cannot

be denied or granted after the installation.

An Android application declares the required permissions in itsAndroidManifest.xml

configuration file. It can also define additional permissions which it can use to restrict

access to certain components.

33
5.4 Coding Standards of Language Used

Coding Standards of Java are used in the whole project. This standard includes the

following: • No wildcard imports.

• Overloads appear sequentially.

• Braces are used even when the body is empty or contains a single statement.

• Two space indentation. • Column limit can be 80 or 100 characters.

• No C-style array declarations.

• Default statements required in switch statements.

• Modifiers appear in the order recommended by the Java Language Specification.

• Constants use CONSTANT CASE. Note that every constant is a static final field, but

not all static final fields are constants.

• Class name should start with uppercase letter.

• Function name should start with lowercase letter.

34
6.Lessons Learned

5.1 IMPORTANCE OF RESEARCH:

We have used few technologies in our project, among them Android operating system
is very important as our final application should run on this platform. We have spent
many days learning Android as it was a new technology. Our application will be
successfully built on this as we were able to use many built-in features of Android.

5.2. TEAM WORK:

By the end of this project we will end up as an effective and coordinating team
as we understood the importance of the team work by the guidance of our mentor.
Our team is a good combination of challenging and hardworking people. Throughout
this project we have learnt a lot about team coordination, planning, presentation and
developing personal attitude towards teamwork.

5.3. TIME MANAGEMENT:

To become successful, one must have good time management as it is
considered as one of the important quality in the current competitive world. Keeping
our mentor suggestions in mind we were able to implement and manage things in
time. Meeting the various deadlines set by the instructor was tough and gave us a
valuable experience of how to effectively manage time and as well the mentor’s
expectations were sometimes very challenging and finally our project timeline was
nearly accurate and we were following that from the initial stages onwards.

35
7. ACTIVITY FLOW – USE CASES, DFD’S, CLASS

DIAGRAM:

USE CASE CHARTS

For Home Screen:

36
For Menu Items:

For Post Service Menu/ Service Menu:

37
DFD’S

Level -0 DFD:
This is the overall systems structure in which all the entities of the app based system
and their functions with the app are shown. The user directly interacts with the app
whereas the admin only gets the complaints at the server side.

38
Level -1 DFD:

39
Level -2 DFD:

40
Class diagram:

41
8. SCREENSHOTS:

42
43
44
45
DATA DICTIONARY:

Table name: User complain

46
Table name: User’s table

47
9. CODE WORK

CODE SNIPPET FOR FirstPage.java file:

48
49
The respective xml file is

50
Java file for complaint page

Respective XML file

51
Java file for automaticEmailActivity page

Parsing content into JSON

App development were done using both IDE’s – Android Studio

and Eclipse

52
53
54
10. CONCLUSION AND FUTURE SCOPE

Future Scope
The future scope of the project is that it can be used as any news giving application
or it can be used to advertise your products, telling the customers about new
schemes and products coming to your shop. This application of CompuServe can be
further extended to include the following features:

1. Categorization of Service: Services can be categorized in different categories, so

that its possible for user to easily manage the selection categories. Categorization
can also be done by making groups. Defining the service pertaining to be the part of
particular group can make it more secure.

2. Image files: The attachments can be further improved to include image or video
files. Then there will not be much need to send images with the notification. A single
file would serve all the purposes and help the service persons serve better.

3. Feedback: Feedback on the services can also be taken. It can increase

communication among connected members and any issue can be easily sorted out on
the spot.

Conclusion I learned a lot by doing this project.

So during this project I learned all the above things. Before this project, I had no idea
about Java and Android for making application. Although I had little bit knowledge of
Ubuntu before. But now I learned a lot about Ubuntu and got knowledge of using
Android and Java for developing mobile application and PHP for server side scripting.
Now I prefer to work on command line rather than graphically. I learned how to work
on shell script. If I talk about the project, CompuServe application has reduced lot of
manual work. It has made notifying each and every user very easy and that too with
no time and place restrictions.

55
11. REFERENCES

1. Learn Android, http://code.google.com/android/

2. MySQL, http://www.mysql.com/

3. XML, http://www.w3schools.com/xml/default.asp

4. XML, http://www.tizag.com/xmlTutorial/

5. Android forum, http://www.anddev.org/

6. http://developer.android.com

7. https://github.com

8. StackOverflow.

56
12. MAJOR TASKS & CONTRIBUTIONS

First of all, the faculties of our department were very cooperative during the project.
Without their guidance, it would have been impossible.

Team Leadership
 Deepak Kumar Agrawal (60%) – Meeting agendas, meeting minutes, task

assignment coordination, coordinated communication with mentor and

professor, communicated with System Administrator

 Amit Kumar Sinha (20%) – Meeting discussion, meeting minutes

 Neha Kumari (10%) – Meeting discussion, meeting minutes

 Lucy Kumari (10%) – Meeting discussion, meeting minutes

Database Design and Implementation

 Deepak Kumar Agrawal (45%) – Designed database draft, ER diagram,

Implemented database.

 Debdeep Ganguly (30%) – contributed to database design decisions

 Amit Kumar Sinha (15%) – contributed to database design decisions

 Lucy Kumari 10%) – contributed to database design

Prototype Design and Implementation

 Deepak Kumar Agrawal (25%) – DBA, ER Diagram, Web server maintenance

57
 and support Android Developer

 Debdeep Ganguly (25%) – Core Application Developer and support server

 Neha Kumari (25%) – Sequence Diagrams and Core Android Developer.

 Lucy Kumari (25%) – Class Diagram, Use case Diagram and support Android

Developer.

Documentation
 Deepak Kumar Agrawal (35%) –Presentation Slides, Requirements

Documents and Final report.

 Amit Kumar Sinha (35%) – Drafted Requirements document, Drafted Design

document and drafted Final Report

 Neha Kumari (15%) – Initiated Requirements Document

 Lucy Kumari (15%) – Drafted Requirements Document

58