DONOR CATCHER USING VoIP

PROJECT REPORT

Submitted by
KADHIRESHAN.S

Register No.: 11TD0455

SHANMOUGAPRIYAN.V

Register No.: 11TD0523

HARIHARAN.R

Register No.: 11TD0440

Under the guidance of

Mr. M. SHANMUGAM
in partial fulfillment of the requirements for the degree
of
BACHELOR OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

MADAGADIPET, PUDUCHERRY-605107
APRIL 2013

SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

PONDICHERRY UNIVERSITY
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

BONAFIDE CERTIFICATE

This is to certify that the project work entitled DONOR CATCHER USING VOIP is a
bonafide

work

done

by

KADHIRESHAN.S

[REGISTER

NO.:11TD0455],

SHANMOUGAPRIYAN.V [REGISTER NO.:11TD0], HARIHARAN.R [REGISTER

NO.:11TD04] in partial fulfillment of the requirement, for the award of B.Tech Degree in
Computer Science and Engineering by Pondicherry University during the academic year 20122013.

PROJECT GUIDE

HEAD OF THE DEPARTMENT

Submitted for the University Examination held on ..

INTERNAL EXAMINER

EXTERNAL EXAMINER

ACKNOWLEDGEMENT

We are very thankful and grateful to our beloved guide, Mr. M. SHANMUGAM whose
great support in valuable advices, suggestions and tremendous help enabled us in completing our
project. He has been a great source of inspiration to us.

We also sincerely thank our Head of the Department, Mr. K. PREMKUMAR whose
continuous encouragement and sufficient comments enabled us to complete our project report.
We thank all our Staff Members who have been by our side always and helped us with
our project. We also sincerely thank all the lab technicians for their help as in the course of our
project development.
We would also like to extend our sincere gratitude and grateful thanks to our Director
cum Principal, Dr. V. S. K. VENKATACHALAPATHY for having extended the Research and
Development facilities of the department.
We are grateful to our Founder Chairman Mr. N. KESAVAN. He has been a constant
source of inspiration right from the beginning.
We would like to express our faithful and grateful thanks to our Chairman & Managing
Director, Mr. M. DHANASEKARAN for his support.
We would also like to thank our Vice Chairman Mr. S. V. SUGUMARAN, for providing
us with pleasant learning environment.
We wish to thank our Family Members and Friends for their constant encouragement,
constructive criticisms and suggestions that has helped us in timely completion of this project.
Last but not the least; we would like to thank the ALMIGHTY for His grace and
blessings over us throughout the project.

ABSTRACT
Emergency situations, such as automobile or other accidents, create an immediate, critical need
for specific blood types. In mass-casualty emergencies, such as the 2006 Mumbai train blasts, the
spike in need can result in scarcities that force government authorities to ask all healthy
individuals capable of donating blood to do so. In addition to emergency requirements, advances
in medicine have increased the need for blood in many ongoing treatments and elective surgeries.
To help meet demand, Indian citizens have created Web sites to match blood donors and
recipients. Donors register themselves on the sites, specifying their blood types and contact
information; requesters do the same, specifying when they need what blood type. Sometimes
requesters must specify months in advance of elective treatments because of donation shortages.
Two problems arise with this Web based approach to blood distribution. First, it doesnt address
immediate emergency requirements. Second, in a country like India, many people lack access to
Internet facilities. Cell phones, however, are becoming ubiquitous in emerging. In India, smart
phones are more common than PDAs and computers, simply because theyre more affordable.
So, we are having a Smart phone application to search donor and also to register as a donor. And
we have a new system, when a users call to our server, It will respond a IVR message, asking the
language, blood group and the location via DTMF tones and redirects the call to the donor. So
any user at any situation using any mobile he can get the donor.

iv

LIST OF TABLES
TABLE NO.

NAME OF THE TABLE

PAGE NO.

1.1

DTMF keypad frequencies

LIST OF FIGURES
FIGURE NO.

NAME OF THE FIGURE

3.1

Functioning of Eligible donor finding Algorithm

4.1

Use case diagram of donor catcher system

4.2
4.3
4.4
4.5

Activity diagram of donor catcher system

Class diagram of donor catcher system
Component diagram of donor catcher system
Deployment diagram of donor catcher system

vi

LIST OF ABBREVIATIONS

PAGE NO.
6

DTMF

Dual Tone Multi Frequency

IVR

Interactive Voice Response

VoIP

Voice over Internet Protocol

vii

TABLE OF CONTENTS

CHAPTER NO.

1.

2.

TITLE

PAGE NO.

ABSTRACT

iv

LIST OF TABLES

LIST OF FIGURES

vi

LIST OF ABBREVIATIONS

vii

INTRODUCTION

1.1 COMMUNICATION TECHNOLOGY

1.2 TECHNOLOGIES USED

1.2.1 Interactive voice response

1.2.2 Dual Tone Multi Frequency

1.2.3 Voice over Internet Protocol

1.2.4 Standalone mobile application

LITERATURE SURVEY

2.1 AUTOMATED ONLINE BLOOD BANK

DATABASE

2.2 SMART PHONES TO THE RESCUE: THE VIRTUAL

BLOOD BANK PROJECT

2.3 SMART BLOOD QUERY: A NOVEL MOBILE

PHONE BASED PRIVACY- AWARE BLOOD
DONOR RECRUITMENT AND MANAGEMENT
FOR DEVELOPING REGIONS

2.4 MHEALTH: BLOOD DONATION SERVICE IN

BANGLADESH

SYSTEM STUDY

3.1 EXISTING SYSTEM

3.1.1 Issues in the system

3.1.2 Solutions

3.2 PROPOSED SYSTEM

4

SYSTEM REQUIREMENTS

9
14

4.1 HARDWARE REQUIREMENTS

14

4.2 SOFTWARE REQUIREMENTS

14

DESIGN AND IMPLEMENTATION

15

5.1

OBJECT ORIENTED ANALYSIS

15

5.2

SYSTEM ARCHITECTURE

19

5.3

IMPLEMENTATION DETAILS

19

5.3.1

Call receiving module

19

5.3.2

Call processing module

19

5.3.3

Call forwarding module

20

CONCLUSION & FUTURE ENHANCEMENT

21

6.1

CONCLUSION

21

6.2

FUTURE ENHANCEMENT

21

APPENDICES
APPENDIX 1 (SAMPLE SCREEN SHOTS)
APPENDIX 2 (PUBLICATIONS)
REFERENCES
22

CHAPTER 1
INTRODUCTION
1.1 COMMUNICATION TECHNOLOGY

A basic telecommunication system consists of three primary units that are always present in some
form:

A transmitter that takes information and converts it to a signal.

A transmission medium, also called the "physical channel" that carries the signal. An example of this
is the "free space channel".

A receiver that takes the signal from the channel and converts it back into usable information.

For example, in a radio broadcasting station the station's large power amplifier is the transmitter; and the
broadcasting antenna is the interface between the power amplifier and the "free space channel". The free space
channel is the transmission medium; and the receiver's antenna is the interface between the free space channel
and the receiver. Next, the radio receiver is the destination of the radio signal, and this is where it is converted
from electricity to sound for people to listen to.
Sometimes,

telecommunication

systems

are "duplex" (two-way

systems)

with

single

box

