Blood Donate Android Mobile Application

by

CS18-01
Department of Computer Science
School of Computing & Informatics Technology

A Project Report Submitted to the

School of Computing and Informatics Technology for the Study Leading to
the
Award of the Degree of Bachelor of Science in
Computer Science of Makerere University

Supervisor:
Dr. Ernest Mwebaze

Department of Computer Science

School of Computing & Informatics Technology
emwebaze@cis.mak.ac.ug Tel: +256414540628 Fax: +256414540620

May, 2018
Dedication

We dedicate this report to the Almighty God without whom we can do nothing. We further
dedicate it to our parents and guardians for their unceasing and selfless support throughout our
stay in this university.
We are proud of you, family members for the unforgettable sacrifices you made to see to it that
we reach this far in our education journey.
This report is dedicated to our sponsors, the government of Uganda for the government sponsor-
ship Brian, Stephen and Ivan attained and Mastercard Foundation for sponsoring Musa throughout
the three years. We are privileged by all facilitations you made.
We further dedicate it to our lectures in the department of Computer Science at the School of
Computing and Informatics technology especially to our supervisors Dr. Ernest Mwebaze and
Mr.Lule Emmanuel.

iii
Acknowledgement

We would like to express our sincere appreciation to our supervisor, Dr. Ernest Mwebaze for the
tremendous guidance since the start of the execution of this project. From the concept preparations
throughout to the Report submission stage, his input has been an invaluable and welcome addition
to that has enabled us come this far. We would also like to thank Mrs. Rose Nakibuule from the
Artificial Intelligence Labs for her suggestions and demonstration especially in the phase pertaining
to coming up with a mathematical model on which the incentive scheme would run. Our sincere
gratitude goes out to all our lecturers and members of staff of the Department of Computer Science,
Makerere University for making our education experience worthwhile and highly enlightening. We
acknowledge the guidance and consistent reminders from our projects coordinator, Mr. Lule Em-
manuel, a senior lecturer in the department of Computer Science. We thank you for tolerating with
us and supporting us every now and then.
Many thanks go out to members of the Computer Science class for the three year experience that
has been nothing short of grueling. It was an honor sharing a comprehensive education experience
with all the ladies and gentlemen of the BCSC class. We are immensely indebted to our parents for the
love, patience and sacrifice invested to get us to this level of education. It is never an easy endeavor
facilitating the education to the stage of completion, therefore we appreciate the endurance through
trying times and are forever thankful to the effort put into our education. Lastly, appreciation goes
to the CS18-01 team for the cooperation in getting this project over the finish line. It was never
going to be an easy ride, but dedication, sacrifice has seen us through whatever barricades stood in
our way.

iv
List of Figures

2.1 Shows the architecture of E-Blood Donation system . . . . . . . . . . . . . . . . . . . 5

2.2 Registration and login activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Interfaces for Revive Blood Donation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Interfaces for Blood Donation Application . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 Interfaces for Friends2Support.org Application . . . . . . . . . . . . . . . . . . . . . . 10

4.1 Use case diagram for a donor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Use Case Diagrams for hospital and blood bank. . . . . . . . . . . . . . . . . . . . . . 15
4.3 Shows the list of tables used in our database, project . . . . . . . . . . . . . . . . . . 17

5.1 phpMyAdmin interface on the server . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2 Overview of the project Structure in Android studio and AndroidManifest.xml . . . . 20
5.3 List of all the xml files we used in the application and the home page . . . . . . . . . 21
5.4 Home page , donor and hospital SignUp interfaces . . . . . . . . . . . . . . . . . . . . 22
5.5 Blood bank homepage, Hospital home page and Sign In Pop-up . . . . . . . . . . . . 22
5.6 Giving points, Donating Blood, Editing blood capacities . . . . . . . . . . . . . . . . 23
5.7 List of all the Java files we used in the implementation of the Client Side. . . . . . . 25

v
Contents

Declaration i

Approval ii

Dedication iii

Acknowledgement iv

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Main Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.2 Specific Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Significance of the Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 To the Blood centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2 To the donor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.3 To the recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Literature Review 5
2.1 E-Blood Donation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Mobile Blood Donor Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Revive Blood Donation Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Blood Donation Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Friends2Support.org Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Comparison with Blood Donate Android Mobile Application . . . . . . . . . . . . . . 9

3 Methodology 11
3.1 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Direct Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Online sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6.1 Database Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6.2 Server Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6.3 Application Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.7 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.8 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.8.1 Design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

vi
 3.10 Goals and expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Systems design and analysis 14

4.1 System Architecture and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Android SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3 Android Emulator and Device . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.5 PhpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Implementation of Blood Donate 18

5.1 Server Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.1 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.2 PHP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Client Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 Development Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.3 Java classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Reward System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.1 Mathematical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.2 Blood Type ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.3 Implementation of mathematical model . . . . . . . . . . . . . . . . . . . . . 26
5.3.4 After loyalty points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 Conclusion and Future Works 27

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vii
Chapter 1

Introduction

Limited supply of blood in Africa is a serious problem. According to the World Health Organization,
out of the 75 countries that report fewer than 10 donations per 1000 people, 38 of them are from
Africa. There is need to solve the problem of very few donations of blood. Throughout this document
we describe an android application that can be used to create a network of blood donors to increase
the amount of blood units in stock within Uganda through voluntarism and motivation of blood
donors.

