Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
26 views59 pages

Sample Documentation

Uploaded by

upasanamahankali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views59 pages

Sample Documentation

Uploaded by

upasanamahankali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 59

A Mini Project Report On

MOBILE BLOOD BANK


Submitted to partial fulfillment of the requirements for the award of the degree of
BACHELOR OF TECHNOLOGY
in
COMPUTER SCIENCE & ENGINEERING
By
G. KHUSHI REDDY (20911A0519)
CH. MOUNIKA (20911A0532)
S. CHAITANYA KUMAR (20911A0552)
CH. ALEKHYA (20911A0559)

Under the Guidance of


Mrs. CH. DEEPIKA
Asst. Professor

Department of Computer Science & Engineering

VIDYA JYOTHI INSTITUTE OF TECHNOLOGY


(An Autonomous Institution)
(Approved by AICTE, Accredited by NAAC, NBA & permanently Affiliated to JNTU, Hyd)
Aziz Nagar Gate, C.B. Post, Hyderabad-500075
2023-2024
1
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

CERTIFICATE

This is to certify that the project report titled “Mobile Blood Bank” is being submitted by
G.Khushi Reddy (20911A0519), Ch. Mounika (20911A0532), S. Chaitanya Kumar
(20911A0552),Ch. Alekhya (20911A0559), partial fulfillment for the award of the Degree of
Bachelor of Technology inComputer Science & Engineering, is a record of bonafide work carried
out by them under my guidance and supervision. These results embodied in this project report
have not been submitted to any other University or Institute for the award of any degree of
diploma.

Internal Guide Head of Department


Mrs. Ch. Deepika Dr. D Aruna Kumari
Assistant Professor Professor

External Examiner
DECLARATION

We, G. Khushi Reddy, Ch. Mounika, S. Chaitanya Kumar, Ch. Alekhya hereby declare that the
project entitled, “Mobile Blood Bank” submitted for the degree of Bachelor of Technology in
Computer Science and Engineering is original and has been done by us and this work is not copied
and submitted anywhere for the award of any degree.

Date: G. Khushi Reddy (20911A0519)


Place: Hyderabad Ch. Mounika (20911A0532)
S. Chaitanya Kumar (20911A0552)
Ch. Alekhya (20911A0559)
ACKNOWLEDGEMENT

We wish to express our sincere gratitude to the project guide, Mrs. Ch. Deepika,
Assistant Professor, Vidya Jyothi Institute of Technology, Hyderabad for her timely
cooperation and valuable suggestions while carrying out this work. It is his kindness that made us
learn more from her.
We are grateful to Dr. D Aruna Kumari, Professor and HOD, department of CSE, for her
help and support during our academic year.
We would like to take this opportunity to express our gratitude to our Principal Dr. E. Sai
Baba Reddy for providing necessary infrastructure to complete this project.
We would thank our parents and all the faculty members who have contributed to our
progress through the course to come to this stage.

G. Khushi Reddy (20911A0519)


Ch. Mounika (20911A0532)
S. Chaitanya Kumar (20911A0552)
Ch. Alekhya (20911A0559)
ABSTRACT
MOBILE BLOOD BANK

The Mobile Blood Bank (MBB) represents a meticulously crafted mobile application
with a singular focus on delivering exceptional performance in emergency situations. It serves as
a versatile and comprehensive repository of vital information, specifically designed to empower
blood donors in seamlessly managing their profiles. This dynamic platform grants users
effortless access to an expansive database of donors, encompassing crucial details such as
contact information, geographic locations, and blood types. The MBB's robust functionality
plays a pivotal role in simplifying the complex and time-sensitive process of securing life-saving
blood donations. By harnessing the full potential of mobile technology, the MBB effectively
bridges the gap between donors and individuals facing dire medical emergencies. Its emergence
as an invaluable tool in the realm of emergency healthcare underscores its significance in the
broader healthcare landscape.

Furthermore, the MBB project goes beyond its primary role as a blood bank by
incorporating an additional feature—a Body Mass Index (BMI) calculator. This inclusion
extends the application's utility and aligns it with a broader perspective of promoting health
consciousness among users. The MBB stands as a shining example of how technology can be
harnessed to address critical medical needs while simultaneously advocating for the overall
well-being and health awareness of individuals. It embodies the fusion of innovation, efficiency,
and humanitarianism, illustrating the pivotal role that modern technology plays in safeguarding
lives and promoting better health outcomes in today's world.
INDEX

S.NO TITLE PAGE NO