of electronics working as both a transmitter and a receiver, or a transceiver. For example, a cellular
telephone is a transceiver. The transmission electronics and the receiver electronics in a transceiver are actually
quite independent of each other. This can be readily explained by the fact that radio transmitters contain power
amplifiers that operate with electrical powers measured in the watts or kilowatts, but radio receivers deal with
radio powers that are measured in the microwatts or nanowatts. Hence, transceivers have to be carefully
designed and built to isolate their high-power circuitry and their low-power circuitry from each other.
Telecommunication over fixed lines is called point-to-point communication because it is between one
transmitter

and

one

receiver.

Telecommunication

through

radio

broadcasts

is

called broadcast

communication because it is between one powerful transmitter and numerous low-power but sensitive radio
receivers.
Telecommunications in which multiple transmitters and multiple receivers have been designed to cooperate
and to share the same physical channel are called multiplex systems. The sharing of physical channels using
multiplexing often gives very large reductions in costs. Multiplexed systems are laid out in telecommunication
networks, and the multiplexed signals are switched at nodes through to the correct destination terminal
receiver.

1.2 TECHNOLOGIES USED

1.2.1

Interactive voice response

Interactive voice response (IVR) is a technology that allows a computer to interact with humans through
the use of voice and DTMF tones input via keypad.
In telecommunications, IVR allows customers to interact with a companys host system via a telephone
keypad or by speech recognition, after which they can service their own inquiries by following the IVR
dialogue. IVR systems can respond with pre recorded or dynamically generated audio to further direct
users on how to proceed. IVR applications can be used to control almost any function where the interface
can be broken down into a series of simple interactions. IVR systems deployed in the network are sized to
handle large call volumes.
It is common in industries that have recently entered the telecommunications industry to refer to
an automated attendant as an IVR. The terms, however, are distinct and mean different things to
traditional telecommunications professionals, whereas emerging telephony and VoIP professionals often
use the term IVR as a catch-all to signify any kind of telephony menu, even a basic automated attendant.
The term voice response unit (VRU), is sometimes used as well.
IVR systems are typically intended to service high call volumes, reduce cost and improve the customer
experience. Examples of typical IVR applications are telephone banking, televoting, and credit
card services. Companies also use IVR services to extend their business hours to 24/7 operation. The use
of IVR and voice automation allows callers' queries to be resolved without the need for queuing and
incurring the cost of a live agent. If callers do not find the information they need or require further
assistance, their calls are often transferred to an agent. This makes for a more efficient system in which
agents have more time to deal with complex interactions. The agents do not deal with basic inquiries that
require yes/no responses or obtaining customer details.
Call centres use IVR systems to identify and segment callers. The ability to identify customers allows
services to be tailored according to the customer profile. The caller can be given the option to wait in the
queue, choose an automated service, or request a call back. The system may obtain caller line
identification (CLI) data from the network to help identify or authenticate the caller. Additional caller
authentication data could include account number, personal information, password and biometrics (such
as voice print).
When an IVR system answers multiple phone numbers the use of DNIS ensures that the correct
application and language is executed. A single large IVR system can handle calls for thousands of
applications, each with its own phone numbers and script.

IVR also enables customer prioritization. In a system wherein individual customers may have a different
status the service will automatically prioritize the individual's call and move customers to the front of a
specific queue. Prioritization could also be based on the DNIS and call reason.
Smaller companies and start-ups can also use an IVR system to make their business appear larger than it
is. For example, a caller never needs to know that their sales and support calls are routed to the same
person.
In addition to interacting with customer information systems and databases, IVRs will also log call detail
information into its own database for auditing, performance report, and future IVR system enhancements.

1.2.2

Dual Tone Multi Frequency

Dual-tone multi-frequency signalling (DTMF) is an in-band telecommunication signalling system using

the voice-frequency band over telephone lines between telephone equipment and other communications
devices and switching centres
Multi-frequency signalling is a group of signalling methods that use a mixture of two pure
tone (pure sine

wave)

sounds.

Various

MF

signalling protocols were

devised

by

the Bell

System and CCITT. The earliest of these were for in-band signalling between switching centres,
where long-distance telephone operators used a 16-digit keypad to input the next portion of the
destination telephone number in order to contact the next downstream long-distance telephone operator.
This semi-automated signalling and switching proved successful in both speed and cost effectiveness.
Based on this prior success with using MF by specialists to establish long-distance telephone calls, dualtone multi-frequency signalling was developed for end-user signalling without the assistance of operators.
The DTMF system uses a set of eight audio frequencies transmitted in pairs to represent 16 signals,
represented by digits, letters, and symbols. As the signals are audible tones in the standard telephony
voice frequency range, they could be transmitted across long distances through electrical repeaters and
amplifiers, and over radio and microwave links, thus eliminating the need for intermediate operators.
The DTMF telephone keypad is laid out in a 44 matrix of push buttons in which each row represents
the low frequency component and each column represents the high frequency component of the DTMF
signal. Pressing a key sends a combination of the row and column frequencies. For example, the
key 1 produces a superimposition of tones of 697 and 1209 hertz (Hz). Initial pushbutton designs
employed levers, so that each button activated two contacts. The tones are decoded by the switching
centre to determine the keys pressed by the user.

DTMF keypad frequencies

1209 Hz

1336 Hz

1477 Hz

1633 Hz

697 Hz

770 Hz

852 Hz

941 Hz

Table 1.1 DTMF keypad frequencies

1.2.3

Voice Over IP

Voice over IP (VoIP) is a methodology and group of technologies for the delivery of voice
communications and multimedia sessions over Internet Protocol (IP) networks, such as the Internet. Other
terms commonly associated with VoIP are IP telephony, Internet telephony, broadband telephony,
and broadband phone service.
4

The term Internet telephony specifically refers to the provisioning of communications services
(voice, fax, SMS, voice-messaging) over the public Internet, rather than via the public switched telephone
network (PSTN). The steps and principles involved in originating VoIP telephone calls are similar to
traditional digital telephony and involve signalling, channel setup, digitization of the analog voice signals,
and encoding. Instead of being transmitted over a circuit-switched network, however, the digital
information is packetized, and transmission occurs as IP packets over a packet-switched network. Such
transmission entails careful considerations about resource management different from time-division
multiplexing (TDM) networks.
Early providers of voice-over-IP services offered business models and technical solutions that mirrored
the architecture of the legacy telephone network. Second-generation providers, such as Skype, have built
closed networks for private user bases, offering the benefit of free calls and convenience while potentially
charging for access to other communication networks, such as the PSTN. This has limited the freedom of
users to mix-and-match third-party hardware and software. Third-generation providers, such as Google
Talk, have adopted the concept of federated VoIPwhich is a departure from the architecture of the
legacy networks. These solutions typically allow dynamic interconnection between users on any two
domains on the Internet when a user wishes to place a call.
VoIP systems employ session control and signalling protocols to control the signalling, set-up, and teardown of calls. They transport audio streams over IP networks using special media delivery protocols that
encode voice, audio, video with audio codecs, and video codecs as Digital audio by streaming media.
Various codecs exist that optimize the media stream based on application requirements and network
bandwidth; some implementations rely on narrowband and compressed speech, while others support high
fidelity stereo codecs. Some popular codecs include -law and a-law versions of G.711, G.722, which is
a high-fidelity codec, marketed as HD Voice by Polycom, a popular open source voice codec known
as iLBC, a codec that only uses 8 Kbit/s each way called G.729, and many others.
VoIP is available on many smart phones, personal computers, and on Internet access devices. Calls and
SMS text messages may be sent over 3G or Wi-Fi.