1.1 Background
Only one per cent of Ugandans donate blood regularly. According to Dr. Dorothy Kyeyune Byabazire
the director Uganda Blood Transfusion Services (UBTS),[2] the response from the adult community
as regards donating blood is very low and this, among other factors has led to shortage of blood at
the blood banks.
According to [1] Uganda can only meet 240,000 units of blood yet the World Health Organization
recommends a country to have units of blood equivalent to one per cent of the population of that
country. This shortfall is of great concern to the health sector and therefore efforts need to be made
to tackle this deficiency and increase the number of blood donors.
The Uganda Blood donation Services being centrally coordinated at regional centers renders
inefficient services to all regions of the country in form of sensitization and mobilization, this is due
to limited access to all places within the country hence the need for a mobile application that fulfills
this gap.
There are inconsistent practices with no guidelines to bring about harmonization and essential
uniformity of collected data at the hospital level and partner organizations, the poor management
of the blood and donors records at the blood bank hence increasing delays in handling the blood
requests from the hospital during critical moments due to too much use of paper work.
This Bureaucratic process of data sharing with partner organizations like Uganda Red Cross
Society makes data sharing and donors network update hectic hence the need for mobile application
that will be used create and update the network of blood donors and their profiles regardless of the
partner organization used.
The poor funding results into limited manpower, there is lack of hospital transfusion committees to
mobilize blood donation around hospitals and also a small task force to carry out donor mobilization
and management hence the need for mobile application that fulfill this gap. A key challenge and
constraint for Uganda blood centers is to expand blood collection capacity to meet the increased
national blood demand especially at health Center IVs when they become fully operational, the task
of meeting the increased demand at Health Center IVs, which are located in rural areas where most
of the population lives.
Most of the blood is used for transfusion of children and mothers; 50% of all blood collected
is for treating children with severe anemia, largely due to malaria, intestinal worm infestation and

1
malnutrition; a further 25% of the blood is required to treat pregnant women with anemia and
complications of child birth and 25% to treat accident or surgical cases, this calls for the need for
mobile application that fulfill this gap through the increased mass outreach and sensitization and
seduction of the people to join the blood donation campaign.
There is inadequate publicity and advocacy for blood donation activities, the need to invest in the
development of sustainable partnerships with the consumers (hospitals) and suppliers (community).
Societal interface is still weak. This is exhibited by the high percentage of one time only donors
hence the need for mobile application to encourage people to keep donating blood so that it fulfills
this gap.
Basing on the above discussion, any citizen (Ugandan) should realize the importance of donating
blood. Blood is the most precious gift that anyone can give to another person. According to [5],
Blood transfusion is needed for:

1. Women with complications of pregnancy, such as ectopic pregnancies and haemorrhage before,
during or after childbirth.

2. Children with severe anaemia often resulting from malaria or malnutrition.

3. People with severe trauma following man-made and natural disasters.

4. Many complex medical and surgical procedures and cancer patients.

5. Regular transfusions for people with conditions such as thalassaemia and sickle cell disease and
is used to make products such as clotting factors for people with haemophilia.

1.2 Problem Statement

The android Blood Donate application aids to fill the prevailing information void that has resulted in
a shortfall of blood donors and also demystify the eligibility conditions in order for one to become a
new donor whilst catering for their registration as blood donors, providing information about access
to blood centers and including a provision for one to make appointments to donate blood.
The major reason why there is a shortfall in the amount of blood donated is the lack of an
incentive mechanism to attract blood donors. Blood donate aids to join various donors on a single
platform by creating a network of blood donors, motivating more people to join and increase the
number of blood donations in Uganda.
The application wants to establish a network of people who each know their respective blood
groups to ease the classification and collection of blood in the field and to shorten the testing process
at critical times of saving lives especially before blood transfusions.

1.3 Objectives
1.3.1 Main Objective
The main objective was to develop a mobile android application that creates a network of blood
donors, motivates more people to join and increase the number of blood donations in Uganda.

1.3.2 Specific Objectives

The specific objectives of the study were:

i. To design an android mobile application that registers all potential donors and keeps track of
their donations with various blood banks.

2
 ii. To implement a reward system that motivates people to use the application and mobilize other
people to join the network of blood donors.

iii. To test the effectiveness of notifying blood donors about blood camps for donations, nearest
blood centers and recipients need for blood of their respective blood groups.

1.4 Significance of the Study

The application helps blood banks to increase the units of blood collected. Data collected from
donors can be used by blood centers to organize blood drives or camps in areas with potentially
great number of blood donors. The system will rely on a central database where all information
about blood banks, hospitals and blood donors is integrated to ease the search for information.
Through making a network of people who are willing to donate blood, this will increase the number
of units of blood collected.

1.4.1 To the Blood centers

This application timely update the information regarding the donors where the administrator accesses
the whole information about Blood Donate system. Using data visualization based on location of
blood donors, the application will show areas rich of potential blood donors. This can help blood
banks organize blood camps at those specific locations to increase on the amount blood units in stock.
The system will enable blood banks not to overwhelm donors with excess donations by utilizing the
eligibility test proposed in the methodology section.

1.4.2 To the donor

The application helps build a network of people who can help each other during an emergency. The
project help donors view data of their past donations records, remind him on his next donation, and
also update him on patients who are in need of his blood type through notifications. The android
application will be updating donors on their next camps of blood donation to be held and the number
of blood units they have donated. When a donor reaches 5 donations, his donor card will be eligible
to be used by 6 patients. The system guarantees donors safety. A donor shall not make excess
donations in a very short interval (based on the eligibility test) because that might compromise
his/her health.

1.4.3 To the recipient