1. Introduction 1
2. Literature Survey 2
3. System Requirement Specifications 3
3.1 Existing System 3
3.2 Proposed System 3
3.3 System Requirements 3
3.3.1 Software Requirements 3
3.3.2 Hardware Requirements 3
3.4 Requirements Definition 4
3.4.1 Functional Requirements 4
3.4.2 Non-Functional Requirements 4
4. System Design 6
4.1 UML diagrams 6
4.1.1 Use case Diagram 8
4.1.2 Activity Diagram 9
4.1.3 Class Diagram 10
4.1.4 Sequence Diagram 11
4.1.5 System Architecture 12
5. Software Implementation 13
5.1 Android Studio 13
5.2 Java 16
5.3 XML 19
5.3.1 XML for Layouts 19
5.3.2 Resources in XML 20
5.3.3 XML in Androidmanifest file 20
5.3.4 Data Binding and XML 20
5.3.5 Layout Editors in Android Studio 20
5.4 Firebase 21
5.5 Application code 22
6. System Testing 25
6.1 Types of Tests 26
6.1.1 Unit Testing 26
6.1.2 Integration Testing 26
6.1.3 Functional Testing 26
6.2. System Tests 27
6.2.1 White Box Testing 27
6.2.2 Black Box Testing 27
6.3 Performance Testing 27
6.4 Acceptance Testing 28
6.5 Validation Testing 28
6.6 Output Testing 28
6.7 Test Cases 29
7. Result and Output Screens 32
7.1 Home Page of Application 32
7.2 Calculation of BMI for Overweight 33
7.3 Calculation of BMI for Normal 34
7.4 Calculation of BMI for Severely Underweight 35
7.5 Calculation of BMI for Underweight 36
7.6 Home page for Donor and Receiver 37
7.7 Donor Registration Form 38
7.8 Donor Registration Successful 39
7.9 Filtering by Blood Group 40
7.10 Filtering by Location 41
7.11 List of Donors 42
7.12 Displaying details of Donor 43
7.13 Direct Calling 44
7.14 Direct Message Notification 45
8. Conclusion 46
9. Future Enhancements 47
10. References 48
LIST OF FIGURES

S.NO TITLE PAGE NO

4.1.1. Use case Diagram 8


4.1.2. Activity Diagram 9
4.1.3. Class Diagram 10
4.1.4. Sequence Diagram 11
4.1.5. System Architecture 12
7.2. Calculation of BMI for Overweight 32
7.3 Calculation of BMI for Normal 33
7.4 Calculation of BMI for Severely Underweight 34
7.5 Calculation of BMI for Underweight 35
7.6 Home page for Donor and Receiver 36
7.7 Donor Registration Form 37
7.8 Donor Registration Successful 38
7.9 Filtering by Blood Group 39
7.10 Filtering by Location 40
7.11 List of Donors 41
7.12 Displaying details of Donor 42
7.13 Direct Calling 43
7.14 Direct Message Notification 44
CHAPTER-1
INTRODUCTION

The critical shortage of blood and its components in India is a matter of utmost concern, as
highlighted by the World Health Organization's (WHO) survey conducted in 2019. The survey
revealed that India's demand for blood stands at a staggering eight crore units annually, while the
availability on the market is a mere ten lakh units. This alarming gap underscores the pressing need to
address the blood shortage crisis.

Blood and its derivatives are irreplaceable in medical procedures, with virtually no major
operation being feasible without the use of blood. As India's population continues to grow, the demand
for blood rises daily, creating a significant challenge for the healthcare system. The quantitative
disparity between the existing number of blood banks and the number required is a critical issue that
needs immediate attention.

On average, at least 2,000 blood donations are required daily, and the current supply falls far
short of meeting this demand. Emergencies such as traffic accidents, hospitalizations, and childbirths
necessitate a constant external supply of blood. To bridge the gap and facilitate access to blood for
those in need, blood-based applications have emerged as a potential solution.

The development of a Blood Donor Application represents a significant step towards


addressing the societal challenge posed by the shortage of blood. Blood transfusion is a fundamental
component of healthcare, saving countless lives annually in both routine and emergency situations. It
greatly enhances the prognosis and quality of life for patients dealing with various acute and chronic
conditions. Blood transfusion is also closely linked to voluntary blood donation, a crucial aspect of
ensuring a consistent blood supply.

1
CHAPTER-2
LITERATURE SURVEY

In the realm of healthcare, blood serves as a lifeline, particularly during emergency situations.
This literature review delves into two significant contributions in the domain of blood donor
information and management systems. The first study, conducted by P. Priya, V. Saranya, S. Shabana,
and Kavitha Subramani[1], explores an extended web application aimed at efficiently updating
information concerning donors, acceptors, and patients. The second study, authored by Tushar Pandit,
Satish Niloor, and A.S. Shinde[2], presents a survey of existing electronic blood bank systems and
proposes an innovative shift towards mobile technology.

Study1: Optimization of Blood Donor Information and Management System


In their study, P. Priya, V. Saranya, S. Shabana, and Kavitha Subramani[1] introduce an
extended web application as a solution to streamline blood donor information and management. This
web application offers real-time updates on donor, acceptor, and patient data. Administrators gain
access to a comprehensive blood bank management system, providing them with a holistic view of
operations. Notably, the proposed system places a strong emphasis on security, safeguarding the
privacy of donor contact details. Moreover, it effectively tracks the availability of various blood groups
and employs a proactive approach, notifying donors when stocks of a specific blood group fall below
the required threshold. To augment this web-based system, the authors propose an Android mobile
application for locating nearby donors during emergencies, such as accidents. This multifaceted
approach proves to be readily scalable, efficient, and adaptable, catering to the intricate needs of blood
banks—a pivotal component within the healthcare sector.

Study 2: A Survey Paper on E-Blood Bank and an Idea to use on Smartphone


Tushar Pandit, Satish Niloor, and A.S. Shinde[2] conducted a comprehensive survey to
highlight the limitations of conventional online blood bank systems. A prominent drawback identified
is the absence of direct communication channels between donors and blood banks, a critical
impediment to efficient blood donation management. Moreover, existing systems are marred by
time-consuming processes, heavy manpower requirements, and high costs. In response to these
shortcomings, the authors propose a paradigm shift, transitioning from traditional desktop systems to a
mobile-centric approach.
2
CHAPTER-3
SYSTEM REQUIREMENTS SPECIFICATIONS