1.2.4

Standalone Mobile Application

A mobile app is a computer program designed to run on smart phones, tablet computers and other mobile
devices.
Apps are usually available through application distribution platforms, which began appearing in 2008 and
are typically operated by the owner of the mobile operating system, such as the Apple App Store, Google
Play, Windows Phone Store, and BlackBerry App World. Some apps are free, while others must be
bought. Usually, they are downloaded from the platform to a target device, such as an iPhone,
5

BlackBerry, Android phone or Windows Phone, but sometimes they can be downloaded
to laptops or desktop computers. For apps with a price, generally a percentage, 20-30%, goes to the
distribution provider (such as iTunes), and the rest goes to the producer of the app. [1]The same app can
therefore cost the average Smartphone user a different price depending on whether they use iPhone,
Android, or BlackBerry 10 devices.
Mobile apps were originally offered for general productivity and information retrieval, including
email, calendar, contacts, stock market and weather information. However, public demand and the
availability of developer tools drove rapid expansion into other categories, such as word
processing, social media, picture sharing, mobile games, factory automation, GPS mapping and locationbased services, banking, networking and file transfer, education, video streaming, order tracking, ticket
purchases and recently mobile medical apps. The explosion in number and variety of apps made
discovery a challenge, which in turn led to the creation of a wide range of review, recommendation, and
curation sources, including blogs, magazines, and dedicated online app-discovery services. Recently
government regulatory agencies have launched initiatives to regulate and curate apps, particularly medical
apps.

CHAPTER 2
LITERATURE SURVEY

In this chapter we see an overview of some related research works presented.

2.1 SMART PHONES TO THE RESCUE: THE VIRTUAL BLOOD BANK PROJECT
AUTHOR: Ramesh Singh, Preeti Bhargava, and Samta Kain

IDEA
Donors register with the service through their mobile devices, specifying their blood type and
contact information in a donor application.
The General Packet Radio Service supports network communications between mobile devices
and the server.
The server stores information about the available blood supply in a central data repository.
6

People who seek blood also communicate with the server through their mobile devices,
specifying their blood type and current location in a subscriber application.
The server matches the blood type and location with the profiles of registered donors or blood
banks, retrieves the information, and sends it to the seeker via GPRS.
The architecture thus embodies a pervasive network of information about availability of the
requested blood type.

DISADVANTAGE

It needs GPRS service in mobile phone.

2.2 Smart Blood Query: A Novel Mobile Phone Based Privacy-aware Blood
Donor Recruitment and Management System for Developing Regions
AUTHOR: Ren Muhammad Sajidur Rahman, Khondoker Asif Akter, Shakil Hossain, Anjon
Basak, Syed Ishtiaque Ahmed

IDEA
Blood donors register for this service through SMS, specifying their blood groups and other
necessary information in specific format. These are stored in the central database.
Donors are also given the option to edit their profile and update details such as change in location
or availability.
When a query for blood come to SBQ server, it makes a quick query and sends a bulk SMS to top
5 search result donors, stating the situation.

The donors have the option to either accept the request by replying YES or deny it by replying
NO. If a donor agrees to the request, he/she is sent a brief questionnaire in order to check if he/she
fulfils the requirements of blood donation.
If everything is all right, the donor then contacts with the recipient. When a donor updates the
date of last donation by SMS, his name is disabled from the donor list for 89 days after donation.
Similarly, if the donor is unwell, he can edit his profile and mark as unavailable.

DISADVANTAGE

User needs messaging service in mobile phone.

Every people cannot use this service easily, literates only can do.

2.3 AUTOMATED ONLINE BLOOD BANK DATABASE

AUTHOR: Muhammad Arif, Sreevass, Nafseer K, Rahul R

IDEA
A blood bank database is created by collection of details from various sources like Blood banks,
NSS, NGOs hospitals and through web interface.
The data collected will be maintained in a central server. This central server will be associated
with a Toll free number that can be used to connect to it.
An algorithm will be defined based on the various parameters that need to be accounted for,
before blood transfer is done.
The willingness of donor and the closeness of the donor to the place from where the call is
coming are also accounted for in defining this algorithm.
8

Based on the algorithm the most eligible donor is found out.

From the server the call from the required person is routed to the eligible donor's number.

DISADVANTAGE

It has a more complex structure.

It costs very high.

2.4 mHealth: Blood Donation Service in Bangladesh

AUTHOR: A. H. M. Saiful Islam, Nova Ahmed, Kamrul Hasan and Md. Jubayer
IDEA
Clients as well as Blood donors need to be registered first for this project to collect donors
record.
A client or donor is managed by a mobile phone.
The collected data is constantly wirelessly transmitted GPRS to a data centre, from where it is
forwarded to responsible personnel who can assess required information of a donor.
The registration processes are done wirelessly using GPRS to a data centre acting as an
intermediary between donors/clients.
It provides two services: data repository (collecting and storage of the received data), streaming
service (forwarding data to a donor or client) using SMS.

DISADVANTAGE

It needs both GPRS and Messaging service.

The user who searches for blood should also be registered to search.

CHAPTER 3
SYSTEM STUDY

3
3.1 EXISTING SYSTEM
3.1.1

ISSUES IN THE SYSTEM

SMS service and GPRS service becomes essential in the existing system, which every one cannot
have and one cannot have it in every time.

Needs some kind of English knowledge for using the existing system.

Registration may take time while one searches for donor and it is unnecessary.

3.1.2 SOLUTIONS

The system is made to be used by everyone, anyone who has a basic mobile phone or a telephone or
by a pay phone, can access this service.
10

Those who wish to register can register using the web application provided.

3.2 PROPOSED SYSTEM

Working
1) Processing Steps:
i. Call is made to the server
ii. Required blood group is typed on the keypad
iii. DTMF decoder decodes this key
iv. Algorithm comes into play getting the list of eligible donors
v. Call gets routed to the most eligible donor
vi. In case the most eligible donor is not responding, automatically the call gets routed to the
second most eligible donor
vii. IVRS system constantly updates the person who is making the call so that he knows what
process is going on.

2) Functioning of Eligible donor finding Algorithm

A key component of the system is the algorithm used for determining a prospective donor in real
time. The parameters which are taken into consideration are:

Blood group

Last time of donation

Health parameters

Closeness to location from where call is happening

Frequency of donation
We should ensure that the hit rate of finding a successful donor after a redirection is as high as
possible, since both the time of caller and system resources are crucial.

Inputs: The DONOR table and a blood group

Outputs: The highest priority donor of that blood group

Steps:
11

I.

Start.

II.

LOC=closest location in donor table.

III.

Get the list of donors in location=LOC. Let this be list Ll.

IV.

OLD DONATION=oldest donation date from list Ll.

V.

From list Ll get the list of donors who last donated on day=OLD_DONATION. Let this be list
L2.

VI.

OLD CONTACT=oldest contact date from list L2.

VII.