Within this document, a recipient is a person who will be in need of blood. Every person who
registers can be both a donor and recipient. If a user is ready to donate blood, he qualifies to be a
donor and on the other hand, a recipient is a user in need of blood.
This application helps a recipient to select the right donor instantly using medical details along
with the desired blood group and reduce the time spent in searching for the blood bank with respective
blood group.
The application will enable a recipient to view the donors location and a few necessary details as
submitted by the donor during registration. Blood-Donate will enable recipients communicate with
blood donors using the contact details of the donor in the central database that are availed after
searching.

3
1.5 Project Scope
This android mobile application Blood-Donate is a mobilization tool for organizations that carry out
blood donation drives in Uganda. The application was designed to maximize the blood donation
potential of millions of healthy smartphone owners which is currently underwhelming given that the
degree of voluntarism is low, with different blood collecting organizations resorting to schools among
other institutions of learning in order to organize the blood donation drives.
By maximizing the blood donation potential of the healthy smartphone users, there will be a lot
more blood units in stock for when patients require it while also going along way in enabling Uganda
improve its compliance in ensuring the number of blood units in stock corresponds to the 1% of the
total population as per World Bank Regulations.
More specifically, the application is designed to pull a lot more smartphone users to download the
application and donate blood by incentivizing the entire process through making use of loyalty points
whenever one downloads the application and donates blood. It also facilitates the dissemination of
information about blood donation drives to the application user via notifications.

4
Chapter 2

Literature Review

This literature review shines a spotlight on the already existing blood donation related systems.

2.1 E-Blood Donation System

According to Deeptha. H [4] the E-Blood Donation System Using Location Tracking is a system
that bridges the gap between blood donors and the people in need for blood. It synchronizes blood
donors and users with the help of Internet and through it, registered users can view the availability
of donors and can send Request for blood to the donor matching with blood requirement and can
be ordered online when required. The Android application can be accessed only by the donors to
receive the blood donation notifications and the requesting users and hospitals to search the nearest
donors and notify them. The functionality of the E-Blood Donation System resembles that of [3] A
FRAMEWORK FOR A SMART SOCIAL BLOOD DONATION SYSTEM BASED ON MOBILE
CLOUD COMPUTING proposed by Almetwally, M. C.

Figure 2.1: Shows the architecture of E-Blood Donation system

After installation of the application a user is provided with two options: Login and sign in. If
the person has already registered, then he/she has to login. If not, he/she has to create an account
providing basic details like name, address, contact, date of birth, blood group, email id etc. Once
the user registration is complete, he/she can check various blood banks that are located. The user
gets various options on screen:

1. Search Donors

5
 2. Request for blood

3. View contact for donors

The user can select any of the option and according to the selected option he/she will get the
information. The user can also get the exact path from his/her location to blood bank or hospital
by using Global Positioning System (GPS). The details of the blood banks, hospitals etc are saved
in database and only the administrator has access to the database.
This application has the following results: The system provides very less paper work and turns the
present manual system in to computerized system. This provides a means to connect people who are
in need of blood and willing donors. With the application, blood donation becomes more effective.
The system also helps to reduce the time required to deliver required blood to the needy in cases
of emergency. The Android application can also be used by the people interested in donating their
blood by locating their nearest blood bank. The web application provides a way of communication
between the hospitals and the blood banks.

Figure 2.2: Registration and login activities

Figure 2.3: Searching

2.2 Mobile Blood Donor Tracker

The Mobile Blood Donor Tracker proposed by Samy. S, [6] is a mobile application that connects
users with Blood Centers to facilitate the blood collection from donors during emergencies, facilitate

6
the communication of blood donors with each other and facilitate the communication of blood donors
with the Hospital blood center. It is an application developed by making use of the following tech-
nologies: MySQL database-used by the application to manage the low-level work of data by sending it
commands, Service based location-a software application for IP capable mobile devices, Android-the
Linux based open source platform backed by Google, and the Android System Architecture, among
others.
The documentation on this application makes a case for leveraging the increasing number of
smart phone users to enhance the effectiveness of blood donation.
The number of smart phone users globally will exceed 2 billion in 2016, according to new statistics
from e Marketer-after almost getting there in 2015. Next year, there will be more than 1.91 billion
smart phone users nationwide, a figure that will boost an extra 12.6% close to 2.16 billion in 2016.,
their paper quotes before going on to propose a mobile blood donor tracking system application that
works on Android smart phones.

Figure 2.4: Use case diagram

2.3 Revive Blood Donation Application

Revive is a blood donor finding android application which will helps users to find nearby donors
and for donors to find blood requests. This application works to create a bond between blood giver
and receiver. It will make the blood search much easier for who are seeking it. This works both for
the giver and receiver. The searcher can request blood through this application and eligible giver is
issued a notification through the application. If any donor is not eligible he/she is not notified.
This only notifies givers who are around the particular area from where the request was initiated.
While registering on the application a question is asked to a donor about how far (distance) he/she
would want to go in kilometers to effect a donation with respect to the donor given location. After
giving blood once, the application does not notify the donor before a 3 month period elapses. As for
the user who requests, he can he/she can send an SMS to all nearby donors (eligible blood donors) or
a message about his/her request with the hospital name and remaining time so that a donor doesn’t
need to be connected to the Internet to get notified. A user can also make a request on behalf of
someone else and can become donor anytime and join the lifesaving community and also obtain the
nearby blood bank contact numbers in case of an emergency.

7
 Figure 2.5: Interfaces for Revive Blood Donation

2.4 Blood Donation Application

This is an android application that helps needy people to search out nearest possible donors. This
application enables one search out the registered donors for specified area / location while sending
SMS to the filtered people matching your blood group requirements.