3.1 EXISTING SYSTEM


Blood donors can be found through online platforms, physical blood banks, and toll-free phone
numbers. However, finding a suitable donor can still take time due to factors like blood type rarity and
donor availability. The current blood donor search process involves manual work, reliance on internet
connectivity, potential time wastage at blood bank centers, and waiting in queues.

3.2 PROPOSED SYSTEM


A mobile-based blood bank project utilizes the portability of mobile devices for easy registration
of blood donors and efficient communication between donors and those in need of blood, enhancing
accessibility and convenience. Our system offers a straightforward and efficient method to locate
blood donors quickly, saving valuable time. Users can effortlessly identify donors with their specific
blood group and access their contact details. Furthermore, our application facilitates direct
communication with donors through phone calls or messages, streamlining the process and ensuring
prompt assistance.

3.3 SYSTEM REQUIREMENTS


3.3.1 SOFTWARE REQUIREMENTS
● OS : Windows XP and above (with any web browser)
● Front end : Java with XML
● Tool kit : Android SDK
● IDE : Android Studio
● Database : Firebase
3.3.2 HARDWARE REQUIREMENTS
● RAM : 4GB
● Processor : Intel i3 or above
● Hard Disk : 40GB or above

3
3.4 REQUIREMENTS DEFINITION
After the severe continuous analysis of the problems that arose in the existing system, we are
now familiar with the requirements required by the current system. The requirements that the system
needs are categorized into functional and non-functional requirements. These requirements
are listed below:

3.4.1 FUNCTIONAL REQUIREMENTS


Functional Requirements delineate the specific functions and behaviors expected from a
software system when subjected to particular inputs or conditions. These encompass calculations, data
manipulation, processing, and other distinct functionalities. Within the scope of this project, the
functional requirements hold paramount importance as they dictate the overall operation of the
system's modules.
The functional requirements for above application are as follows:-
1. User registration for both donors and receivers.
2. Donors can input blood details, including location and type.
3. Donors can view incoming requests from receivers.
4. Receivers can search for donors based on location and blood type.
5. Receivers can send donation requests to donors and view responses.
6. Receivers can initiate messages or calls to donors.

3.4.2 NON-FUNCTIONAL REQUIREMENTS


Non-functional requirements describe features, characteristics, and capacity of the system and
they may constrain the boundaries of the proposed system. The following are the non-functional
requirements that are essential depending on the performance, cost, and control and give security
efficiency and services.
Based on the above-explained non-functional prerequisites, they are as follows:
1. Reliability: The system must reliably display changes made by users and developers, ensuring
transparency and visibility of modifications.
2. Security: The system must prioritize security to protect against crashes and unauthorized access,
given the rapid evolution of technology.

4
3. Maintainability: System monitoring and maintenance should be straightforward and manageable,
avoiding excessive background processes.
4. Performance: The system should offer high performance, supporting multiple simultaneous users
without interruptions or delays.
5. Portability: It should be easily transferable to another system in case of hosting issues or server
problems.
6. Scalability: The system must accommodate future functionalities, providing a common channel for
their integration.
7. Flexibility: It should adapt to changing scenarios, business rules, and user requirements, with
minimal impact on the overall system when adjustments are needed.

5
CHAPTER-4
SYSTEM DESIGN

4.1 UML Diagrams


UML diagram is designed to let developers and customers view a software system from a
different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual
modeling tools include. In its simplest form, a use case can be described as a specific way of using the
system from a User’s (actor’s) perspective. A more detailed description might characterize a use case
as:
● a pattern of behavior the system exhibits
● a sequence of related transactions performed by an actor and the system
● delivering something of value to the actor
Use cases provide a means to:
● capture system requirements
● communicate with the end users and domain experts
● Test the system
Use cases are best discovered by examining the actors and defining what the actor will be able
to do with the system. Since all the needs of a system typically cannot be covered in one use case, it is
usual to have a collection of use cases. Together this use case collection specifies all the ways of using
the system.
A UML system is represented using five different views that describe the system from a distinctly
different perspective. Each view is defined by a set of diagrams, which is as follows.
User Model View
● This view represents the system from the user’s perspective.
● The analysis representation describes a usage scenario from the end-user’s perspective.
Structural Model view
● In this model the data and functionality are arrived from inside the system.
● This model view models the static structures.

6
Behavioral Model View
● It represents the dynamic of behavior as parts of the system, depicting the interactions of
collection between various structural elements described in the usermodel and structural model
view.
Implementation Model View
● In this the structural and behavioral parts of the system are represented as they are to be built.
Environmental Model View
● In this the structural and behavioral aspect of the environment in which the system is to be
implemented are represented.

UML is specifically constructed through two different domains they are:


● UML Analysis Modeling: This focuses on the user model and structural model views of the
system.
● UML Design Modeling: This which focuses on the behavioral part of the system.

7
4.1.1 Use Case Diagram
A use case diagram is a graphical depiction of a user's possible interactions with a system and
shows various use cases and different types of users the system has and will often be accompanied by
other types of diagrams.

Figure. 4.1.1 Use case diagram for MBB