From list L2 get the list of donors who were contacted on day=OLD CONTACT. Let this be list
L3.

VIII.

BMI=maximum Body Mass Index from list L3.

IX.

From list L3, select a donor whose body mass index >= BMI. He/she is the most eligible donor.

X.

Stop.

This algorithm considers four parameters for selection. The parameters with their priority are given
below:
a. Health parameters.
b. Location (distance between the donor and recipient).
c. Last Donation Date.
d. Last Contact Date.

12

Fig 3.1 Functioning of Eligible donor finding Algorithm

KEY ISSUES

1) Tackling fake callers

In order to prevent the issue of fake callers demanding for blood, DTMF password facility is provided.
These passwords are one time passwords that are provided through hospitals or blood banks.

2) Tackling fake donors

13

Since a dynamic algorithm for choosing the most eligible donor is followed, which takes into account the
willingness factor of each donor, fake donors will automatically be relegated to the bottom of the donor
list.

3) Follow up communication with the donor

Once the initial communication between the donor and recipient is completed, a SMS containing the
recipient's number is given to the donor for follow up communication. An alternate IVRS facility is also
provided keeping in mind the landline phone users for whom the phone number will be dictated out.

4) Handling large user traffic blood

To handle large user traffic parallel programming is employed. When a higher demand for blood is
needed, by pressing a key on the phone, automatic redirection to the next most eligible donor is made
possible. A limit of 5 donors is kept for each caller. For people with constant demand for blood, like
people with blood cancer, a separate registry of their phone numbers is kept.

5) Avoiding intermediaries from creating artificial scarcity

A caller's database is maintained and monitored to ensure the too frequent calls from the same number are
not made. A separate registry is made containing phone numbers of hospitals and blood banks. Thus
tracking of intermediaries or agents can be made possible.

6) Updating database
For every blood transfusion made, it is essential that the database is updated about this transfer. It is
essential factor that should be considered for selecting the most eligible donor the next time, as a
minimum of 56 days should be passed between successive whole blood donations. This updating is done
based on the confirmation from both the donor and the blood bank/hospital where the donation was done.

ADVANTAGES

ADVANTAGES OVER OTHER SIMILAR SYSTEMS

14

When there is urgent need for blood, it may not be possible for people to connect to the internet to
look into the online blood database systems that are already in existence. If we adopt this model, the
caller is immediately connected to the donor.

Consider a SMS based database system is in which whenever a SMS is send to prospective senders,
based on the demand. Here there will be a significant delay in the recipient side in viewing the SMS
and then responding to it. If the system that we propose is setup, only the most eligible donor is
contacted and that too with no cost being borne by him.

Another significant advantage is the fact that location details of prospective donors is taken into
account by the algorithm. This ensures that automatically the nearest donor is contacted and
immediate fulfilment of blood requirement is done. In other similar systems, there is no such
provision, which again adds on to the delay in getting a donor.

A toll free number is used to connect to the server. Any other additional cost that may occur will be
minimal that can be borne by government or NGO's. So any common man at the time his utmost
need can connect to this system for help.

Internet access is not a essential requirement for the effective working of this system. This enables
the system to be used in rural areas as well, which are not well connected by internet service.

An apt scenario where the full use of this system can be described is some big vehicle accident.
There will be a number of people who will be in urgent need of blood of different blood groups.
Once they connect to this system, the IVRS system automatically directs to them the most eligible
donor of that specific blood group. Also, will multiple number of parallel ports provided,
considerable amount of traffic can be easily handled.

4
5

CHAPTER 4

SYSTEM REQUIREMENTS

4.1 HARDWARE REQUIREMENTS

15

For simulation
Processor

Intel Pentium IV or higher

RAM

2 GB

Secondary Memory

500 MB

Display

14 colour monitor

Keyboard

101 key standard keyboard

Mouse

Windows OS compatible

For working
Any Mobile phone or Telephone

For Android Application

OS

Android 4.1 or Above

RAM

512 MB

Memory

100 MB

4.2 SOFTWARE REQUIREMENTS

Operating System

Linux x86 32/64-bit

Windows 7, 8 and XP
Mac OS X 10.7,10.8 and 10.9

Tool

C Complier and System Libraries

CHAPTER 5
DESIGN AND IMPLEMENTATION

5.1 OBJECT ORIENTED ANALYSIS

16

5.1.1 USE- CASE DIAGRAM

Fig 5.1 Use case diagram of donor catcher system

Explanation:
The hospital will maintain the donor list and will update the benefactor and donor details. The
user will call the toll free number and will ask for the required blood group. The donor will
register his details and will update the personal and donor details it will be maintained by the
hospital and the administrator. The administrator will collect the donor details from the NGO and
will invest later.

5.1.2 ACTIVITY DIAGRAM

17

Fig 5.2 Activity diagram of donor catcher system

Explanation:
The donor will register his details and will update the personal and donation information.The
user will call the toll free number and will enter the blood group and the call will be forwarded to
the best eligible donor. The user will receive the SMS later.

5.1.3. CLASS DIAGRAM

18

Fig 5.3 Class diagram of donor catcher system

Explanation:
The donor will give his personal details and it will be stored in the server. The hospitals
information is also stored in the server. The user will request the server and will get the required
information.

5.1.4 COMPONENT DIAGRAM

19

Fig 5.4 Component diagram of donor catcher system

Explanation:
The user will search and filter the details and will forward the required details. The user will
request for the information from the server.

5.1.5 DEPLOYMENT DIAGRAM

20

Fig 5.5 Use case diagram of donor catcher system

Explanation:
The communication takes place through the mobile phone and by the telephone exchange. They
request information from the server and it is stored in the database for future use.

5.2 SYSTEM DESIGN

21

Fig 5.6 System design diagram of Donor catcher system

5.3 IMPLEMENTATION DETAILS

5.3.1 Call Receiving Module
The call made by the users will be handled by our server. IVR will respond to the user. It
will ask
the users to press numbers for questions like city, blood group, language etc. The user will press the
number; the mobile will send the DTMF tones to the server and the server will process according to the
DTMF.

5.3.2 Call Processing Module

The server will receive the DTMF values for city and blood group. The server will search the donors
in that city in that blood group and will check the last donated date, when the user matches all the
criterias the call will be forwarded to the respective donor.

5.3.3Call Forwarding Module

The calls will be forwarded to the respective donors. The user will now talk to the donor, when he is
satisfied, he will be asked to press one button, when not satisfied, he will be asked to press another button
and the server will forward the call to the next donor.

CHAPTER 6
CONCLUSION & FUTURE ENHANCEMENT
22

5.1 CONCLUSION
We all know blood is a primary necessity of life. There are lots of scenarios where immediate
availability of blood can save human lives. Our project makes one step in this direction. Online database
aided with automatic call routing facility can is an apt choice for immediate fulfilment of blood
requirements.

5.2 FUTURE ENHANCEMENT

We have simulated the telecommunication concept to the mobile phones. It can be made into real
time and so it will be helpful to the public.
Hospital logins in the websites are yet to be made. So the hospitals can update the details of the
donor on the spot when need, and they can also search for the donors.

REFERENCES

1. T Santhanam, S Sundaram, Application of CART Algorithm in Blood Donors

Classification, Journal of Computer Science, 2010 scipub.org.

23