2.5 Friends2Support.org Application

Friends2Support.org is an android mobile application that enables Blood donor registration upon
OTP verifications. This refers to One Time Pass code that verifies a users email address or mobile
number during registration by the submission of a one-time pass code. Once the OTP is entered,
it is verified and the user gets registered. Blood donor’s login, edit, delete profile, change password,
Location based voluntary blood donors search , You can call donor directly, Send SMS and WhatsApp
donors details.

8
 Figure 2.6: Interfaces for Blood Donation Application

2.6 Comparison with Blood Donate Android Mobile Appli-

cation
The common theme among all the reviewed existing works as far as blood donation application
concepts are concerned is that there is an overwhelming need for the spirit of voluntarism on the
part users of the application (especially for the donor side) in order for them to actualize an ambition
big as increasing number of blood donations. This means that in locations where individuals do
not necessarily register a rampant culture of voluntarism, blood unit shortfalls would become an
everlasting specter which is a problem Uganda is currently facing. Therefore dependence on the
voluntary capabilities cannot simply be an option as far as improving our blood stocks is concerned.
This is where Blood Donate comes in with an incentive mechanism for donors and stakeholders in
the blood donation field. Donors do not have to solely rely on voluntarism as the main motivation for
getting more blood donors on board. This is to be done through the integration of loyalty points that
will be earned whenever someone donates blood or recommends the application to another party and
they are able to download it. This brings into play another reason for people to donate other than
voluntarism and the regular t-shirt, biscuits and soda and is therefore, what makes our application
concept different from the existing works.

9
 Figure 2.7: Interfaces for Friends2Support.org Application

The spending of loyalty points entirely depends on the blood donor. Whether to claim an award
or gift, give some of his points to another blood donor or use the loyalty points to obtain medical
service especially blood transfusion services.

10
Chapter 3

Methodology

3.1 Research Design

The research for the development of the Blood Donate android mobile application was undertaken
by way of qualitative and quantitative approaches in order to obtain the necessary data we needed
with regards to aspects of the blood donation process such as donation intervals, blood type rations
with respect to population among other vital information. This was to aid us in the development of
an incentivized blood donation application.

3.2 Data Collection

The development of a reward system or mechanism required us to do research on the different blood
types and we found out that there were eight blood types that is O+, O-, A+, A-, B+, B-, AB+,
and AB-. After establishing the existing blood types, research was done on which blood types have
a dominant percentage in as far as a carrier population is concerned.
This data was important as it enabled us establish which blood types would be hardest to source in
the eventuality of emergencies or in any other case scenarios that required blood donation. Research
was also carried on the donation intervals pertaining to the blood donation process. We found that it
was recommended that donors wait a total of three months before making their next donation. Which
brought us to the conclusion that one would donate blood a total of 4 times in a year. This data
was especially important as we had to factor it in, especially in the formulation of a mathematical
model upon which the reward system would run.

3.3 Direct Interviews

This involved reaching out to people that had donate blood. This was in a quest to find out the blood
donation procedures and whether similar donation procedures cut across the various organizations
that carried out blood donation drives. Some of the interview questions included: What were you
asked for when you went to donate blood? Have you ever received a call to give blood in an emergency
situation? What inspires you to donate blood?

3.4 Online sources

The web is rich in information and therefore we used it to perform research on aspects like the global
perspective in as far as blood type ratios are concerned with respect to different nations to ascertain
whether there is a general correlation with that in Uganda. We also researched the problems causing
general blood stock outs or shortages; a situation that came to the fore in late 2017 and early 2018;

11
with the main discovery being that blood was being sourced from student populations who were home
for the holidays at the time, while an inherent lack of voluntarism among the general population was
also a major factor in the failure of the country to have the recommended blood volumes in stock.
Research was also done on the response of many corporate organizations to the existing blood
shortage. According to our findings, companies did attempt to fulfill their corporate social respon-
sibilities with organizations like National Social Security Fund (NSSF), UMEME and Capital FM
among others, organizing blood donation drives in a bid to stem the blood shortages at the various
hospitals. This was important information because we sought to leverage such organizations keenness
to fulfill their social responsibility to facilitate the rewards section of our application.
The application contains a reward section that donors who have accumulated certain amounts
of loyalty-points would be eligible for certain rewards. Partnerships with organizations like the
ones mentioned above would enable us impart both variety and numerousness in the rewards that
consistent donors would be eligible for.

3.5 Data Analysis

Analysis of the data collected was performed. The research on the different blood types enabled
us establish which blood types were the rarest to come by in the populace and which blood type
would be the easiest to mobilize. The minus blood types that is (O-, A-, B-, AB-) were found to
have significantly lower percentages compared to the plus blood types (O+, A+, B+, AB+). Such
percentages were very vital in the development of a reward system.
Regarding the interviews held with blood donors, this intended to establish the nature of incen-
tives that the current blood donation procedures served to blood donors and also aid us in coming
up with a logical and more efficient reward system to motivate people to donate blood. Our findings
indicated that aside from the usual soda and biscuits that were offered after blood donation was
done, along with the occasional offer of T-shirts, the grounds were ripe for the establishment of more
attractive rewards to offer to blood donors.
In keeping with our strategy to come up with a more viable reward system, we did research on
the viability of bringing corporate organizations to facilitate the provision of rewards for the rewards
section. After one obtained loyalty points as per the mathematical model, we wanted to provide a
means to make those points worth something that is the rewards catalogue where items could be
claimed by a user after accumulation of a necessary number of points through carrying out donation.
The information from the online sources indicated that there were possibilities that the corporate
organizations that had on previous occasions organized blood drives, could be persuaded to also
facilitate the rewards section of the application.