8
4.1.2 Activity Diagram
Activity diagram is a flowchart to represent the flow from one activity to another activity and
can be described as the operation of the system.

Figure. 4.1.2 Recipient Interaction and BMI Calculation Activity Diagram

9
4.1.3 Class Diagram
A class diagram is a type of static structure diagram that describes the structure of a system by
showing the system's classes, their attributes, operations (or methods), and the relationships among
objects.

Figure. 4.1.3 Class diagram for MBB

10
4.1.4 Sequence Diagram
Sequence diagrams are used to communicate the behavior of a system to developers,
stakeholders, and other users. They can be used to model simple processes and complex processes.

Figure. 4.1.4 Sequence diagram for Donor and Receiver interacting with MBB

11
4.1.5 System Architecture
System architecture for mobile applications refers to the high-level design and structure of the
software and hardware components that make up a mobile application. It defines how different parts of
the application interact with each other, how data is stored and processed, and how the application
communicates with external resources or services. A well-defined system architecture is crucial for
ensuring the reliability, scalability, and maintainability of a mobile app.

Figure. 4.1.6 System Architecture For Mobile Blood Bank

12
CHAPTER-5
SOFTWARE IMPLEMENTATION

5.1 Android Studio


Android applications are written in the Java programming language. The Android SDK tools
compile the code—along with any data and resource files—into an Android package, an archive file
with an .apk suffix. All the code in a single .apk file is considered to be one application and is the file
that Android-powered devices use to install the application.

Once installed on a device, each Android application lives in its own security sandbox:
● The Android operating system, is a multi-user Linux system in which each application is
a different user.
● By default, the system assigns each application a unique user ID (the ID issued only by
the system and is unknown to the application). The system sets permissions for all the files
in an application so that only the user ID assigned to that application can access them.
● Each process has its own virtual machine (VM), so an application's code runs in isolation
from other applications.
● By default, every application runs in its own Linux process. Android starts the process
when any of the application's components need to be executed, then shuts down the process
when it's no longer needed or when the system must recover memory for other applications.

In this way, the Android system implements the principle of least privilege. That is, each
application, by default, has access only to the components that it requires to do its work and no
more. This creates a very secure environment in which an application cannot access parts of the
system for which it is not given permission.
However, there are ways for an application to share data with other applications and for an
application to access system services:
It's possible to arrange for two applications to share the same Linux user ID, in which case they
are able to access each other's files. To conserve system resources, applications with the same user ID
can also arrange to run in the same Linux process and share the same VM (the applications must also
be signed with the same certificate).
13
An application can request permission to access device data, such as the user's contacts, SMS
messages, the mountable storage (SD card), camera, Bluetooth, and more. All application permissions
must be granted by the user at install time.
That covers the basics regarding how an Android application exists within the system. The rest
of this document introduces you to:
● The core framework components that define your application.
● The manifest file in which you declare components and required device features for your
application.

Android Studio: Application Development


The first step in the application development process is to create a new project within the Android
Studio environment. Begin, therefore, by launching Android Studio so that the ―Welcome to Android
Studio‖ screen appears as illustrated in Figure.

Figure: Starting a new android project


The Android SDK instruments order the code—alongside any information and asset records—
into an Android bundle, a file document with an .apk addition. All the code in a solitary .apk record is
thought to be one application and is the document that Android-filled gadgets use to introduce the
application. Once introduced on a gadget, every Android application lives in its own particular security
sandbox:

14
● The Android working framework, is a multi-client Linux framework in which
every application is an alternate client.
● By default, the framework allocates every application one of a kind client ID
(the ID issued just by the framework and is obscure to the application). The
framework sets authorizations for every one of the documents in an application
so that exclusive the client ID doled out to that application can get to them.
● Each handle has its own particular virtual machine (VM), so an application's
code keeps running in detachment from different applications.
● By default, each application keeps running in its own particular Linux prepare.
Android begins the procedure when any of the application's parts should be
executed, then closes down the procedure when it is not required anymore or
when the framework must recoup memory for different applications.

Along these lines, the Android framework actualizes the rule of slightest benefit.
That is, every application, of course, has entry just to the segments that it requires to do
its work and no more. This makes an exceptionally secure condition in which an
application can't get to parts of the framework for which it is not given authorization.

Be that as it may, there are courses for an application to impart information to


different applications and for an application to get to framework administrations:

It's conceivable to orchestrate two applications to have a similar Linux client ID,
in which case they can get to each other's documents. To save framework assets,
applications with a similar client ID can likewise organize to keep running in a similar
Linux process and have the same VM (the applications should likewise be marked with
a similar declaration).

An application can ask for consent to get gadget information, for example, the
client's contacts, SMS messages, the mountable stockpiling (SD card), camera,
Bluetooth, and that's only the tip of the iceberg. All application consents must be
allowed by the client at introduction time.That covers the fundamentals in regards to
how an Android application exists inside the framework.

15
5.2 JAVA

A platform is the hardware or software environment in which a program runs. As


already mentioned some of the most popular platforms like Windows 2000, Linux, Solaris,
and MacOS. Most platforms can be described as a combination of the operating system and
hardware. The Java platform differs from most other platforms in that it’s a software-only
platform that runs on top of other hardware-based platforms.The Java platform has two
components:

● The Java Virtual Machine (JVM)


● The Java Application Programming Interface (Java API)