2. Kapicak, L. ,Nevlud, P. , Zdralek, J. , Dubec, P. , Plucar, J. "Remote control of Asterisk

via Web Services", 34th International Conference on Telecommunications and Signal
Processing (TSP), 2011
3. Sripanidkulchai, K., Shu Tao, Zon-Yin Shae "DA VINCI: A tool to improve VoIP call
routing configurations", IEEE Network Operations and Management Symposiwn
(NOMS), 2010
4. Dinusha Vatsalan1,Shiromi Arunatileka, Keith Chapman, Gihan Senaviratne, Saatviga
etileka and Yvonne Wickramasinghe, Mobile Technologies for Enhancing eHealth
Solutions in Developing Countries,2010 Second International Conference on eHealth,
Telemedicine, and Social Medicine
5. BN Li, S Chao, MC Dong, SIBAS: a blood bank information system and its 5-year
implementation at Macau, Computers in Biology and Medicine, 2007-Elsevier.

APPENDICES
APPENDIX 1
Coding of Mobile Application
24

Index.html
<!DOCTYPE HTML>
<html>
<head>
<meta charset="UTF-8">
<title>index</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximumscale=1.0, minimum-scale=1.0, user-scalable=0">
<link rel="shortcut icon" href="images/favicon.png">
<link rel="apple-touch-icon" href="images/apple-touch-icon.png">
<link href="jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet">
<link href="jqueryMobile/jquery.mobile-1.4.0.min.css" rel="stylesheet">
<link rel="stylesheet" href="css/main.css">
<script>window.$ = window.jQuery = WLJQ;</script>
<script src="jqueryMobile/jquery.mobile-1.4.0.js"></script>
<link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet">
<link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet">
<link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet">
<link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet">
<link href="native/assets/www/default/jqueryMobile/jquery.mobile-1.4.0.min.css"
rel="stylesheet">
</head>
<body onload="startTime()">
<div data-role="page" id="page" data-theme="b" >
<div data-role="content" style="padding: 15px">
<!--application UI goes here-->
<div data-role="header" data-position="fixed">
<h1>Choose</h1>
</div>
<div id="txt" align="right"></div>
<br><br><br><br>
<a href="#" data-role="button" id="reg" onClick="reg()">Register</a>
<a href="#" data-role="button" id="need" onClick="need()">Need Blood?</a>
<a href="#" data-role="button" id="dnd" onClick="dnd()">Update activities</a>

</div>
<br><br><br>
<div data-role="footer">
<marquee>Save blood, save life</marquee></div>
</div>
<div data-role="page" id="page1" data-theme="b" >
<div data-role="content" style="padding: 15px">
<!--application UI goes here-->
<div data-role="header" data-position="fixed">
<h1>Register</h1>
25

</div>
<div data-role="navbar">
<ul>
<li><a href="#" id="home2">Home</a></li>
<li><a href="#" id="reg2">Register</a></li>
<li><a href="#" id="sear2">Search</a></li>
</ul>
</div><!-- /navbar -->
<!-- <label id="label" style="text-align: center; font-size: xlarge">REGISTRATION</label>-->
<form name="myForm"><input type="text" id="name" name="name"
placeholder="Name">
<input type="text" id="mno" name="mno" placeholder="Mobile
number">
<select id="bg" name="bg">
<option value="A+"selected>A+</option>
<option value="A-">A-</option>
<option value="B+">B+</option>
<option value="B-">B-</option>
<option value="AB+">AB+</option>
<option value="AB-">AB-</option>
<option value="O+">O+</option>
<option value="O-">O-</option>
</select>
<input type="password" id="addr" name="addr" placeholder="Enter
password">
<input type="text" id="addr2" name="addr2" placeholder="Door no.,
street,">
<input type="text" id="addr3" name="addr3" placeholder="Area, city,
state">
<!--<table>
<tr><td>Post</td>
<td><select id="public1">
<option value="yes">Yes</option>
<option value="no">No</option>
</select>
</td></tr>
</table>-->
<table>
<tbody>
<tr>
<td>Drinking?:</td>
<td><select id="drink">
<option value="yes" >Yes</option>
<option selected
value="no">No</option>
26

</select></td>
</tr>
</tbody>
</table>
<!-- <table>
<tr><td>
Drinking:</td>
<td><input type="radio">Yes</td>
<td><input type="radio">No</td></tr>
</table>-->
<input type="text" id="std" name="std" placeholder="STD Code">
<input type="text" id="pin" name="pin" placeholder="PIN Number">
<a href="#" data-role="button" id="reg"
onclick="submit()">REGISTER</a>
</form></div>
</div>
<div data-role="page" id="page2" data-theme="b">
<div data-role="content" style="padding: 15px">
<!--application UI goes here-->
<div data-role="header" data-position="fixed">
<h1>Search blood</h1>
</div>
<div data-role="navbar">
<ul>
<li><a href="#" id="home1">Home</a></li>
<li><a href="#" id="reg1">Register</a></li>
<li><a href="#" id="sear1">Search</a></li>
</ul>
</div><!-- /navbar -->
<select id="bloody" name="bloody">
<option value="A+"selected>A+</option>
<option value="A-">A-</option>
<option value="B+">B+</option>
<option value="B-">B-</option>
<option value="AB+">AB+</option>
<option value="AB-">AB-</option>
<option value="O+">O+</option>
<option value="O-">O-</option>
</select>
<!-- <input type="text" id="pincode" name="pincode"
placeholder="PIN code">-->
<input type="text" id="stdcode" name="stdcode"
placeholder="STD code">
<input type="button" id="search1" name="search1"
value="Search" onclick="search()">
<br><br><br><br>
27

<a href="#" data-role="footer" id="back"

onclick="back()">Back</a>
</div>
</div>
<div data-role="page" id="dndpage" data-theme="b" >
<div data-role="content" style="padding: 15px">
<!--application UI goes here-->
<div data-role="header" data-position="fixed">
<h1>Update activities</h1>
<div data-role="navbar">
<ul>
<li><a href="#" id="home3">Home</a></li>
<li><a href="#" id="reg3">Register</a></li>
<li><a href="#" id="sear3">Search</a></li>
</ul>
</div><!-- /navbar -->
</div>
<input type="text" id="dndmno" name="mno" placeholder="Mobile
number">
<input type="password" id="dndname" name="name"
placeholder="Password">
<select id="dndbg" name="bg">
<option value="A+"selected>A+</option>
<option value="A-">A-</option>
<option value="B+">B+</option>
<option value="B-">B-</option>
<option value="AB+">AB+</option>
<option value="AB-">AB-</option>
<option value="O+">O+</option>
<option value="O-">O-</option>
</select>
<a href="#" data-role="button" id="login"
onClick="login()">ENTER</a>
</div></div>
<div data-role="page" id="dndpage1" data-theme="b" >
<div data-role="content" style="padding: 15px">
<!--application UI goes here-->
<div data-role="header" data-position="fixed">
<h1>Do not disturb</h1>
</div>
<div data-role="navbar">
<ul>
<li><a href="#" id="home4">Home</a></li>
28

<li><a href="#" id="reg4">Register</a></li>