3.6 Implementation
3.6.1 Database Implementation
A number of databases were created using MySQL. The reward system required a database that
contained blood pack numbers which would be used after a user had donated blood. A user would be
required to enter a blood pack number that corresponds to that in the database after which points
would be awarded accordingly.

3.6.2 Server Implementation

The server side was implemented using php and was connected to the application, Blood Donate
using JSON.

12
3.6.3 Application Development
For the user to interact with the system services, Blood Donate Android Application was created to
provide the User interfaces to the system services. This was implemented in Android studio software
using both XML for customizing user interfaces and JAVA for functionality of the backend in the
application. The application also connects to both the server program and the database using JSON.

3.7 Testing
During the implementation phase, unit testing was done to ensure all modules are built correctly so
as to perform the operations intended. System integration testing was done to ensure that all the
system modules function as intended.

3.8 Evaluation
3.8.1 Design decisions
All project designs as based on research were very vital in the implementation of the all project.
The use of a server program provides a centralized nature of the operation of the whole project. As
per our prototype, the blood pack numbers to be used by donors on the blood pints are entered into
the central blood pack database at the server end after which a blood donors pack number can be
validated in order for them to obtain points.

3.9 Tools
The Android studio and Wamp Server as used in the implementation of the application and the server
Program respectively provided ease and flexibility. These enabled use of other external libraries in
the application.

3.10 Goals and expectations

The project is at a prototype stage. Therefore despite the fact that it has been found to be working
in as far as awarding points to blood donors is concerned, it is still not ready for public use as it
still requires more work in implementing a more efficient and robust mode of Reward Claiming not
to mention the continued research that needs to be put into further enhancing the mathematical
model to probably include more variables that could have been overlooked. The project is currently
providing the set objectives and the remaining partially unfulfilled objectives are either long-term or
will be achieved during usage and restructuring of the project designs.

3.11 Summary
In the available time, the project has created a promising incentive scheme geared towards motivating
persons to donate blood either voluntarily at blood donation drives or in response to emergency
situations as broadcast in the application by hospitals. To sustain the project to maturity, it should
be considered a viable option in getting the general public especially smart phone users to donate
blood in order to boost the blood volume stock at the blood banks and decrease our reliance on the
student population as the countrys main source of blood.

13
Chapter 4

Systems design and analysis

4.1 System Architecture and Requirements

4.1.1 System Requirements
There are certain requirements that should be met for Blood Donate to meet its objectives. Require-
ments are classified into client and server-side requirements.
1. Server side requirements
i. The server should be an SQL server supporting PHP.
ii. At the server, there should be a relational database comprising of the various tables used.
ii. Database must be able to communicate with the client side application.
2. Client requirements
a. The client side must have a user interface.
b. The client application must be compatible with most android devices.
c. It should have the ability to store and retrieve data from the database at the server.
d. The client device should be connected to the internet.
e. The client should allow the application to access his/her phone gallery and camera.

4.1.2 System Architecture

System architecture is the conceptual model that defines the structure and behavior of a system.
Blood Donate application consists of an Android application on the client side and PHP-MySQL
application on the server side. The Android application is the part visible and available to the user
for interaction while the PHP/MySQL-based server-side component serves intermediary between the
Android application and the database on the server.
There are three types of users within the application namely;
1. Donor. A donor is the kind of user who will signup into the Blood Donate with aims of
donating blood, searching for fellow blood donors, get a reward by accumulating points, view
blood banks’ notifications and hospital’s emergencies.
2. Hospital. Hospitals are only responsible for sending emergencies to donors with a blood type
of the victim or patient or a blood type that can donate to the patient.
3. Blood Bank. Blood banks’ role is to sign up with BloodDonate, Sign in, edit the amount or
quantity of blood they have in stalk and send notifications of blood drives or camps to all
donors.

14
 Figure 4.1: Use case diagram for a donor.

Figure 4.2: Use Case Diagrams for hospital and blood bank.

4.2 System Design

Blood Donate was designed basing on the requirements in 4.1.1. In the design we employed various
tools. The project tools and technologies used include the following.

4.2.1 Android
Android is an Open Source software stack for mobile devices like phones and tablets. The stack
comprises of a Linux-based kernel, middleware and mobile applications. It is developed by the Open
Handset Alliance spearheaded by Google Inc. It is licensed under the Apache Software License, 2.0
, which is commonly abbreviated as Apache 2.0.

15
 We chose Android for this project, primarily for the open-source nature of the platform as well as
the ease of development and deployment with the extensive supports provided on the official Android
website and major developers forums, such as the android developer’s official website. Android also
has the largest market share and has native compatibility with tablets. It also supports cross platform
application development, i.e. developers can develop Android application in Mac, Windows and many
UNIX-based operating systems like Ubuntu.

4.2.2 Android SDK

An Android application can be developed using an Android SDK and a compatible software devel-
opment environment. The Android SDK provides developers with the necessary set of tools and
libraries needed to build, test and debug applications on the Android platform. It is readily available
for download, along with needed support, on the Android official website.
Android Studio is the official integrated development environment (IDE) for Google’s Android
operating system, built on JetBrains’ IntelliJ IDEA software and designed specifically for Android
development. We used Android Studio version 3.1 throughout the implementation process.

4.2.3 Android Emulator and Device