We‘ve already been introduced to the Java VM. It‘s the base for the Java platform and is ported
onto various hardware-based platforms.The Java API is a large collection of ready-made software
components that provide many useful capabilities, such as graphical user interface (GUI) widgets. The
Java API is grouped into libraries of related classes and interfaces; these libraries are known as
packages.The figure depicts a program that‘s running on the Java platform. As the figure shows, the
Java API and the virtual machine insulate the program from the hardware.

Native code is code that after you compile it, the compiled code runs on a
specific hardware platform. As a platform-independent environment, the Java platform
can be a bit slower than native code. However, smart compilers, well-tuned interpreters,
and just-in-time bytecode compilers can bring performance close.

Java was conceived by James Gosling, Patrick Naughton, Chris wrath, Ed


Frank, and Mike Sheridan at Sun Micro system. It is a platform independent
programming language that extends its features wide over the network. The Java2
16
version introduces new components that are possible with AWT.

● It‘s a lightweight package, as they are not implemented by platform-specific code.


● Related classes are contained in sub packages such as javax.swing
● Components explained in the swing have more capabilities than those of AWT

The Java programming language is a high-level language that can be characterized by all of the
following buzzwords

● Simple
● Architecture neutral
● Object oriented
● Portable
● Distributed
● High performance
● Interpreted
● Multithreaded
● Robust
● Dynamic
● Secure

With most programming languages, it either compiles or interprets a program so that it can run
it on our computer. The Java programming language is unusual in that a program is both compiled and
interpreted. With the compiler, first it translates a program into an intermediate language called Java
byte codes.

Java byte codes are the platform-independent codes interpreted by the interpreter on the Java
platform. The interpreter parses and runs each Java bytecode instruction on the computer. Compilation
happens just once; interpretation occurs each time the program is executed. The following figure
illustrates how this works.

17
Figure. Java Programming Language Execution

We can think of Java bytecodes as the machine code instructions for the Java Virtual Machine
(Java VM). Every Java interpreter, whether it‘s a development tool or a Web browser that can run
applets, is an implementation of the Java VM. Java byte codes help make ―write once, run anywhere‖
possible. You can compile your program into byte codes on any platform that has a Java compiler. The
byte codes can then be run on any implementation of the Java VM. That means that as long as a
computer has a Java VM, the same program written in the Java programming language can run on
Windows 2000, a Solaris workstation, or on an iMac.

18
Figure. Sample program execution

5.3 XML

XML (Extensible Markup Language) plays a fundamental role in Android app development
when it comes to defining user interfaces, resources, and configuration settings. Understanding XML in
Android Studio is crucial for creating visually appealing and functional Android applications. Here's an
overview of XML in Android Studio:

5.3.1 XML for Layouts


Layout Files: XML is commonly used in Android to define the layout and structure of user interfaces.
These XML files, known as layout files, describe how UI elements are arranged on the screen.
View Hierarchy: In Android, UI elements such as buttons, text views, and image views are defined
using XML in layout files. Developers specify the positioning, size, and attributes of these elements
using XML tags and attributes.
XML Tags: Android provides a set of XML tags that represent UI elements (e.g., <Button>,
<TextView>, <ImageView>). These tags are used to create user interface components in layout files.
Attributes: XML attributes are used to set properties and styles for UI elements. For example, you can
set the text color, size, and alignment for a TextView using XML attributes.

19
5.3.2 Resources in XML
String Resources: XML is used to define string resources, which store text strings that can be easily
localized for different languages. String resources are stored in XML files and referenced in layout and
code.
Color Resources: XML is also used to define color resources. This allows you to maintain a consistent
color scheme throughout your app by specifying colors in XML and referencing them in your layout and
code.
Dimension Resources: XML is used to define dimension resources for specifying sizes, margins, and
padding in a consistent manner. This helps ensure that your app's layout scales properly on different
devices.
Style Resources: XML is used to define style resources that encapsulate sets of attributes. Styles can be
applied to multiple UI elements, simplifying the management of their appearance.
Resource References: XML allows you to reference resources by their IDs or names, making it easier
to update and maintain your app's design and content.
5.3.3 XML in AndroidManifest.xml
AndroidManifest.xml: The AndroidManifest.xml file is an essential part of an Android app. It uses
XML to declare various aspects of the app, including permissions, activities, services, and intent filters.
Permissions: XML elements in the manifest file specify the permissions required by the app to access
certain features or device capabilities, such as the camera or location services.

5.3.4 Data Binding and XML


Data Binding: Android Data Binding is a library that allows you to bind UI components in your layout
files directly to data sources. It uses XML-based expressions to connect UI elements to data, reducing
the need for boilerplate code.
5.3.5 Layout Editors in Android Studio
Visual Editors: Android Studio provides visual layout editors that allow you to create and edit XML
layout files using a graphical interface. These editors simplify the process of designing user interfaces.
Resource Qualifiers: XML-based resource qualifiers, such as folder names and prefixes, are used to
provide different resources for different device configurations (e.g., screen size, orientation, and
language).

20
XML is a critical part of Android app development in Android Studio. It is used to define layouts,
resources, configuration settings, and app metadata. Understanding how to use XML effectively allows
developers to create visually appealing and functional Android applications that work across a wide
range of devices and languages.