<li><a href="#" id="sear4">Search</a></li>
</ul>
</div><!-- /navbar -->
<!-- <label><input type="radio" name="reason" id="reason"
value="6mon" >Blood donated, don't disturb for 6 months</label>
<label><input type="radio" name="reason" id="reason"
value="never">Not interested, never disturb</label>
-->
<select id="reason" name="dnddetail">
<option value="6mon"selected>Blood donated, don't disturb for 6
months</option>
<option value="never">Not interested, never disturb</option>
<option value="act">Activate me again</option>
</select>
<a href="#" data-role="button" id="dndenter"
onClick="dndenter()">DND</a>
</div>
</div>
<!-<div id="details" data-role="content">
<label for="text">Name:</label><input type="text" name="text"
id="text">
<label for="text0">Number</label><input type="text"
name="text0" id="text0">
<label for="text1">Address:</label><input
type="text" name="text1" id="text1">
</div>
<div data-role="content" id="contentlist" >
<ul data-role="listview" id="show" data-filter="true"
data-filter-placeholder="Search Product..." data-inset="true">
</ul>
</div> -->
<div data-role="page" id="page4" data-theme="b" data-dom-cache="false">
<input type="button" id="backgo" onclick="backgo()" value="Back">
<div data-role="content" style="padding: 15px">
<!--application UI goes here-->
<div data-role="listview" id="con">
<form id="form" action="">
<ol id="listview">
<li></li>
</ol>
29

</form>
</div></div></div>
<div data-role="page" id="page5" data-theme="b" >
<div data-role="content" style="padding: 15px">
<!--application UI goes here-->
<div data-role="listview" id="con">
<label id="label">HI:</label>
<form id="form1" action="">
<ol id="listview1">
<li></li>
</ol>
</form>
</div></div></div>
<div data-role="page" id="page7" data-theme="b" >
<div data-role="content" style="padding: 15px">
<input type="button" id="mapback" onclick="backend()"
value="Back">
</div>
<div data-role="content" id="mapp" style="padding: 15px"
style="height: 400px;" >
<!--application UI goes here-->
</div></div>
<script src="js/initOptions.js"></script>
<script src="js/main.js"></script>
<script src="js/messages.js"></script>
<script src="https://maps.googleapis.com/maps/api/js?
v=3.exp&sensor=false"></script>
<script type="text/javascript" src="http://maps.google.com/maps/api/js?
sensor=false"></script>
</body>
</html>
Main.css
/* Reset CSS */
a, abbr, address, article, aside, audio, b, blockquote, body, canvas, caption, cite, code, dd, del,
details, dfn, dialog, div, dl, dt, em, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6,
header, hgroup, html, i, iframe, img, ins, kbd, label, legend, li, mark, menu, nav, object, ol, p, pre,
q, samp, section, small, span, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, time, tr,
ul, var, video {
margin: 0;
30

padding: 0;
}
/* Worklight container div */
body {
height: 460px;
margin: 0 auto;
width: 320px;
}

Main.js
function wlCommonInit(){
/*
* Application is started in offline mode as defined by a connectOnStartup property in
initOptions.js file.
* In order to begin communicating with Worklight Server you need to either:
*
* 1. Change connectOnStartup property in initOptions.js to true.
* This will make Worklight framework automatically attempt to connect to Worklight Server
as a part of application start-up.
* Keep in mind - this may increase application start-up time.
*
* 2. Use WL.Client.connect() API once connectivity to a Worklight Server is required.
* This API needs to be called only once, before any other WL.Client methods that
communicate with the Worklight Server.
* Don't forget to specify and implement onSuccess and onFailure callback functions for
WL.Client.connect(), e.g:
*
* WL.Client.connect({
*
onSuccess: onConnectSuccess,
*
onFailure: onConnectFailure
* });
*
*/
// Common initialization code goes here
}
function startTime()
{
var today=new Date();
var h=today.getHours();
var m=today.getMinutes();
var s=today.getSeconds();
// add a zero in front of numbers<10
m=checkTime(m);
31

s=checkTime(s);
document.getElementById('txt').innerHTML=h+":"+m+":"+s;
t=setTimeout(function(){startTime()},500);
}
function checkTime(i)
{
if (i<10)
{
i="0" + i;
}
return i;
}
$("#reg1").click(function() {
$.mobile.changePage('#page1');
});
$("#reg2").click(function() {
$.mobile.changePage('#page1');
});
$("#sear1").click(function() {
$.mobile.changePage('#page2');
});
$("#sear2").click(function() {
$.mobile.changePage('#page2');
});
$("#reg3").click(function() {
$.mobile.changePage('#page1');
});
$("#reg4").click(function() {
$.mobile.changePage('#page1');
});
$("#sear3").click(function() {
$.mobile.changePage('#page2');
});
$("#sear4").click(function() {
$.mobile.changePage('#page2');
});
$("#home1").click(function() {
$.mobile.changePage('#page');
});
$("#home2").click(function() {
$.mobile.changePage('#page');
});
32

$("#home3").click(function() {
$.mobile.changePage('#page');
});
$("#home4").click(function() {
$.mobile.changePage('#page');
});
function backend()
{
$.mobile.changePage('#page4',{transition:"slide"});
}
function back()
{
$.mobile.changePage('#page',{transition:"slide"});
}
function backgo()
{
$.mobile.changePage('#page2',{transition:"slide"});
//$('#page4').reload();
}
function mapback()
{
$.mobile.changePage('#page5',{transition:"slide"});
}
function mappage(k)
{
$.mobile.changePage('#page7',{transition:"slide"});
//alert(window.myValue[k]);
//alert(window.myValue1[k]);
var map;

var geocoder = new google.maps.Geocoder();

var address = window.myValue1[k];
var latitude;
var longitude;
33

//$('#page7').refresh();
//$('#page7').append("<br><br>");
//$('#page7').append("Name:<b>"+window.myValue2name[k].toUpperCase()+"</b><br>");
//$('#page7').append("Blood group:<b>"+window.myValue4bg[k]+"</b><br>");
//$('#page7').append("Mobile number:<b>"+window.myValue3mobile[k]+"</b><br>");
//$('#page7').append("Address:<b>"+window.myValue[k]+","+window.myValue1[k]
+"</b><br>");
//$('#page7').append("Pincode:<b>"+window.myValue5pin[k]+"</b><br>");
//$('#page7').append("<br><br>");
geocoder.geocode( { 'address': address}, function(results, status) {
if (status == google.maps.GeocoderStatus.OK) {
window.latitude = results[0].geometry.location.lat();
window.longitude = results[0].geometry.location.lng();
} else {
alert('Geocode was not successful for the following reason: ' + status);
}
//var address = document.getElementById('address').value;
geocoder.geocode( { 'address': address}, function(results, status) {
if (status == google.maps.GeocoderStatus.OK) {
map.setCenter(results[0].geometry.location);
var marker = new google.maps.Marker({
map: map,
position: results[0].geometry.location
});
} else {
alert('Geocode was not successful for the following reason: ' + status);
}
});
var mapOptions = {
zoom: 15,
center: new google.maps.LatLng(window.latitude, window.longitude)
};

map = new google.maps.Map(document.getElementById('mapp'),

mapOptions);
});

34

google.maps.event.addDomListener(window, 'load', initialize);

}
function dnd()
{
$.mobile.changePage('#dndpage',{transition:"slide"});
}
function reg()
{
$.mobile.changePage('#page1',{transition:"turn"});
}