The Android SDK provides an emulator, which is a virtual mobile device, which runs on the computer
and enables the user debug and test applications without a physical device. The specification of the
emulator is defined, and can be edited, by the developer using the AVD Manager, which is a graphical
user interface used to configure and manage AVDs. The AVD can be configured as different devices,
screen sizes, Android target levels. For this project, we configured the AVD as a Nexus device with
a screen size of 4.65 inches with a resolution of 720 by 1280 pixels. The AVD runs Android Jelly
Bean, version 4.2.2, which is equivalent to API level 17.
We also tested our application on various categories of android phones.

4.2.4 MySQL
MySQL is a cross-platform open source relational database management system (RDBMS). We cre-
ated a database, project, that holds all our tables used in the application. The tables we used include;
blood bank quantity, blood pack, bloodBankRegistration, centerNotifications, donor, donorPoints,
hospitalEmergency, hospitalSignUp,ratioOfPeopleWithBlooType and rewards as shown in figure4.3.

4.2.5 PhpMyAdmin
PhpMyAdmin is a free and open source GUI tool written in PHP, which is used for web database
administration. It has cross-platform support for the major operating systems and it was first
released in the 1998 under the GNU General Public License. It has an intuitive web interface, and
core support for many MySQL features. It also has data management (including import and export)
support for many formats like CSV, SQL, PDF, XML, among others. For Blood Donate project,
the MySQL database was managed and manipulated easily using phpMyAdmin because it is easy to
manipulate graphical user interface.

16
Figure 4.3: Shows the list of tables used in our database, project

17
Chapter 5

Implementation of Blood Donate

5.1 Server Implementation

This section deals with data retrieval and storage from the database, initiated by HTTP request from
the client-side application. PHP is used to handle the request from the application and performs
appropriate tasks on the MYSQL database. It also informs the application of success or failure of
the application, Blood Donate. The PHP development was done in the Notepad++ software, which
is a free and open Windows multi-language editor. It provides colored support for native functions,
as well as code indentation.
The server database was managed by a free PHP-based GUI tool named phpMyAdmin which
was readily available on the PHP website.

Figure 5.1: phpMyAdmin interface on the server

5.1.1 Database Design

The database for the project was designed based on the requirements listed in section 4.1.1. A table
named ’donor’ was used to store details about the blood donors. Details were a unique userName,
fullNames, email, contact, village, city, specialID, gender, bloodType, dOB, image, password. The
specialID was the primary key and it is incremented automatically whenever a new donor signs up.
It is used in the award of loyalty points in the mathematical model. Hospital details are stored in
a table called ’hospitalsignup’ with the following columns, userName, hospitalName, address, email,
contact, image, password. Blood banks on sign up, submit userName, bbName, address, email,
contact, image and password to the table ’bloodbankregistration’. Blood banks send notifications
to donors about the upcoming blood donation camps. Details of these notifications are stored in a

18
table ’centernotifications’ with columns, notificationID, today(current time),bloodCenter, date, title,
message, link. The link is a url to a google form that caontains eligibility test questionnaire.
Another table named ’blood bank quantity’ holds the amount of blood per blood type for each
registered blood center. It has columns like, id, userName, a, a , b, b , o, o , ab, ab . A table
’blood pack’ contains id, packNumber, bloodBank . When a donor is to receive loyalty points after
donation of blood, the donor fills the packNumber on his/her pack the application checks in the
database, ’blood pack’ table for the filled packNumber. If it exists the donor receives the points.
After filling that packNumber and evaluation has been done, the respective packNumber is deleted
from the table.

5.1.2 PHP Files

Twenty PHP files listed below were created to handle the logical and data management operations
between the clients and the database on the server.

a. bloodBankRegistration.php

b. bloodBankSigningIn.php

c. bloodBankUpdateQuantity.php

d. centerNotifications.php

e. donorCalcPoints.php

f. donorDonate.php

g. donorFullList.php

h. donorGivePoints.php

i. donorPoints.php

i. donorRegistration.php

j. donorRegistrationUpdate.php

j. donorSigningIn.php

k. donorUseRewards.php

l. getEmergencyHospital.php

m. getNotificationsDonor.php

n. getRewards.php

o. hospitalEmergency.php

p. hospitalSigningIn.php

q. sendEmergencyHospital.php

r. sendNotificationBloodBank.php

19
5.2 Client Implementation
The client-side application is designed based on the requirements stated in 4.1.1, using the right sets
of libraries, database design and programming methods while providing a good user experience.

5.2.1 Development Overview

Blood donate android mobile application was developed using Android Studio IDE version 3.0.1 and
gradle version 4.1 with the help of the Android SDK downloaded from the Android official website.
The application uses a package that contains all the java classes.
The application is configured to a minimum API level of 15 and declares permissions in the An-
droidManifest.xml that include, WRITE EXTERNAL STORAGE, READ EXTERNAL STORAGE
INTERNET, ACCESS NETWORK STATE, ACCESS FINE LOCATION, ACCESS COARSE LOCATION
and CAMERA functionalities of the system.
All the titles of the application are defined under the application tag, along with the list of
components and libraries used.

Figure 5.2: Overview of the project Structure in Android studio and AndroidManifest.xml

5.2.2 User Interfaces

User interfaces were designed in XML, eXtensible Markup Language. Android uses a number of
resources and the ones we used include;

i Drawable.

ii Layout.

iii Mipmap.

20
 iv Menu.

v Values.

vi Xml.

In the layout resource/folder, we wrote twenty six .xml files which were our user interfaces. Each
layout file had a corresponding Java class that handles the manipulation within that Activity. The
results of the layout files are shown in the following figures obtained from our Blood Donate android
mobile application prototype.