5.4 Firebase
Firebase Cloud Messaging (FCM) It is formerly known as Google Cloud Messaging (GCM),
FCM is a paid service which is a cross-platform solution for messages and notifications for Android,
Web Applications, and IOS. Firebase Auth Firebase Auth supports social login providers like
Facebook, Google GitHub, and Twitter. It is a service that can authenticate users using only client-side
code and it is a paid service. It also includes a user management system whereby developers can
enable user authentication with email and password login stored with Firebase.Real-time Database
Firebase provides services like a real-time database and backend. An API is provided to the
application developer which allows application data to be synchronized across clients and stored in
Firebase's cloud. The client libraries are provided by the company which enables integration with
Android, IOS, and JavaScript applications. Firebase Storage It facilitates easy and secure file transfer
regardless of network quality for the Firebase apps. It is backed by Google Cloud Storage which is a
cost-effective object storage service.

The developer can use it to store images, audio, video, or other user-generated content.
Firebase Test Lab for Android It provides cloud-based infrastructure for testing Android apps. With
one operation, developers can initiate testing of their apps across a wide variety of devices and device
configurations. The various test results like screenshots, videos and logs are available in the Firebase
console.

Even if a developer hasn't written any test code for their app, Test Lab can exercise the app
automatically, looking for crashes. Firebase Crash Reporting The detailed reports of the errors are
created in the app. The errors are grouped into clusters of similar stack traces and triaged by the
severity. The other features are: the developer can log custom events to help capture the steps leading
up to a crash. Firebase Notifications It enables targeted user notifications for mobile app developers
and the services are freely available.

21
5.5 Application Code

Activity_blood_connect_home.xml

<?xml version="1.0" encoding="utf-8"?>

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

android:paddingBottom="@dimen/activity_vertical_margin"

android:paddingLeft="@dimen/activity_horizontal_margin"

android:paddingRight="@dimen/activity_horizontal_margin"

android:paddingTop="@dimen/activity_vertical_margin"

tools:context="com.digicare.digicare.BloodConnectHomeActivity">

<Button

android:id="@+id/donarbutton"

android:layout_width="@dimen/bloodconnect_width"

android:layout_height="@dimen/bloodconnect_height"

android:layout_marginTop="121dp"

android:onClick="donarbuttonImplementation"

android:text="Donar"

android:background="@drawable/button_background"

android:layout_alignParentTop="true
22
android:layout_centerHorizontal="true" />

<Button

android:id="@+id/receiverbutton"

android:layout_width="@dimen/bloodconnect_width"

android:layout_height="@dimen/bloodconnect_height"

android:layout_below="@+id/donarbutton"

android:layout_centerHorizontal="true"

android:layout_marginTop="70dp"

android:background="@drawable/button_background"

android:onClick="receiverbuttonImplementation"

android:text="Receiver" />

</RelativeLayout>

BloodConnectHomeActivity.java

package com.digicare.digicare;

import android.content.Intent;

import android.os.Bundle;

import android.view.View;

import androidx.appcompat.app.AppCompatActivity;

public class BloodConnectHomeActivity extends AppCompatActivity {

@Override

23
protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_blood_connect_home);