function need()
{
$.mobile.changePage('#page2',{transition:"flip"});
}
function dndenter()
{
var mobile=window.value;
// using as global varaiable
//var dndvalue=reason.filter(':checked').val();
var dndvalue=$("#reason").val();
//var dndvalue=document.getElementByName(reason).val();;
//alert(mobile);
//alert(dndvalue);
try{ WL.Client.invokeProcedure(
{
adapter : "sample",
procedure : "dndupdate",
parameters : [dndvalue, mobile]
},
{
onSuccess:function(result){
alert("Updated");
},
onFailure:function(result){
alert("Updation failed");
}
});
}
35

catch(err)
{
alert(err);
}
}
function login()
{
var responseData= {};
var dndname=$("#dndname").val();
var dndmno=$("#dndmno").val();
window.value=dndmno;
var dndbg=$("#dndbg").val();
$.mobile.loading('show', {text:'Logging...', textVisible:true, theme:'b'});
try{
WL.Client.invokeProcedure(
{
adapter : "sample",
procedure : "dndlogin",
parameters : [dndmno]
},
{
onSuccess:function(result){
responseData = result.invocationResult.resultSet;
if (result.invocationResult.isSuccessful) {
if (responseData.length >= 0) {
for (var i = 0; i <= responseData.length; i++) {
var obj = responseData[i];
var rebg = obj.bg;
var rename = obj.street;
if(dndbg == rebg)
{
if(dndname == rename)
{
$.mobile.loading( "hide" );
$.mobile.changePage('#dndpage1');
}
}
else
{
$.mobile.loading('hide');
alert("Enter valid data");
}
}
}
}
36

},
onFailure:function(result){$.mobile.loading('hide');alert("Retry
again...");}
}
);
}
catch(err1)
{alert(err1);}
}
function submit()
{
var name=$("#name").val();
if(name==""){
alert("Enter valid name");
document.myForm.name.focus() ;
return false;
}
var mobileno=$("#mno").val();
{
if (mobileno.length!=10)
{
alert("Enter 10 digit mobile number");
document.myForm.mno.focus() ;
return false;
}
}
var bg=$("#bg").val();
var street=$("#addr").val();
if(street<5)
{
alert("Enter password greater than 5 digits");
document.myForm.addr.focus() ;
return false;
}
var city=$("#addr2").val();
if(city==""){
alert("Enter address");
document.myForm.addr2.focus() ;
return false;
}
var country=$("#addr3").val();
if(country==""){
alert("Enter address");
37

document.myForm.addr3.focus() ;
return false;
}
//var public1=$("#public1").val();
var drink=$("#drink").val();
var std=$("#std").val();
if(std=="")
{
alert("Enter valid STD code");
document.myForm.std.focus() ;
return false;
}
var pin=$("#pin").val();
{
if( document.myForm.pin.value == "" ||
isNaN( document.myForm.pin.value ) ||
document.myForm.pin.value.length != 6)
{
alert( "Please provide a zip in the format ######" );
document.myForm.Zip.focus() ;
return false;
}
}
try{
WL.Client.invokeProcedure(
{
adapter : "sample",
procedure : "insertreg",
parameters : [name, mobileno, bg, street, city, country, drink, std, pin]
},
{
onSuccess : function(result) {
alert("Successfully registered");
$.mobile.changePage('#page');
},
onFailure : function(result) {alert("Number already registered or connection not
available");}
}
);}
catch(err)
{alert(err);}
}
/*function search()
{
document.write('<body bgcolor="blue">');
document.write('Hi</body>');
38

}*/
function reg1(k)
{
$.mobile.changePage('#page5',{transition:"turn"});
alert(window.myValue[k]);
alert(window.myValue1[k]);
//$('#page5').append("Welcome " + k + ", the ");
//$('#page5').append("Pincode:<b>"+window.myValue[k]+"</b><br>"+window.myValue1[k]
+"</b><br>");
}
function search()
{
//$("#page4").load("index.html");
//("#page4").refresh();
$.mobile.changePage("#page4");
//$.mobile.reload("#page4");
//$('[data-role="content"]').empty();
$.mobile.loading('show', {text:'Retrieving...', textVisible:true, theme:'b'});
//window.location.reload(true);
var stdcode=$("#stdcode").val();
var bg=$("#bloody").val();
//var pincode=$("#pincode").val();
//var ProductCollection = {};
var responseData = {};
WL.Client.invokeProcedure({
adapter:"sample",
procedure:"getdonor",
parameters:[stdcode,bg]
},
{
onSuccess:function(result){
console.log("Inside function" +result);
//var html='';
//WL.Logger.debug("Return data" + result.invocationResult.resultSet);
responseData = result.invocationResult.resultSet;
if(result.invocationResult.isSuccessful)
{
if(responseData.length>0)
{
39

//

$("#productslist").empty();
//document.write("<html><body><b>Name</b>&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>Phone<
/b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;<b>City</b></body></html>");
//var pass6 = new Array();
myValue= [];
myValue1= [];
myValue2name= [];
myValue3mobile= [];
myValue4bg= [];
myValue5pin= [];
for(var i=0;i<responseData.length;i++)
{
var obj=responseData[i];
var pass1=obj.name;
// window.value1=pass1;
var pass2=obj.mobileno;
// window.value2=pass2;
var pass3=obj.city;
var pass4=obj.bg;
var pass5=obj.country;
var pass6=obj.pin;
// pass6[i]=pass6;
window.myValue[i] = pass3;
window.myValue1[i] = pass5;
window.myValue2name[i] = pass1;
window.myValue3mobile[i] = pass2;
window.myValue4bg[i] = pass4;
window.myValue5pin[i] = pass6;;
// window.ivalue= i ;
//$
('#page4').append(pass1+"&nbsp;&nbsp;"+pass2+"&nbsp;&nbsp;"+pass3+"<br>");
//document.write('<html><body> Name:');
$
('#page4').append("Name:<b>"+pass1.toUpperCase()+"</b><br>");
$('#page4').append("Blood
group:<b>"+pass4+"</b><br>");
$('#page4').append("Mobile
number:<b>"+pass2+"</b><br>");
$
('#page4').append("Address:<b>"+pass3+","+pass5+"</b><br>");
$
('#page4').append("Pincode:<b>"+pass6+"</b><br>");
40

$('#page4').append('<a href="#" data-role="button"

id="reg" onClick="mappage('+i+')">Map</a><b>');
$('#page4').append("<br><br>");
// window.value3=pass3;
//$('#contentlist').append$('<li>', {}).append($
('<a>',{'href':'#details','data-transition' : 'slide','text':'obj.name','onclick':'getdetails('+pass1+')'}));
//$.mobile.changePage("#show");
//
$("#show").append(pass1);
//document.write("<html><body><table
align:center background-color:grey cellspacing=5% cellpading=5%><tr>");
//document.write('<td width="33%"><a
href="#contentlist" onClick="getdetails()">'+pass1+'</a></td>');
//document.write("<td
width=33%>"+pass2+"</td>");
//document.write("<td
width=33%>"+pass3+"</td>");
//document.write("</tr></table></body></html>");
// document.write("<!DOCTYPE
HTML><html><head><meta charset='UTF-8'><title>index</title><meta name='viewport'
content='width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, userscalable=0'><link rel='shortcut icon' href='images/favicon.png'><link rel='apple-touch-icon'
href='images/apple-touch-icon.png'><link href='jqueryMobile/jquery.mobile-1.4.0.css'
rel='stylesheet'><link href='jqueryMobile/jquery.mobile-1.4.0.min.css' rel='stylesheet'><link
rel='stylesheet' href='css/main.css'><script>window.$ = window.jQuery =
WLJQ;</script><script src='jqueryMobile/jquery.mobile-1.4.0.js'></script><link
href='native/www/default/jqueryMobile/jquery.mobile-1.4.0.css'rel='stylesheet'><link
href='native/www/default/jqueryMobile/jquery.mobile-1.4.0.css'rel='stylesheet'><link
href='native/www/default/jqueryMobile/jquery.mobile-1.4.0.css'rel='stylesheet'><link
href='native/www/default/jqueryMobile/jquery.mobile1.4.0.css'rel='stylesheet'></head><body><div data-role='page' id='page' data-theme='b' ><div
data-role='content' style='padding: 15px'>");
//document.write(pass1);
//document.write("</div></div><script
src='js/initOptions.js'></script<script src='js/main.js'</script><script
src='js/messages.js'></script</body></html>");
//document.getElementById["print"].innerHTML=pass1;
//document.writeln(pass1+"---"+pass2+"---"+pass3)
;
//document.writeln("<br>");
//document.writeln("<br>");
//document.writeln("<br>");
//document.writeln(pass2);
//document.writeln(pass3);
//alert(pass1+"---"+pass2+"---"+pass3);
//alert(pass2);
41

//alert(pass3);
//document.write("<br>");
/*var detaillist=responseData[i];
html=html + '<li><a
href"#">'+detaillist.name+''+detaillist.mobileno+''+detaillist.city+'</a></li>';
//ProductCollection[obj.name]=obj;*/
}
// jq("#list").html(html);
$.mobile.loading('hide');
}
else{alert("Sorry, " +bg+" not available in this std code "+stdcode);
$.mobile.loading('hide');
$.mobile.changePage('#page2');
}
}
},
onFailure:function(result){alert("Error in Retrieving");}
}
);
//document.writeln('</div><script src="js/initOptions.js"></script<script
src="js/main.js"></script><script src="js/messages.js"></script</body></html>');
}
Sample.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-Licensed Materials - Property of IBM
5725-I43 (C) Copyright IBM Corp. 2011, 2013. All Rights Reserved.
US Government Users Restricted Rights - Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
-->
<wl:adapter name="sample"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wl="http://www.worklight.com/integration"
xmlns:sql="http://www.worklight.com/integration/sql">
<displayName>sample</displayName>
<description>sample</description>
<connectivity>
<connectionPolicy xsi:type="sql:SQLConnectionPolicy">
<!-- Example for using a JNDI data source, replace with
actual data source name -->
<!-- <dataSourceJNDIName>java:/data-source-jndiname</dataSourceJNDIName> -->
42

<!-- Example for using MySQL connector, do not forget to

put the MySQL connector library in the project's lib folder -->
<dataSourceDefinition>
<driverClass>com.mysql.jdbc.Driver</driverClass>
<url>jdbc:mysql://localhost:3306/sample</url>
<user>root</user>
<password>root</password>
</dataSourceDefinition>
</connectionPolicy>
<loadConstraints maxConcurrentConnectionsPerNode="5" />
</connectivity>
<!-- Replace this with appropriate procedures -->
<procedure name="procedure1"/>
<procedure name="procedure2"/>
<procedure name="getSamples"> </procedure>
<procedure name="addSample"> </procedure>
<procedure name="updateSample"> </procedure>
<procedure name="deleteSample"> </procedure>
<procedure name="insertreg"/>
<procedure name="getdonor" />
<procedure name="dndlogin" />
<procedure name="dndupdate" />
</wl:adapter>
Sample-impl.js:
/*
sample-impl.js
/*
* Licensed Materials - Property of IBM
* 5725-I43 (C) Copyright IBM Corp. 2011, 2013. All Rights Reserved.
* US Government Users Restricted Rights - Use, duplication or
* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
*/
/
************************************************************************
*******
* Implementation code for procedure - 'procedure1'
*
*
43

* @return - invocationResult
*/
var procedure1Statement = WL.Server.createSQLStatement("select COLUMN1,
COLUMN2 from TABLE1 where COLUMN3 = ?");
function procedure1(param) {
return WL.Server.invokeSQLStatement({
preparedStatement : procedure1Statement,
parameters : [param]
});
}
/
************************************************************************
*******
* Implementation code for procedure - 'procedure2'
*
*
* @return - invocationResult
*/
function procedure2(param) {
return WL.Server.invokeSQLStoredProcedure({
procedure : "storedProcedure2",
parameters : [param]
});
}
/
************************************************************************
*******
* Functions that correspond to JSONStore client operations
*
*/
var selectStatement = WL.Server.createSQLStatement("select COLUMN1, COLUMN2
from TABLE1");
function getSamples() {
return WL.Server.invokeSQLStatement({
preparedStatement : selectStatement,
parameters : []
});
}

44

var addStatement = WL.Server.createSQLStatement("insert into TABLE1 (COLUMN1,

COLUMN2) values (?, ?)");
function addSample(param1) {
return WL.Server.invokeSQLStatement({
preparedStatement : addStatement,
parameters : [param1]
});
}
var updateStatement = WL.Server.createSQLStatement("update TABLE1 set
COLUMN1=?, COLUMN2=?");
function updateSample(param1) {
return WL.Server.invokeSQLStatement({
preparedStatement : updateStatement,
parameters : [param1]
});
}
var deleteStatement = WL.Server.createSQLStatement("delete from TABLE1 where
COLUMN1=?");
function deleteSample(param1) {
return WL.Server.invokeSQLStatement({
preparedStatement : deleteStatement,
parameters : [param1]
});
}
var insertst = WL.Server.createSQLStatement("insert into sample2 (name, mobileno, bg,
street, city, country, drink, std, pin) values (?,?,?, ?, ?, ?, ?, ?, ?)");
function insertreg(name, mobileno, bg, street, city,country, drink, std, pin) {
return WL.Server.invokeSQLStatement({
preparedStatement : insertst,
parameters : [name, mobileno, bg, street, city, country, drink, std,
pin]
});
}
var searchreg= WL.Server.createSQLStatement("select name, mobileno, bg, street,
city,country,pin from sample2 where std=? and bg=? and dnd='act'");
function getdonor(stdcode,bg)
45

{
return WL.Server.invokeSQLStatement({
preparedStatement : searchreg,
parameters:[stdcode,bg]
});
}
var dndlogin1= WL.Server.createSQLStatement("select street, bg from sample2 where
mobileno=?");
function dndlogin(dndmno)
{
return WL.Server.invokeSQLStatement({
preparedStatement : dndlogin1,
parameters:[dndmno]
});
}
var dndupdate1 = WL.Server.createSQLStatement("update sample2 set dnd=? where
mobileno=?");
function dndupdate(dndvalue, mobile) {
return WL.Server.invokeSQLStatement({
preparedStatement : dndupdate1,
parameters : [dndvalue, mobile]
});
}

46