Figure 5.3: List of all the xml files we used in the application and the home page

5.2.3 Java classes

Every Interface had a java class responsible for monitoring the Activity. Using the Activity class we
override the onCreate method and set a ContentView to the respective layout/xml files and by that
the Java class and XML files would be linked together. An activity is a single screen in android.
Java classes we used are listed below;

a. BloodBankDonorsActivity.java
The class sets a content view to the layout activity blood bank donors which contains a list
view. Each item in the list View, is comprised of the image of the donor, name, and blood
type. Generally , the class fills the list view with a list of available blood donors.

b. BloodBankSendNotificationActivity.java
The class is responsible for helping a blood bank send notifications to the database. It sets a
content View to the layout activity blood bank send notification which contains a form contain-
ing details of the notification message.

c. Donor.java
Donor.java contains setters and getters for the details of a donor. It comprises of a constructor
that contains the name, email, phone, blood type and image of a specific donor.

21
 Figure 5.4: Home page , donor and hospital SignUp interfaces

Figure 5.5: Blood bank homepage, Hospital home page and Sign In Pop-up

d. DonorAdapter.java
It is an adapter that obtains its data from what is set by the setters and returned by the getters
of the Donor.java class.

e. DonorEmergencyActivity.java
Its role is to download emergencies from our database and prevail them to the donor. It
uses getEmergencyHospital.php, a script for returning the available emergencies sent by various
hospitals.

22
 Figure 5.6: Giving points, Donating Blood, Editing blood capacities

f. DonorNotificationsActivity.java
Its role is to download blood bank notifications from our database and prevail them to the
donor. It uses getNotificationsDonor.php, a script for returning the available notifications sent
by various blood banks.

g. EditProfileActivity.java
The class is responsible for directing a donor, hospital or blood bank to the respective Sign up
fragments to enable them edit their details and update them in the respective sign up tables
in the database.

h. Emergency.java
Emergency.java contains setters and getters for the details of an emergency. It comprises of a
constructor that contains the emergencyID, hospitalName, date, title and message.

i. EmergencyAdapter.java
It is an adapter that obtains its data from what is set by the setters and returned by the getters
of the Emergency.java class.

i. ForotPasswordActivity.java
It is a java class that sets a content view to a layout activity forot password that enables a user
to fill in a few of his or her details in order to request for a new password.

j. HomeBloodBankActivity.java
After a blood bank signs in, it is redirected to this activity. HomeBloodBankActivity.java sets
a content view to the layout activity home blood bank which displays the name, image of a
blood bank and a form for editing the amount of blood in stock for the respective blood bank.

j. HomeDonorActivity.java

After a donor signs in, it is redirected to this activity. HomeDonorActivity.java sets a content
view to the layout activity home donar which displays the details of the respective user using

23
 . It also displays the available notifications to the donor in a scrollable list view. It uses a php
script getNotificationsDonor.php to return the available notifications for the user.

k. HomeHospitalActivity.java
It sets a content view to a layout activity home hospital that displays the image, name and a
form for sending emergencies to the database.

l. MainData.java
MainData.java contains the IP address of the server, a computer with our database. It also
contains variables that are links to the directory of the various php files and a folder where
store our images.

m. MyDividerItemDecoration.java

n. Notification.java
Notification.java contains setters and getters for the notifications from a blood bank. It com-
prises of a constructor that contains the notificationID, today, bloodCenter, date, title, message
and link.

o. NotificationAdapter.java
It is an adapter that obtains its data from what is set by the setters and returned by the getters
of the Notification class in Notification.java.

p. Reward.java
Reward.java contains setters and getters for the notifications from a blood bank. It comprises
of a constructor that contains the id, image, name, description, points, quantity.

q. RewardActivityInterface.java

r. RewardsActivity.java
It implements the interface RewardActivityInterface. It uses the php file, getRewards.php that
returns a list of available rewards to the user.

s. RewardsAdapter.java
It is an adapter that obtains its data from what is set by the setters and returned by the getters
of the Reward class in Reward.java.

t. SearchDonorActivity.java
The activity enables a donor to search for a fellow blood donor by name and blood type. On
search, a list of donors is returned as per the search.

u. SignInActivity.java
This is the home page of Blood Donate. It sets a content view to a layout activity sign in. The
layout has two edittexts that permit a user to submit userName and a password. On clicking
the Sign In button, the application pops up a window for a user to choose the type of account
he owns. We used hospitalSigningIn.php, bloodBankSigningIn.php and donorSigningIn.php for
signing in the hospital, blood bank and donor respectively.

v. SignUpsActivity.java
When the user has no a account with Blood Donate, on clicking Signup the application loads the
SignUpsActivity.java activity. This activity has three fragments for the users. Every fragment
has a interface containing a form for a user to fill in user details. We used donorRegistration.php,
bloodBankRegistration.php and hospitalSignUp.php for donor, blood bank and hospital to create
accounts.

24
 Figure 5.7: List of all the Java files we used in the implementation of the Client Side.

5.3 Reward System

5.3.1 Mathematical Model
With an aim of motivating blood donors we came up with a mathematical formula which we based on
to aid donors accumulate points. The mathematical model evaluates the amount of points a donor
has obtained. We based on four factors or conditions namely;

1. number of donations made by the donor (X).

2. the ration of people with a particular blood type (Y).

3. the amount of blood in storage per blood type (S).

4. number of recommendations made (Z) .

We assigned ratios to these four factors and came up with the formula below;

L = 2X + 5(Y + S) + 3Z