public void donarbuttonImplementation(View view) {

startActivity(new Intent(BloodConnectHomeActivity.this, DonarRegisterActivity.class));

public void receiverbuttonImplementation(View view) {

startActivity(new Intent(BloodConnectHomeActivity.this, ReceiverActivity.class));

24
CHAPTER-6

SYSTEM TESTING

Testing is a pivotal phase within the product development life cycle. In this phase, any
remaining errors from previous stages are identified and rectified. Consequently, testing plays a critical
role in ensuring quality assurance and the reliability of the software. During testing, the program is
executed with a predefined set of test cases, and the program's output for these cases is assessed to
determine if it aligns with the expected behavior. Any errors that are detected are addressed, and these
corrections are meticulously documented for future reference. As such, a comprehensive series of tests
is conducted on the system before it is deemed ready for implementation.

Testing serves as a process to assess the correctness, completeness, security, and overall quality
of developed computer software. It involves a technical investigation carried out on behalf of
stakeholders to reveal information related to the product's quality, considering the context in which it
is intended to operate. This encompasses executing a program or application with the objective of
uncovering errors. Quality, in this context, is not an absolute value but rather a value relative to a
particular individual or group.

Therefore, testing cannot guarantee the absolute correctness of arbitrary computer software.
Instead, it offers a form of critique or comparison, assessing the state and behavior of the product
against its specifications. It's important to differentiate software testing from the broader discipline of
Software Quality Assurance (SQA), which encompasses all business process areas, not limited to
testing.

While there are various approaches to software testing, effectively testing complex products
primarily involves an investigative process rather than just following routine procedures. Although
many of the intellectual processes in testing align with those in reviews or inspections, the term
"testing"implies dynamic analysis, actively subjecting the product to a range of scenarios. Common
quality attributes under scrutiny include capability, reliability, efficiency, portability,
maintainability,compatibility, and usability.

25
6.1 Types of Tests

6.1.1 Unit Testing


Individual components are tested to ensure that they operate correctly. Each component is
tested independently, without other system components. This system was tested with the set of proper
test data for each module and the results were checked with the expected output. Unit testing focuses
on verification effort on the smallest unit of the software design module. This is also known as
MODULE TESTING. This testing is carried out during phases, each module is found to be working
satisfactory as regards to the expected output from the module.

6.1.2 Integration Testing


Integration testing is another aspect of testing that is generally done in order to uncover errors
associated with flow of data across interfaces. The unit-tested modules are grouped together and tested
in small segments, which make it easier to isolate and correct errors. This approach is continued until
all modules have integrated to form the system as a whole.

6.1.3 Functional Testing


Functional tests provide methodical evidence that the tested functions are available and meet
all technical and business requirements as well as those listed in the system documentation and user
manuals.
Functional testing is centered on the following items:

Valid Input: Recognized valid input classes need to be accepted.

Invalid Input: identified classes of invalid input must be rejected. Functions: It is necessary to use the
identified functions.

Output: Specific application output classes must be put to use.

Systems or procedures: Interfacing systems or procedures must be invoked.Organization and


preparation of functional tests are focused on requirements, key functions, or special test cases. In
addition, systematic coverage pertaining to identifying business process flows, including data fields,
predefined processes, and successive processes, must be considered for testing.

26
6.2 System Test
System testing is actually a series of different tests whose primary purpose is to fully exercise
the computer-based system. System testing ensures that the entire integrated software system meets
requirements. It tests a configuration to ensure known and predictable results. An example of system
testing is the configuration oriented system integration testing. System testing is based on process
description and flows, emphasizing pre-driver process and integration points.

6.2.1 White Box Testing

This allows the tests to:

● Check whether all independent paths within a module have been exercised at least once
● Exercise all logical decisions on their false sides
● Execute all loops and their boundaries and within their boundaries
● Exercise the internal data structure to ensure their validity
● Ensure whether all possible validity checks and validity lookups have been provided to validate
data entry.

6.2.2 Black Box Testing

Black box testing is done to find the following:

● Incorrect or missing functions


● Interface errors
● Errors on external database access
● Performance error
● Initialization and termination error

6.3 Performance Testing

The performance testing ensures that the output is produced within the time limits and time taken for
the system compiling, giving response to the users and requests being sent to the system in order of the
results.

27
6.4. Acceptance Testing
This is the final stage of the testing process before the system is accepted for operational use.
The system is tested within the data supplied from the system procurer rather than simulated data.

6.5 Validation Testing


This is the final stage of the testing process before the system is accepted for operational
use.The system is tested within the data supplied from the system procurer rather than simulated data.

6.6 Output Testing


After performing the validation testing, the next step is to test the output of the proposed
system, since no system could be useful if it did not produce the required output in the specified
format. The outputs produced or displayed by the system under consideration are tested by asking the
users about the format they require. As a result, there are two ways to think about the output format:
one is on screen, and the other is in printed form.

28
6.7 Test Cases

Test Case 1

Name of thetTest Donor registration

Input Enter Donor details name, email id, add, dob, mob
no.

Expected output Donor got registered successfully

Actual result As expected,

Remarks Successful

Test Case 2

Name of Test View blood details

Input Search based on location

Expected Result Fetched related data from database based on location

Actual output Results are shown on app

Remarks Successful

29
Test Case 3

Name of Test Request for blood

Input Send request to donor by message

Expected Result Request must be sent to respective donor

Actual output Donor received request and respond to receiver

Remarks Successful

Test Case 4

Name of Test BMI CALCULATOR

Input Gives weight and height

Expected Result BMI is shown with the Conditions

Actual output response shown on page

Remarks Successful

30
Test Case 5

Name of Test Call donor

Input Show call number details and connect call

Expected Result Call connected to donor from app

Actual output Call connected to donor

Remarks Successful

31
CHAPTER-7
RESULTS AND OUTPUT SCREENS

7.1 Home Page

Figure. 7.1 Home Page

This serves as the initial page of the application, featuring a pair of buttons. The second
button is designated for calculating the BMI (Body Mass Index) when weight is provided in
kilograms and height in centimeters. The first button is intended for individuals who wish to either
register as donors or connect with potential blood donors if they are in need.
32
7.2 Calculation of BMI for Overweight

Figure. 7.2 Calculation of BMI for Overweight

When the BMI (Body Mass Index) is computed, it will classify the first scenario as
"overweight" when weight in kilograms and height in centimeters are provided.

33
7.3 Calculation of BMI for Normal

Figure. 7.3 Calculation of BMI for Normal

When the BMI (Body Mass Index) is computed, it will classify the first scenario as "normal"
when weight in kilograms and height in centimeters are provided.

34
7.4 Calculation of BMI for Severely Underweight

Figure. 7.4 Calculation of BMI for Severely Underweight

When the BMI (Body Mass Index) is computed, it will classify the first scenario as "Severely
Underweight" when weight in kilograms and height in centimeters are provided.

35
7.5 Calculation of BMI for UnderWeight

Figure. 7.5 Calculation of BMI for Underweight

When the BMI (Body Mass Index) is computed, it will classify the first scenario as
"Underweight" when weight in kilograms and height in centimeters are provided.

36
7.6 Home page for Donor and Receiver

Figure. 7.6 Home page for Donor and Receiver

On this page, you'll find two buttons. The "Donor" button is used for donor registration, while
the “receiver” button allows people to connect with registered donors.

37
7.7 Donor Registration Form

Figure. 7.7 Donor Registration Form

This is the page where the donors can register.

38
7.8 Donor Registration Successful

Figure :7.8 Donor Registration Form

Upon successful registration, users will receive a confirmation message indicating that their
registration was completed successfully.

39
7.9 Filtering by Blood Group

Figure :7.9 Filtering by Blood Group

Individuals seeking blood donations can select the needed blood group from the available list
of groups.

40
7.10 Filtering By Location

Figure :7.10 Filtering By Location

Those in need of blood can select their desired location from the provided list.

41
7.11 List of Donors

Figure :7.11 List of Donors


Once the receiver has made selections from the provided list, they will be able to see the name
of the individual.

42
7.12 Displaying the details of Donor

Figure :7.12 Displaying the details of Donor


By clicking on the donor's name, you can access the donor's information, along with two
buttons—one for sending a message to the donor and the other for initiating a call to the donor.

43
7.13 Direct Calling

Figure :7.13 Direct Calling

The call is initiated after pressing the “Make a call” button.

44
7.14 Direct Message Notification

Figure :7.14 Direct Message Notification

The message is received by the donor.

45
CHAPTER-8
CONCLUSION

Thus, the proposed application will help Receivers to get the data of available blood near them
in time. Also, any person who wants to donate blood can do the same with the help of this application.
Anybody who needs blood should be able to use this service anytime without any need for
sophisticated hardware. This application provides an option for the donor to add blood details and the
receiver to search based on location and blood group type and send a request to the donor and get a
response. The automated system will simplify the manual blood donation process, reduce blood
wastage, and minimize blood transfusion errors. Furthermore, based on the statistical analysis of this
research, Android-based Blood donation inventory system will provide a seamless and faster method
of blood transfusion as evidenced by the opinion of the respondents. This study therefore recommends
the full deployment of this prototype and its implementation which will ease the burden of the manual
process of blood donation inventory system and improve blood transfusion activities.

46
CHAPTER-9
FUTURE ENHANCEMENTS

● Additional analysis features, such as identifying frequently requested zones or hospitals for
blood,tracking the number of donors, determining the most commonly requested blood group, and
categorizing patients by age groups in need of blood, can be incorporated into the application
● The application functionality can be implemented by leveraging Artificial Intelligence and Machine
Learning algorithms, enhancing the app's capabilities.
● Information about Non-Governmental Organizations (NGOs) and National Cadet Corps (NCC) units
can be made readily accessible within the application.
● Donors' most recent donation details can be automatically updated and synchronized with the
application, ensuring up-to-date donor information.
● Implementing a notification system to alert donors about the nearest Blood Donation Camps, ensuring
timely and convenient participation in blood donation initiatives.

47
CHAPTER-10
REFERENCES

[1]. Brislin M.R.A et al. (2017), ‘Blood Donation and Life Saver App’, 2 nd Int. Conf. on
Communication and Electronics Systems (ICCES), DOI:10.1109/CESYS.2017.8321318, pp 446-451.

[2] .Clementeena A, Sankar K and Kannan S, (2014), ‘A Study on Blood Bank Management System’,
Middle East Journal of Scientific Research, Vol. 19, No. 8, pp 1123-1126.

[3]. Das H.D, Ahmed R, Smrity N and Islam L, (2020) ‘Bdonor: A Geo-Localized Blood Donor
Management System Using Mobile Crowdsourcing’, IEEE 9th Int. Conf. on Communication Systems
and Network Technologies (CSNT), Doi: 10.1109/CSNT48778.2020.9115776, pp 313-317.

[4] .Fahim M, Cebe H.I, Rasheed J and Kiani F, (2016), ‘Mhealth: Blood Donation Application
UAndroid Smartphone’, 6 st Int. Conf. on Digital Information and Communication Technology and its
Applications (DICTAP), Konya, Turkey, 2016, Doi: 10.1109/DICTAP.2016.7543997 pp 35-38.

[5] .Hamlin M.R.A and Mayan J.A, (2016), ‘Blood Donation and Life Saver-Blood Donation App’,
Int. Conf. on Control, Instrumentation, Communication and Computational Technologies (ICCICCT),
Kumara coil, India, 2016, Doi: 10.1109/ICCICCT.2016.798802, pp 625-628.

[6]. Meiappane A, et al. (2019) ‘DWORLD: Blood Donation App Using Android’, IEEE Int. Conf. on
System, Computation, Automation and Networking (ICSCAN), Pondicherry, India, 2019, DOI:
10.1109/ICSCAN.2019.8878830, pp 1-5.

[7]. Pohandulkar S.S and Khandelwal C.S (2018), ‘Blood Bank App Using Raspberry Pi’ Int. Conf. on
Computational Techniques, Electronics and Mechanical Systems (CTEMS), Belgium, India, Doi:
10.1109/CTEMS.2018.8769143, pp. 355-358.

[8] .Priya P, et al. (2014), ‘The Optimization of Blood Donor Information and Management System by
Technopedia’, Int. Journal of Innovative Research in Science, Engineering and Technology, Vol. 3, pp
1-5.

48
[9] .Vikas Kulshreshtha, and Sharad Maheshwari, (2012) ‘Blood Bank Management Information
System in India’, Int. Journal of Engineering Research and Applications (IJERA), Vol .1, No. 2, pp
260-263.

[10]. Vikas Kulshreshtha, and Sharad Maheshwari, (2013), ‘Benefits of Management Information
System in Blood Bank’, Int. Journal of Engineering and Science, Vol. 1, No. 12, pp 5 -7.

49

You might also like