Where L is the number of loyalty points. Before the formula is evaluated, a donor receives 50
points immediately they sign up. This occurs once for every donor. We assigned the lowest ratio to
X, the number of donations because there is a limit on the number of donations a donor can make.
The next ratio was to the number of recommendations made by a donor. This helps to enlarge our
network of blood donors if more people know about it. Coefficient 5 was assigned to Y and S because
they are the most influential factors in our mathematical model.

25
5.3.2 Blood Type ratio
There are eight common blood types and that is A, B, AB, O but these can be further grouped
into A+, A-, B+, B-, AB+, AB-, O+, O-. Blood group A has only the A antigen on the red blood
cells and the B antibody in the plasma. Blood Group B has only the B antigen on red cells and the
antibody A in the plasma. The Blood Group AB has both A and B antigens on red blood cells but
neither the A nor B antibody are in the plasma. The Blood Group O has neither A nor B antigens
on the red cells but both A and B antibody are in the plasma. In addition to the A and B antigens,
there is a protein called the Rh factor which can be present (positive) or absent (negative). With
this background we delve in to the distribution of these blood types among the countrys population.
According to Wikipedia, Uganda with a population of 43,276,492 has got 43.7% of the population
with the blood group O+, 39.0% with A+, 10.7% with blood type B+, 3.9% with AB+, 1.3% for
O-, 1.0% with A-, 0.3% with B-and 0.1% with AB-.

5.3.3 Implementation of mathematical model

Currently in Uganda, blood packs contain pack numbers. In our implementation after a donor has
donated blood he can fill the pack number into our application. Only the blood bank and donor
know about this pack number. On filling it in, a donor receives points for donation (X) and pack
number is deleted from the list of available pack numbers.
When signing in a donor fills the username of the person who shared with him the application or
the person who recommended him to download it. This field is optional because not all donors are
recommended. The more the users that fill in a donors name as a person who recommended them,
the more that donors Y value (number of recommendations) increases hence receiving more points.
Values for the ration of people with a particular blood type (Y) are stored in a table having columns
of the eight (8) blood types. The value is picked according to the profile of the donor that is the
blood group they register on signup.
The amount of blood in storage per blood type (S). All blood banks are mandated to update the
value of blood they have in stock. Totals from all blood banks registered are generated for every
blood type. We wrote a method sortReverseReturn in donorCalcPoints.php that assigns the highest
value of (S) to the donors that have the least blood in stock. This helps bring people whose blood
type is scarce on board to donate blood and balance levels technically. As fluctuations occur the
model does the balancing appropriately.

5.3.4 After loyalty points

When a user accumulates points he can use the points to claim a reward. A user can only access a
reward whose price costs cheaper than the donors points. When uploading rewards, we classify them
according to worthiness basing on loyalty points cost. On the other hand, a donor can serve some
of his points to another donor but he cant serve more than he has. We would suggest the loyalty
points system to replace the old model in Uganda of using cards to receive blood.

26
Chapter 6

Conclusion and Future Works

6.1 Conclusion
The start of the year 2018 witnessed a spike in the number of blood donation drives organized
and popularized by prominent companies like UMEME, Capital FM, among others geared towards
fulfillment of their corporate responsibility in light of the shortfalls in blood stocks at the hospitals
and blood banks.
The blood donate application will serve as a tool to extend the reach of such events in terms
of popularization while also giving the companies the platform to provide incentives to those that
would partake in the Blood donation drives.
The application will be integral in increasing the number of donations and getting more people
on board to make donations while also ensuring the necessary competitiveness in order to attain
rewards; process that will eventually turn out to be a win-win as donors rack up points to attain
reward while blood volumes register increases.

6.2 Future Works

Hosting the database on an online server and putting the application prototype on the Google
playstore in order to operationalize it for use by whomever may need it. Incorporation of Application
programming Interfaces of popular social sites into the application.
Monitoring of the application downloads and use in order to perform analysis and gauge the
effectiveness of a mobile application in increasing the number of donations along with response to
calls made by donations drives through the application for people to go and donate blood.
Pursuit of partnerships with companies and organizations that are chiefly known for organizing
blood donation drives and also those that would be open to offering products, services for the rewards
catalogue in the application such as flat screens, smartphones, tickets to blockbuster premieres,
holiday trips.
The aim of this would be to rack up revenue in advertisements along with having diversity in the
potential rewards that users that regularly donate blood can acquire.

27
References

[1] Beatrice nakibuuka, low response to donation drive causes blood shortage - daily monitor, in-
ternet: http://www.monitor.co.ug/magazines/healthliving/low-response-donation-drive-causes-
blood-shortage/689846-3066402-12u8lsoz/index.html, saturday, november 11, 2017* [20th, oc-
tober, 2017].

[2] Oganyo, p. ubts — safe blood saves life, internet: http://www.ubts.go.ug/, friday, october 6,
2017* [29th, october, 2017].

[3] M. C Almetwally. (2014) a framework for a smart social blood donation system based on mobile
cloud computing, volume 1: Pages 5–9.

[4] H Deeptha. (may, 2017) design and implementation of e-blood donation system using location
tracking, international journal of innovative research in computer and communication engineer-
ing,volume 5: Pages 3–5.

[5] T. Denbar. World health organization, who — why should i donate blood, internet:
http://www.who.int/features/qa/61/en/, tuesday, june 13, 2017* [12th, november, 2017].

[6] Samy. S. (february, 2016) design and development of mobile blood donor tracker,journal of
multidisciplinary engineering science studies, volume 2: Pages 2–6.

28