MOBILE REMINDER TO IMPROVE MEDICINE COMPLIANCE OF DEAF OR PATIENTS WITH LOW LITERACY LEVELS

texturegainfulMobile - Wireless

Dec 10, 2013 (3 years and 8 months ago)

110 views

MOBILE REMINDER TO
IMPROVE MEDICINE
COMPLIANCE OF DEAF O
R
PATIENTS WITH LOW LI
TERACY
LEVELS

By

Buhle Bongco

A
project
submitted in partial fulfillment
of the requirements for the
degree of

BSc (Honours) Computer Science

University of the Western Cape

2013

Date:


December 10, 2013



University of the Western Cape

Abstract

MOBILE REMINDER
TO
IMPROVE MEDICINE
COMPLIANCE OF
DEAF

OR
PATIENTS WITH LOW LI
TERACY
LEVELS

By

Buhle Bongco

Supervisor: Professor

IM Venter

Co Supervisor: Professor WD Tucker

Department of
Computer Science

This project aims to
improve the
medicine
compliance of patients with
low levels
of literacy.

The
system

remind
s

the
patient, with a short
video;

when it is time to
take medication
.

R
eminder
s
application will be pre
-
installed on the patient’s
mobile phone and the videos will be stored on the SD card. At

the
right

time a
video with instructions pops up
and tells the user what to do.

Two methods were
used to gather user requirements: literature and interviews.




ii

TABLE OF CONTENT

TABLE OF CONTENT

II

LIST OF TABLES

IV

LIST OF FIGURES

V

ACKNOWLEDGMENTS

VI

GLOSSARY

VII

C
HAPTER
1

9

The Users Requirement Document

9

Introduction

9

User’s view of the problem

12

Brief description of the problem domain

12

Complete description of the problem

12

What is expected from a software solution

13

What is not expected from a software solution

13

Chapter Summary

14

C
HAPTER
2

15

Requirement Analysis Document

15

Introduction

15

Designer’s view of the problem

15

High level design of the solution

16

Deep analysis of these parts and detailing

18

Identifying existing solutions

19

Identify alternative technical solutions

21

Best solution

21

Testing Methods

22

Summary

22

C
HAPTER
3

24

User interface specification

24

Introduction

24

Description of the complete user interface

24

What the user interface looks like to the user

25

How the user interface behaves

39

How the user interacts with the system

39

Summary

40

C
HAPTER
4

41

Object Oriened analysis (High Level Design)

41

Introduction

41

Data dictionary

41

User interaction design

42

Class diagrams showing the name, attributes, and methods of each class.

45

Summary

48

C
HAPTER
5

49

Object orientated DESIGN (Low level design)

49

Introduction

49




iii

Inner details of

the class attributes

50

Inner details of the class methods

50

Pseudo code of the application

52

Summary

53

C
HAPTER
6

54

code documentation

54

Introduction

54

Progress

54

Challenges

55

Future work

55

Code documentation

56

Pharmacist date and time selector class

56

The alarm receiver class

66

The option for the pharmacist to set a second alarm

70

DateAndTimeSelector2

72

Alarm Receiver 2 class

76

Option

for Alarm Again

80

Date and Time Selector 3

83

Alarm Receiver Class 3

93

Summary

96

Appendices

98

Appendix A

98

Questionnaire

98

Appenidx B

99

Project Plan: Term 1

99

Meeting dates & times /Tasks

99

Thesis Document

100

URD

100

RAD

100

Literature Survey

100

Presentation/

101

Deliverable

101

Website

101

appendix c

101

Project Plan Term 2

101

Appendix D

105

Project plan ter
m 4

105

Appendix e

106

project plan term 3

106

BIBLIOGRAPHY

108

Bibliography

108

INDEX

110




iv

LIST OF TABLES

Number

Page

T
ABLE
1:

D
ATA DICTIONARY CONSI
STING OF THE TECHNIC
AL TERMS EXPLAINED
E
NGLISH

42

T
ABLE
2:

D
EAF PATIENT
C
LASS WITH ATTRIBUTES

AND METHODS

45

T
ABLE
3:

T
HE PHARMACIST INTERF
ACE

46

T
ABLE
4:

T
HE
P
ROJECT PLAN FOR TE
RM
2

102

T
ABLE
5:

T
HE
P
ROJECT PLAN FOR TERM

4

E
RROR
!

B
OOKMARK NOT DEFINED
.





v

LIST OF FIGURES

Number

Page

F
IGURE
1:

S
TANDARD ALARM REMIND
ER ON A CELLPHONE

10

F
IGURE
2:

SD

CARD AND HOW INFORMA
TION IS STORED ON TH
E CARD OR THE PHONE
.

(A
SHISH
,

2013)

17

F
IGURE
3:

T
HE DIFFERENT
SD

CARDS AVAILABLE AND
THE DIFFERENT SIZES
(R
ED
O
RBIT
,

2013)

17

F
IGURE
4:

A
N EXAMPLE OF THE TYP
ICAL EXISTING SOLUTI
ON
(S
UGAR
,

2008)

20

F
I
GURE
5:

T
HE INTERFACE OF
G
OOGLE
C
ALENDAR
(
HTTP
://
WWW
.
GOOGLE
.
CO
.
ZA
/
URL
?
SA
.
COMMONS
.
WIKIMEDIA
.
ORG
/AC
LOUD
_
COMPUTING
,

2012)

21

F
IGURE
6
:

T
HE MAIN MENU WHERE T
HE PHARMACIST HAS TH
E OPTION TO SELECT T
HEIR PROFILE
.

(M.

B.

M
OTLHABI
,

2011)

26

F
IGURE
7:

P
HARMACIST LOGS
IN WITH THEIR PRACTI
CE NUMBER
(M.

B.

M
OTLHABI
,

2011)

27

F
IGURE
8:

T
HE WELCOME PAGE FOR
THE PHARMACIST
(M.

B.

M
OTLHABI
,

2011)

27

F
IGURE
9:

P
HARMACIST VERIFIES P
ATIENT IDENTITY
(M.

B.

M
OTLHABI
,

2011)

28

F
IGURE
10:

T
HE PATIENT BACKGROUN
D
(M.

B.

M
OTLHABI
,

2011)

28

F
IGURE
11:

T
HE
P
HARMACIST IS READY T
O DISPENSE MEDICATIO
N TO THE PATIENT
(M.

B.

M
OTLHABI
,

2011)

29

F
IGURE
12:

M
EDICATION THE PATI
ENT IS SUFFERING FRO
M
(M.

B.

M
OTLHABI
,

2011)

29

F
IGURE
13:

R
EPEAT TREATMENT
(M.

B.

M
OTLHABI
,

2011)

30

F
IGURE
14:

M
EDICINE NAME
(M.

B.

M
OTLHABI
,

2011)

30

F
IGURE
15:

C
APTURE
S
CREEN WHERE THE PHAR
MACIST WOULD TAKE A
PICTURE OF THE MEDIC
ATION
(M.

B.

M
OTLHABI
,

2011)

31

F
IGURE
16:

T
HE PHARMACIST WOULD
BE DISPENSING
(M.

B.

M
OTLHABI
,

2011)

31

F
IGURE
17:

T
HIS WHERE THE
PHARMACIST WOULD SET

THE TIME AND DATE

32

F
IGURE
18:

T
HEY HAVE THE OPTION
OF SETTING MULTIPLE
ALARMS FOR ONE TYPE
OF MEDICATION

33

F
IGURE
19:

T
HE RECOMMENDATIONS T
HE PATIENT SHOULD FO
LLOW
(M.

B.

M
OTLHABI
,

2011)

33

F
IGURE
20:

T
HE WARNINGS TO FOLLO
W
(M.

B.

M
OTLHABI
,

2011)

34

F
IGURE
21:

P
HARMACIST DONE PRESC
RIBING MEDICATION FO
R THE DEAF PERSON
(M.

B.

M
OTLHABI
,

2011)

34

F
IGURE
22:

T
HE CONDITION THEY SU
FFERING FROM IS EXPL
AINED IN
SASL

TO THE
D
EAF PATIENT
(M.

B.

M
OTLHABI
,

2011)

35

F
IGURE
23:

T
HEY ARE ABLE TO SEE
WHETHER OR NOT THIS
IS A REPEAT TREATMEN
T
.

(M.

B.

M
OTLHABI
,

2011)

36

F
IGURE
24:

T
HE PATIENT IS ABLE T
O SEE THE PICTURE OF

MEDICATION TAKEN BY
THE PHARMACIST FOR T
HEM TO
TAKE
.

(M.

B.

M
OTLHABI
,

2011)

36

F
IGURE
25:

M
EDICATION INSTRUCTIO
NS FOR THE PATIENT
(M.

B.

M
OTLHABI
,

2011)

37

F
IGURE
26:

T
HE PATIENT

CAN VIEW THE WARNING
S GIVEN BY THE PHARM
ACIST

37

F
IGURE
27:

T
HE PATIENT CAN VIEW
RECOMMENDATIONS FROM

THE PHARMACIST

38

F
IGURE
28:

T
HIS TELLS THE PATIEN
T THAT THE INSTRUCTI
ONS HAVE NOW COME TO

AN END
.

38

F
IGURE
29:

T
HIS IS A USE
-
CASE OF HOW THE PHAR
MACIST INTERACTS WIT
H THE SYSTEM

43

F
IGURE
30:

T
HIS IS HOW THE USER
AND THE SYSTEM INTER
ACT

44





vi

A
CKNOWLEDGMENTS

.




vii

GLOSSARY

API:

Application Programming Interface

(
www.thefreedictionary.com/API
)
.
Is a protocol intended to be used as an interface by software components to
communicate with each other
.

Deaf
:

Deaf

with a capital ‘D’ refers to people whose first language is sign
language and who are members of a specific linguistic cultural group

(Carol,
1991)
.

Functionally Illiteracy
:

An adult with the ability to read at sixth
-
grade level
and also employable
.

(Olsen, 1965)
. This term also refers
to
reading

and

writing

skills that are inadequate "to manage daily living and
employment tasks that require

reading skills beyond a basic level.

Functional
illiteracy is contrasted with

illiteracy

in the strict sense, meaning the inability
to read or write simple sentences in any language.
Foreigners who cannot read
and write in the native language where they live may also be considered
functionally illiterate.

(http://en.wikipedia.org/wiki/Functional_illiteracy#cite_ref
-
1)


High Level Design:
provides an overview
of an entire system, identifying all
its elements at some level of abstraction

(WikiMedia, 2013)

Interface
:

The point of interaction or communication between a computer and
any other entity, such as a printer
or human operator

or
the

layout of an
application's graphic or textual controls in conjunction with the way the
application responds to user activity
.

(www.thefreedictionary.com/interface,
2008)

Low Level Design:

E
xposes the
detailed design of each of these elements

(WikiMedia, 2013)

Mobile Phone
:

a portable telephone that works by means of a cellular radio
system
.

(www.thefreedictionary.com/interface,
2008)

SASL
:

South African Sign Language

SMS
:

(Short Message Service) is a form of text messaging communicating on
phones and mobile phones

(www.thefreedictionary.com/interface, 2008)




viii

Software
:

The programs, routines, and symbolic languages that control the
functioning of the hardware and direct its operation.

User:
A stakeholder, the person whom their needs should be satisfied by the
application

User Interface:

T
he junction between a user and a

computer program. An
interface is a set of commands or menus through which a user communicates
with a program
.

(Enterprise, 2013)






9

C h a p t e r 1

THE USERS REQUIREMEN
T DOCUMENT

Introduction

This section describes the problem from the user’s point of the view. It briefly
describes the problem
domain. Then

the

document delivers a simple and exact
description of the problem
. After the problem description, the user sta
tes
exactly what he/she would like the software system to do. While this may
seem to indicate a user interface, it is better to focus on the tasks to be solved
rather than the inte
rface. The crux of this section

is to identify

what the user
requires of the program, and not what the user requires of the programmer
.
This section furnishes the programmer with formal description of the problem.

The project aims to increase medicine compliance in Deaf and illiterate
patients as wel
l as creating a mobile application that is some form
of
reminder

mobile
device that is not audio based

or text based

like the normal current

reminder

devices

(
see

Figure
1
).
These syst
ems do not take illiterate user
s into
account in anyway.




10


Figure
1
: Standard alarm r
eminder

on a cellphone

There is a significant difference between Deaf with a capital D
and

small letter

deaf. The term Deaf is used to refer to people that were born deaf have never
in their lives ever had the ex
perience of being able to hear. The term deaf refer
to
the pathological condition: hearing loss. Physical deficiency and how it
subsequently affects the behaviour of deaf people.

(Carol, 1991)
.
In Deaf
culture the distinction
also refers to the individual’s preferred language, this
means people that are Deaf with big D prefer sign language over any other
language and deaf people use other languages as well

(Wang, 2010)
.




11


In Sub
-
Saharan Africa m
any

Deaf
1

children
are
not
diagnosed
early enough,
or their families do not have the means, to take advantage of the specialised
treatment and education required to teach Deaf children
at a
n

early
stage in
their lives
so that they do not miss
out on
a
solid e
ducational
foundation

(Kennedy, 1995)
.

As
direct

result illiteracy

is very common in Deaf
communities
,
and in Sub
-
Saharan Africa
a further

cause
of low literacy levels
,
is

poverty.

Aspects of l
ife
that literate people take for granted,
is
often
difficult
for
the
illiterate
. F
or example

instructions on how to take medication

and when
to take it, can become a major pro
blem fo
r an illiterate person.
This can result
in non
-
compliance of treatment

which
can lead to

the worsening of the
condition
or even
a
fatality that

could have been avoid
ed
.

Deaf people
use

mobile phones, but
do not

utilize all the various applications
available to them

effectively
(D. J. Power, 2007)
.
The most
common

reason

being that

many of the applications are audio based and
furthermore

that
many

Deaf

people

are functionally illiterate.
The term “functionally illiterate” means
that although a person may be able to read and write a few words of a spo
ken
language (such as English), they do
not do
so well enough to deal with the
requirements of everyday life

(Ros Dowse, 2001)

The aim of this project is to

design an application that could thus

improve
the
compliance

of medical treatment and thus
the quality of life of the Deaf as
well as the
illiterate
.
The application will be d
esign
ed for

a mobile
device

with

purpose of

remind
ing

patients

when it is time
to take their medication.
T
he
reminder, at a par
ticular point in time, will be in the form of a video that will



1

Deaf with a
capital ‘D’ refers to people whose first language is sign language and who are members of a
specific linguistic cultural group.





12

give instructions of how and when to take the medication prescribed by a
pharmacist or doctor.

User’s view of the proble
m

F
our
hearing
people were interviewed based on how they

would react to
persuasive technologies

and how they remind themselves of important tasks
and activities
during the day see Appendix A for the questionnaire used.
In t
he
interview the users were probed

about their general cell phone usage.
The
l
iterature on the Deaf commu
nity illiterate people and their general use of
mobile phone
s,

and other
reminder or persuasive technologies available, were
reviewed for further information.

Brief description of the problem domain

Deaf and illiterate people do not have a mobile applicati
on that

is

created
especially with

them in mind
,

that
reminds them when it is time to take their
medication and what the prescribed dosage for each pill or syrup they have to
take
,

is
.
This project

is aiming to help

the Deaf or illiterate to be compliant


thus take their medication correctly and at the right time.
This system is
designed to satisfy the needs of medical compliance in Deaf and illiterate
patients only.

Complete description of the problem

Deaf people
in South Africa often have problems communicating with hearing
people because they use sign
language

(SASL
)
,

and cannot use a

spoken
language. Many Deaf people have low written/spoken

(Kiyaga, 2003)

language literacy thus reading, writing and lip
-
reading are not op
tions for
them.
Sign language interpreter
s are very

expensive because registered

interpreters are not easily available in South Africa

(M. B. Motlhabi, 2011)
.
D
ue to
these

results

it was found that Deaf or illiterate patients are in need of a



13

reminder that will work specifically for them in a language they understand
(SASL
), reminding them when it is time for consumption of their medication
and to fol
low the instructions given by the pharmacist.

A major
ity

of people

in South
Africa own mobile phones and many

have
smartphones that allow
video playback, thus the solution of a mobile a
larm
reminder is a solution to the problem currently faced by

Deaf an
d illiterate
patients.

What is expected from a software solution

It must be capable of disrupting whatever the patient was busy with
; it must be
attention seeking
. It must
also
consist of a very clear vivid video
image
with
clear and easy to follow instructions. The software solution must also be very
user friendly to users that are functionally illiterate. The solution is expected to
be able to
remind patients

when it is time for medicine consumption and
how
to

consume
the medication.

This application is expected to work only on
Android phones of API

level 4 and above

What is not expected from a software solution

The syst
em will
be simple
because

it caters for functionally illiterate users.
The system should not have any busy or complex hardware and should only be
software. The system should not be audio based in anywa
y, it should also

not
have unclear picture or any forms of ambiguity that might
could
cause
confusion to the
user. The application

is network independent meaning the
system should be operational on all the different South African network
providers. The system is not expected to work for other phone than android
phones

of API level 4
and above.




14

Chapter Summary

This chapter focuses on viewing the problem from the user’s perspective. The
solution is based on the vital information acquired from the user.

In the next
chapter

the programmer’s view of the problem and how the
programmer will

try to solve the user’s problem

will be addressed as well as

to simulate and test
the application.




15

C
h a p t e r 2

REQUIREMENT ANALYSIS

DOCUMENT

Introduction

In this section

the problem
is considered
from
the
designer’s point of view.
However, instead of diving

directly
in
to implementation details, the analysis
focuses on the system and software requirements needed to implement the user
requirements. This section
does not delve into programming
details;

i
nstead,
it
takes the user’s requirements and clearly
ident
ifies

all factors that will affect
the solution that the user
wants.
The
analysis may indicate a preference for a
particular programming language that best suits the problem domain rather
than an algorithm to satisfy a particular requirement. The
requireme
nt analysis
document (
RAD
)

looks at the
user requirement document (
URD
)

as defining
an entire system, and then breaks the URD down into bite
-
size chunks (divide
and conquer). These chunks identify the subsystems of the overall solution,
and the relationshi
ps between them. But the RAD also goes further and
identifies the actual
details

of the problem that the user may not

be aware of.

Designer’s view of the problem

Users require an application on their

mobile phone
s

that will serve as
a
vibrating
alarm
reminder
that
will show a

very clear video of the different
medicine
s

and the different
dosages the user needs to consume. The
application
’s content will be designed with
input from the doctor or
pharmacist

in order to

be
ethical
when providing this type o
f
health care
trea
tment

(Barnett, 1999)





16

The system will act like a normal
sound/vibrating reminder except instead of
text
, a high quality
vibrating video will pop up. T
he video will have a play
button that is green to play and

may be
stop
ped

at any point

by simply
pressing the back button
. The video will consist of a set of
demonstrated
instructions
,

instructing

the user what medicine

the user is supposed to

take at
that particular time and the prescribed dosage the

user
should

consume
.
The
time and
type of medicine that needs to be administrated at the particular time

will be set by the pharmaci
st using the application on the phone that is already
pre
-
installed by the system administrator. This can be done during
consultation

a
nd

the setup will remain on the patient’s mobile
phone

for the specified time
period depending on the treatment time period
.


High level design of the solution

The user in
teracts with the system using the

application that will be

pre
-
installed on their

mob
ile phone
.

The user
simply
presses the play button that
appears when the reminder pops
up;

once the button is

pressed a video from
storage

is pulled and is played until it reaches the end or until the user presses
the
back

button. The reminder

is set on
t
he application by the pharmacist using
the patient’s phone
;

the reminder
is
then

stored on the patient’s mobile phone
SD card
. In

Figure 2
the SD card and its properties

on the mobile phone

and

Figure 3 shows the actual picture of the SD card
.





17


Figure
2
:
SD card and how information is stored
on the card or the phone.

(Ashish, 2013)


Figure
3
: Th
e different SD cards available and the
different sizes

(R
edOrbit, 2013)





18


Deep a
nalysis of these parts and detailing

The software application w
ill be implemented on any

Android
mobile phone

as an add on feature for the Sign

Support application. This phone will need to
have

a large screen, video playback capability and

no i
nternet access

required
.
The mobile phone’s large display screen assists in clear viewing. The user also
needs to have

an SD card which will be used to store the different videos by
the system administrato
r
.
How the system will work is as follows: w
hen it is
time for medicine intake a powerful vibration will come through consisting of
a video telling the user that this is an “alarm” using sign language until the
user

presses either the play or the back butt
on. A

video will fill the phone

screen and the user will have the option of pressing the play or stop
ping it by
pressing the back

button. Once the play button has been pressed, the video
takes over the screen and starts instructing the user what to do. Thi
s can then

be stopped by pressing the phone’s back

button or by reaching the end of the
clip.

How this appl
ication will work is: Sign language videos with instructions and
commands that the user will need to follow
when they taking the medication,
these

will be preinstalled on the SD card
. The

pharmacist will specify the time
,
date and
other
details
form “look
-
a
-
like” screen that is specifically for the
pharmacist
. The
time, date and details saved
on the application which is on the

mobile phone

and also

where the video
s are stored
. Once the video
is ready to
play,

the user will be prompt
ed

to enter input in the form of pressing the play
or stop

it by pressing the back

button. The play button will allow for the video
to start playing and the
phone’s back

b
utton will stop the video and allow for
the user to continue with whatever they were busy with.




19

Technologies that suggested to be used are the following: Google
Calendar
APIs
,
app inventor,
Eclipse
, SD
card
, desktop
.

In constructing the application
Eclipse will be used for creating the

application as it works with both Java and
Xml
. Java

primarily

working for

coding

the back
-
end of the application and
the Xml being the front
-
end.

MySQL for c
reating a database will not be
needed as the information needed is stored on the SD card.
Google APIs
app
inventor
was needed during the prototyping phase of the project but was later
on cut out as Eclipse covered everything.


Identifying existing solution
s

Existing mobile reminders on mobile phones

can be considered as a
solution
,

however

the problem with this solution is that most mobile

phone producers
produce audio
based alarm reminders and these are also catered for literate
people with at lea
st
some
basic mobile phone knowledge
.

T
he Deaf and
illiterate are not taken into consideration at all

with the existing reminder
systems
. Another problem with the existing mobile reminder is the fact that
the reminder should be set by the user itself, now this mea
ns that the user
would have to remember all the instructions given by the pharmacist and as
well as remember


to set the
reminder. The

user will also need
the expertise to
set the alarm
the actual mobile phone
.




20


Figure
4
:
An examp
le of the typical existing
solution

(Sugar, 2008)

The current Google Calendar system could
also
be considered as an existing
solution, however because it is text based it puts the
illiterate
people

at a great
disadvantage
. The
proposed system is aimed at solving these problems tha
t
current solutions lack
.





21


Figure
5
: The interface
of Google

Calendar

(http://www.google.co.za/url?sa.commons.wikime
dia.org/ACloud_computing, 2012)

Identify alternative technical solutions

The current alternative solutions work well for users that are literate and not
Deaf, alternative technical solution to these systems would have to involve
development that would accommodate Deaf people and as wel
l as illiterate
users. Such developmen
t would have to involve the elimination of

any audio
and text on the users interface. Colour would have to

be used extensively as
studies show that
illiterate

people recognize colour and visuals, indicating that
they r
emember colour and visuals

easier than
words

(Russell, 2006)
.



Best solution

The proposed solution

will
be similar to the
existing
solution
s

however it
is
incorporated into the application
SignSupport
.

SignSupport is a running



22

application that acts as a tool to bridge the communication barriers often
experienced by Deaf patients when visiting a pharmacy.
The
application
allows the pharmacist to be the person to
set

the reminder time and date,

meaning better instructions

and the chances of mistakes happening in the
setting up stages are curbed. The application

requires one action from the
patient that

is only pressing the play button. Once set re
minder is set by the
pharmacist and it is time a notification pops up on the deaf person’s side
allowing them to go over the instructions again.

Testing Methods

Testing methods will vary according the project plan. The first week of term 4
is mainly usability testing. Usabilit
y testing is

a technique used in

user
-
centered interaction
-
design

to evaluate a product by testing it on users
.

Performance testing would then follow soon the usability testing, testing the
general performance of the application
in terms of responsiveness
and stability
under a particular workload
. This could then be used to
investigate
,
measure,

validate or verify
other

quality attribute of the system, such
scalability,

reliability

and resource usage
. Acceptance test would then follow
to
determine

if the requirements of the
specification
s we
re met.

Multi
-
user
testing would soon follow allowing for multiple users to test the application
for the various multiple
instances of a functional

testing. The last week of the
term would end of with beta testi
ng.

Summary

In this chapter the requirements were analysed from the designer’s point of
view. The current solution relevant to the problem was analysed

and
alternative solutions

were considered. The solution
was then broken down into
small parts and test methods

were suggested. In the next chapter the user



23

interfaces are discussed and analysed.

In the next chapter user
the
interface of
the system will be investigated.




24

C h a p t e r

3

USER
INTERFACE SPECIFICAT
ION

Introduction

This section describes what the user interface

is going to do, what it looks like
and how the user interacts with the program. The UIS focuses in detail
specifically on the user interface itself.

The description of the UIS includes the
snap shots of the interfaces (screen
s
) that the user interacts with. This chapter
describes exactly what the user interface is going to do, what it looks like, and
how the user interacts with the program.

Description

of the complete user interface

The
user interface consists of two

different graphical user interfaces

(GUI);
one
is the pharmacist interface that is where the pharmacist will set up the
date, time and the
different dosages

to be followed by the Deaf patient when
taking their medication. The date and time of the application is dependent on
the network time and date as it uses 3G technologies to keep track of the time
date even if the phone has been off
.

The second interface is the Deaf person’s
interface, this is then called up when it is the appropriate time and date, as per
set by the pharmacist, a video of instructions of

how

a certain medication
should be taken and as well as display to the Deaf pati
ent the picture of this
medicine that they are supposed to take.

The user interface
s are

designed to
avoid ambiguity, to be simple

and easy for both the

user
s

to use.
The trend in
computer user interfaces seems to be more graphics and voice and less plain

text for both input and output.
(Richard Ladner, 1987)

. The adherence to the
usability design principles

i
s also very crucial and extra caution should be
taken in the implementation of this

solution,

the user that this solution is



25

catered for could solely be dependent on this application and this application
could be the one solution that ensures that the user is compliant to their
medication consumption .T
he solution is
simple and

not

clust
ered with text as
this solution
could also be used to cater for
illiterate users

as well
.


What the user interface looks like to the user

The application consists

of

two

main
interfaces; the in
terface on the

Deaf

patient’s phone and
the interface the pharm
acist
is

working on
. T
he

storage
system

(SD card)

is
hidden to both the pharmacist and patient.

The interfac
e of
the
Deaf
patient is

mainly buttons activated by a click and
video
s of
instructions, warnings, recommendations and the patient is expected to follow.

The interface of the pharmacist is also not that different from that of the Deaf
patient except for the fact that it has text and also that they are able to access
files l
ike patient background details and there is more text on the pharmacist’s
interface.

The f
igure
s that follow show a

step by step set of instructions of how
the

steps the

pharmacist

follows when interacting

with the application.






26




Figure
6
: The main menu where the
pharmacist has the option to select their profile.

(M. B. Motlhabi, 2011)

Figure 6 allows for the pharmacist to access the main screen of the application
where they have the option

of choosing their profile. They are then expected to
login with their practice number.




27




Figure
7
: Pharmacist logs in with their practice
number

(M. B. Motlhabi, 2011)




Figure
8
: The welcome page for the
pharmacist

(M. B. Motlhabi, 2011)




28





Figure
9
: Pharmacist verifies patient
identity

(M. B. Motlhabi, 2011)




Figure
10
: The patient background

(M. B.
Motlhabi, 2011)




29




Figure
11
: The Pharmacist is ready to dispense
medication to the patient

(M. B. Motlhabi, 2011)




Figure
12
: Medication the patient is suffering
from

(M. B. Motlhabi, 2011)




30




Figure
13
: Repeat treat
ment

(M. B. Motlhabi,
2011)




Figure
14
: Medicine name

(M. B. Motlhabi,
2011)




31




Figure
15
: Capture Screen where the
pharmacist would take a picture of the medication

(M. B. Motlhabi, 2011)



Figure
16
: The pharmacist would be dispensing

(M.
B. Motlhabi, 2011)




32





Figure
17
: This where the pharmacist would set
the time and date






33

Figure
18
: They have the option of setting multiple
alarms for one type of medication






Figure
19
: The
recommendations the patient
should follow

(M. B. Motlhabi, 2011)




34




Figure
20
: The warnings to follow

(M. B.
Motlhabi, 2011)





Figure
21
: Pharmacist done prescribing
medication for the deaf person

(M. B. Motlhabi,
2011)




35

The above figures show the different screens the pharmacist goes through
whilst dispensing medication for the Deaf p
atient. The figures that follow
show how the patient interacts with the application when it is the set time and
date.

The patient would get a notification in the form of a vibration that last for
about 10 seconds and when they open the notification figure
22 is what they
would see.




Figure
22
: The condition they suffering from
is explained in SASL to the Deaf patient

(M. B.
Motlhabi, 2011)






36


Figure
23
: They are able to see whether or not this
is a repeat treatment.

(M. B. Motlhabi, 2011)




Figure
24
: The patient is able to see the
picture of medication taken by the pharma
cist for
them to take.

(M. B. Motlhabi, 2011)






37


Figure
25
: Medication instructions for the
patient

(M. B. Motlhabi, 2011)



Figure
26
: The patient can view the warnings given
by the pharmacist





38



Figure
27
: The patient can view recommendations
from the pharmacist



Figure
28
: This tells the patient that the instruc
tions
have now come to an end.




39

These steps are what the Deaf patient gets to see when it is time for them to
take their medication.


The application also comprises

of a storage system

that will be invisible to the
patient and pharmacist. This will be where

first time
user’s information will be
stored

as well as the appropriate video will be stored
. This
storage system
(a

SD card
)

will be stored for video

storage and a
s well as a

database for storing
the patient information
.
This i
nterface
will consist of a form that will co
mprise

of a

registration form where all the
pharmacist’s details and the medication

details will be
captured and saved to

the SD card memory
.

How the user interface behaves

The

two interfaces
depend

on

each other; firstly

the pharmacist sets up a
reminder on a calendar at a particular time. The reminder set by the
pharmacist
is set as text and behaves like the normal audio based reminder and stores data
on the

hidden system. The interface on

the patient

side
is a

video that is
only
played once the user has opened the

notification
. Whilst
waiting for the user to
interact with it whilst the phone gives off a powerful vibration

that last for
about 10 seconds
.

How the user interacts with the system

The user’s interface give the user the option of playing or
repeating viewing of
video, if the user chooses to play the video then the information that was

kept
by the system in video form goes through and gets displayed to the patient in
the means of a vi
deo.




40

Summary

In this chapter a closer look at the User Interface was analysed, how it will
look like and how it will behave .This chapter also explained the interaction of
the user with the system. In the next chapter, the
higher level design is
analysed.




41

C h a p t e r

4

OBJECT ORIENED ANALY
SIS (HIGH LEVEL DESI
GN)

Introduction

In the previous chapter the user interface specification was discussed and
it is
explained
how the user
s

will interact with the system. This chapter focuses

on
the Object Oriente
d Analysis (OOA) or High Level
Design of the problem. A
detailed breakdow
n of the technical solution is
discussed. At this point no
algorithms will be disc
ussed. However, a set of class
diagrams will be given
with detailed interaction

between the mini syst
ems, including interface mini
systems.

Data dictionary

This defines exactly

what each object represents in
English
.

Object

Description

Deaf patient
Interface

(Video)

The
space where interaction between humans
and machines occurs.

Pharmacist Interface

This interface where the pharmacist will give
the duration of the treatment, dosages and the
times

Input

Data about the patient is stored
eg patient
medical condition, current treatment etc

Outpu
t

Data about the patient is retrieved
, the right
video for the right condition.

Stored as text on
the SD card.

Administrator

This ensures that video are on the system and
as well as the patient information is up
to
date.




42

Table
1
: Data dictionary consisting of the technical
terms explained English

User interaction design

The figure below

depicts
the

high level design of the solution from the point of
view of the user.

The diagrams depict

a simplified story of

how the pharmacist
and the Deaf patient

will interact with the application. The basic high level
functioning of the system follows the below steps
:

I.

The pharmacist chooses the duration

and instructions

of medicine

consumption.

II.

The pha
rmacist sets the date and the time on the application.

III.

The application stores the information given by the pharmacist and sets
a notification.

IV.

The notification is sent to the Alarm receiving class that will then
cause for a vibration to be sent to the pati
ent.

V.

A
notification
is received by the Deaf patient
.

VI.

When the Deaf patient opens the notification they view the instructions
and the “how to ” set by the pharmacist

The image (see Figure 29
) shows

the use
-
cases of how both the pharmacist
and patient intera
ct with the system

independently
.

Figure

29

shows that the
patient first registers as a new user, then fills in the
patient details from the
doctor’s prescription, the pharmacist then allocates the time period

the patient
should consume the
medication for.

The start and end dates are defined on the
application. The pharmacist sets when, during the day, the patient should



43

consume the medication
. Number of
pills

to

be consumed

by patient is
defined
, how they should be consumed
. The

registration details from the
pharmacist are then saved by the administrator on the
database.



Figure
29
: This is a use
-
case of how the pharmacist
interacts with the system

Figure 30

a use
-
case

of the interaction between the
Deaf
patient and the
system.
When the Deaf patient opens the notification they have received they
are able to view the instructions given by the pharmacist and play them.

That
is the only interaction the patient has with the

system and the system is fairly
easy to use, easy to remember and is
accessible
for
a
functionally illiterate
user.




44


Figure
30
: This is how the user and the system
interact

Figure 29 and Figure 30

show how the patient and the pharmacist interact with
the system.




45


C
lass diagrams
showing the name, attributes, and methods of each class
.


Deaf Patient Class

p
rivate int
videolength()

private String videoName()



public void playVid()

public void
stopVid()




Table
2
: Deaf patient

Class with attributes and
methods

The
Deaf patient

interface provides the users with a si
mple interface that
enables the patient
to see the video with the instructions. Table 2 shows all the
attributes and the methods included in the user interface class
.

When the user
opens the notification they would have received,

the method playVid () is
called, the method

enables the correct video to be pull
ed from the SD card

using the video name and the duration of the video as a way of searchi
ng for
the video in the SD card
. This class works
collaboratively with two other
classes namely the Input class and
Receiver class
. The Input class takes in all
the information entered
by the pharmacist and stores it. The
Receiver class
enables a notification to be sent to the Deaf patient’s phone
.






46



pharmacistInterface

private string name()

private float practiceNumber()

private Boolean consumptionPeriod()

private date StartDate()

private date Enddate()

private time Time()


public void
captureMedicine()

public void setDetails()

public void getDetails()



Table
3
: The pharmacist interface


The
pharmacist

interface provides t
he pharmacist

with a si
mple
interface that
enables him/her

to
capture patient details and to set the dates, time and how the
patient should take their medication
. Table
3

shows all the attributes and the
methods included in the
pharmacist

interface class.





47


Table 4
: The interaction
of all the interfaces




48

Table 4

shows all the different interfaces and how they interact with each
other.

Summary

In this chapter an analysis of the High Level De
sign

was obtained. The various
classes involved and how they interact with each other were described as
well
as
the relationship between them. The problem

solution was analysed from an
object oriented view. In the next chapter, the classes

discussed in this chapter
are
analysed further;

pseudo codes

of the solution are extracted from the
classes.











49

C h a p t e r 5

OBJECT ORIENTATED DE
SIGN (LOW LEVEL DESI
GN)

Introduction

In the previous chapter, the classes used to sol
ve the problem where looked at
together with their attributes and the relationship

between them. In this chapter
we take an even closer look at those classes,
so much as almost touching the
code. This will develop into pseudo
-
code, which is the closest thi
ng to the
code.




Figure
31
: The scenario case of a Deaf patient
visiting the pharmacist





50

Inner details of the class attributes

The following table

shows the inner details of the cla
sses with their attributes.
It
is the description of the attribute with
regards

to the type of data that they
represent.

Class

Attributes

UserInterface

VideoLength
-

get the video length for
identifying which video it is in the database

VideoName
-

gets the video name for
searching purposes.

PharmacistInterface

Duration
-

stores the time period the patient
should consume the medication for.

Time
-

stores the different times the patient
should consume the medication

Dosage
-

the dosages of the med
icine dosages

InputInterface

Pharmdetails
-
The input from the
pharmacist

PatientDetail
-

Inputs the patient details

OutputInterface

PharmDetails
-
Returns pharmacist information

PatientDetails
-
Returns patient information


Videodata


VideoName
-

gets the vi
deo name for
searching purposes and displays the right
video.

Duration
-

video length

whilst playing


Table

5
: Classes and the attributes

Inner de
tails of the class methods

The following table

( Table 5)

shows the inner details of the class methods.

It
is the description of the methods in simple English.

T
able

5

gives the classes and the attributes of the classes in English.

The
attributes listed are explained
in terms of
what their roles are in their
respective classes.




51


Class

Methods

UserInterface

playVid()
-

The method that plays the
video that has been
generated.

stopVid()
-

The method that stops the
video that has been generated.

displayVid() The method that actually
creates a canvas for playing the video

Pharmacist
Interface

OnCreate()
-

C
reates
the activity

OnCreateMenu()
-
Inflate the menu;
this
adds items to the action bar if it is
present.

Allows the activity to be
visible.

InputInterface

setPatientInfo()

setPharmacistInfo()

setVideo()

OutputInterface

getVideo()

getPatientInfo()

getPharmicistInfo()



Table
6: Table of classes

and methods.

T
able

6

give
s the classes and the methods

of the classes in English. The
attributes listed above are also explained what their roles are in their respective
classes.




52

Pseudo code of the application

Below is the proposed pseudo code of the application. This
pseudo code shows
how the interfaces interact with each other, how they function and lists the
methods in not so much detail.

When clockSystemTimer

{

Display currentTime


Countdown to medication time

}

Def

alarmOn = F
alse;

Def alarmTimeInstance =
F
alse;

convertInput= timeInput

choose length.timeInput =0

then

0

else


return abs.time.Input


set Button.click
{

when
Set
Button is
Click

{



alarmTimeInstance = clockAlarm.Now


alarmTimeInstance = clockAlarm.Addhours





clockAlarmHours =
alarmTimeInstance






alarmTimeInstance convertInput to txtHour.text


alarmTimeInstance = clockAlarm.AddMinutes






clockAlarm.Timer
Enabled = True






buttonStop.Visible = True


}

}

when clockAlarm.Timer

{

If

(
clockAlarm.GetMillis(clockAlarm.Now)
>
cloc
k
Alarm.GetMillis(alarmTimeInstance)
)




clockAlarm.TimerEnabled= False




53





alarmOn = True





go to the receiver Class()

}


When received by the receiver class{

Send a notification to the Deaf patient’s phone

}

When notification is received on the phone and opened{

Deaf patient can playback the instructions set by the pharmacist

They can repeat or exit when done

}

Summary

In this chapter the low level design

solution was discussed and a pseudo code,
code required
to understand the solution, was

developed. The various
classes’

attributes

and method
s were explained in detail. In the next chapter, we
implement the solution bas
ed on the pseudo
code obtained
here. The document
code will be produced in the next chapter.





54

C h a p t e r

6

CODE DOCUMENTATION


Introduction

In the preceding

chapter, classes were identified and their related attributes and
methods were shown. In this chapter, the code docume
ntation will be
presented and each class will be briefly examined and described.

Progress

This project has not been rigid it has been changing over the few months.
There
have been great and significant changes:

Term 2



A stand
-
alone video reminder was
created as a prototype.



App Inventor was used for coding the prototype.



The prototype was able to notify but not instruct the user how to take
the medication.

Term 3



Integrated the video reminder into SignSupport application.



Android consisting of Java

was

used

for coding the back end and Xml
for coding the
front end.



The video reminder was able to notify and instruct the Deaf patient
when it is time to take their medication and how to go about taking
their medication.






55

Challenges

There were expectations that were not fulfilled whilst coding the application,
but these could be improved in the future. The application could have allowed
more flexibility on the pharmacists side, the application was planned
in a way
so that it would
all
ow the pharmacist to alter and change instructions and
dosage intakes. However because this application was an add feature to
SignSupport, which is a running application, the flexibility and freedom was
not possible to achieve as SignSupport comes with alr
eady recorded videos of
certain
instructions, dosages and consumption times in SASL.

The application was also planned to be able to notify the Deaf patient even
when the Deaf patients’ phone is off. This also proved to be impossible
because sometimes the p
atient’s phone would be off because of a flat battery
and the when the patient’s battery is flat is nothing that can be done.

During the planning stages of the project it had been planned that the
application could be aligned with Google Calendar however
it also proved to
be impossible because Google Calendar does not cater for video storage and is
only text and audio based.

Future work

In the future the application could include a flash light that would work as a
tool to notify along with the powerful vib
ration that is already working. The
application could also include a repeating notification if the patient did not
open the notification the first time the notification was received.




56


Code documentation

The following class

codes will be presented:



Pharmacist selecting the date and time for the patient.



The
option for

the pharmacist to set another alarm for the same pill.



Class for the pharmacist the set a repeat date and time.



Two alarm receiver classes with the vibration used to notify the user.

P
harmacist date and time selector class

/**Class Date and time picker allows the pharmacist to set the and time the
deaf user is suppose
d

to take their medication


* T
his will release a notification with instructions how the user should take
their
medication, when it is the right time


* This class was constructed using the websites:


* https://github.com/benbahrenburg/benCoding.AlarmManager


* http://www.appsrox.com/android/tutorials/remindme/3/#8


* http://blog.blundell
-
apps.com/notification
-
for
-
a
-
user
-
chosen
-
time/


* http://stackoverflow.com/questions/3226495/android
-
exit
-
application
-
code


* http://stackoverflow.com/questions/6898770/android
-
multiple
-
alarms
-
w
-
pending
-
intents
-
how
-
to
-
determine
-
which
-
intent
-
is
-
b




57


*
http://gitorious.org/0xdroid/packag
es_apps_alarmclock/source/185d17974729
a98cf48a71ab9f16adaab9d1e1e0:src/com/android/alarmclock/AlarmClock.jav
a


* http://android
-
er.blogspot.com/2012/05/to
-
schedule
-
repeating
-
alarm
-
call.html


* Created by : Buhle Bongco and added on the sign support applica
tion by
Michael Motlhabi*/

package com.michaelmotlhabi.signsupportv3;// Package of SignSupport


import java.util.Calendar;// importing the calendar allows the user to identify
the current date and time

import android.os.Bundle;

import android.app.Activity;
// importing activity allows for multiple activities
to occur in one class

import android.app.AlarmManager;// importing the Alarmmanager allows the
activity to be able to set date and time as well as call up an alarm.

import android.app.PendingIntent;// i
mporting the PendingIntent for calling up
intent and pendingIntent methods.




58

import android.content.Context;// It allows access to application
-
specific
resources and classes, as well as up
-
calls for application
-
level operations such
as launching activities,

broadcasting and receiving intents, etc.

import android.content.Intent;//An intent is an abstract description of an
operation to be performed. It can be used with startActivity to launch an
Activity, broadcastIntent to send it to any interested BroadcastR
eceiver
components, and startService(Intent) or bindService(Intent,
ServiceConnection, int) to communicate with a background Service.

import android.view.View;// All of the views in a window are arranged in a
single tree. You can add views either from code

or by specifying a tree of
views in one or more XML layout files. There are many specialized subclasses
of views that act as controls or are capable of displaying text, images, or other
content.

import android.view.View.OnClickListener;//Interface definit
ion for a
callback to be invoked when a view is clicked.

import android.widget.Button;//Represents a push
-
button widget. Push
-
buttons
can be pressed, or clicked, by the user to perform an action.

import android.widget.DatePicker;//Class to render a date
picker component to
select day, month and year in a pre
-
defined user interface.

import android.widget.ImageButton;//Displays a button with an image (instead
of text) that can be pressed or clicked by the user.

import android.widget.TextView;//Displays text

to the user and optionally
allows them to edit it. A TextView is a complete text editor.




59

import android.widget.TimePicker;//Class to render a time picker component
to select hour and minute in a pre
-
defined user interface.

import android.widget.Toast;//A
toast is a view containing a quick little
message for the user. The toast class helps you create and show those.


/**


* This is the Main Activity of our app.


* Here we allow the pharmacist to select a date,


* we then set a notification for that date to
appear in the status bar


*


* @author Buhle Bongco


*/

public class DateAndTimeSelector extends Activity{



DatePicker pickerDate;// This is the date picker used to select the date for our
notification

TimePicker pickerTime;// This is the time picker
used to select the time for our
notification




60

Button buttonSetAlarm;// The set button once clicked sets the time and date so
that a notification is called up

TextView info;// Variable for displaying pieces of information

ImageButton next;// Button for mo
ving to the next page.



final static int RQS_1 = 1;




/** Called when the activity is first created. */

@Override

protected void onCreate(Bundle savedInstanceState) {


super.onCreate(savedInstanceState);


setContentView(R.layout.activity_main
);// this will pull the xml file
named activity





next
=(ImageButton)findViewById(R.id.imageButton1);//imageButton1 id is
pulled and will be accessible when the next button is pressed.


info = (TextView)findViewById(R.id.info);//text is stored as id
info
and accessible through the name info




61


pickerDate = (DatePicker)findViewById(R.id.pickerdate);// id
pickerdate


pickerTime = (TimePicker)findViewById(R.id.pickertime);// id
pickertime





/** The button next is pressed it goes to a method that perf
orms an
action when pressed */


next.setOnClickListener(new View.OnClickListener(){







public void onClick(View v) {





//myVib.vibrate(100);





goNext(); // method goNext() is called



}


});





Calendar now = Calendar.ge
tInstance();


// Get the date from our datepicker


pickerDate.init(




62





now.get(Calendar.YEAR), // this is where th user has the option
to change the year





now.get(Calendar.MONTH), //option to change the month





now.get(Calendar.DAY_OF_MONTH), // op
tion to change the
day.





null);





pickerTime.setCurrentHour(now.get(Calendar.HOUR_OF_DAY));//
Gets the hours of the day


pickerTime.setCurrentMinute(now.get(Calendar.MINUTE));// picks
the minutes


/**


* This is the onClick called from the XML

to set a new notification



*/





buttonSetAlarm = (Button)findViewById(R.id.setalarm);// When this
button is clicked it sets the choosen date and time


buttonSetAlarm.setOnClickListener(new OnClickListener(){//
listener for when the butto

is clicked




63




/**The following method that compares the set time to the current
time and if the set time is equal to or less than





* the current time it then handles tells the user it is an invalid time
and date*/




@Override




public void onClick(
View arg0) {





Calendar current = Calendar.getInstance();










Calendar cal = Calendar.getInstance();





cal.set(pickerDate.getYear(),







pickerDate.getMonth(),







pickerDate.getDayOfMonth(),







pickerTime.getCurrentHour(),







pickerTime.getCurrentMinute(),







00);










if(cal.compareTo(current) <= 0){// checks here if the current date
is equal to the set date




64






//The set Date/Time already passed






Toast.makeText(getApplicationContext(),








"Invalid Date
/Time", // tell the user it is the invalid date and
time








Toast.LENGTH_LONG).show();//exception handling





}else{






setAlarm(cal);// sets the alarm if it is not an invalid time





}









}});// ButtonSetAlarm is closed here








}//

end of the DateAndTimeSelector class


/**


* The method setAlarm is activated and the alarm for the specified time
and calls up the receiver class AlarmReceiver.


*/

private void setAlarm(Calendar targetCal){




65



info.setText("
\
n
\
n***
\
n"





+ "Alarm is set@ " + targetCal.getTime() + "
\
n"





+ "***
\
n");// the information that lets the pharmacist know/
verify for when they have set the alarm for.





Intent intent = new Intent(getBaseContext(),
AlarmReceiver.class);//an instance for intent h
as been set


PendingIntent pendingIntent =
PendingIntent.getBroadcast(getBaseContext(), RQS_1, intent, 0);


AlarmManager alarmManager =
(AlarmManager)getSystemService(Context.ALARM_SERVICE);


alarmManager.set(AlarmManager.RTC_WAKEUP,
targetCal.getTimeI
nMillis(), pendingIntent);




}

/**The method goNext that allows the pharmacist to go to the next screen on
clicking the next arrow */

private void goNext(){







66


Intent intent = new Intent(this, OptionForAlarm.class);// intent of
moving for the current

to the class
OptionForAlarm.class

which allows the
pharmacist to set another alarm in the class DateAndTimeSelector2 which is
identical to DateAndTimeSelector.


startActivity(intent);


//setContentView(R.layout.second_alarm);





}

}

The
alarm receiver class

/***


Copyright (c) 2008
-
2012 CommonsWare, LLC


Licensed under the
Apache

License, Version 2.0 (the "License");
you may not


use this file except in compliance with the License. You may
obtain a copy


of

the License at http://www.apache.org/licenses/LICENSE
-
2.0.
Unless required


by applicable law or agreed to in writing, software distributed
under the


License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
CONDITIONS


OF ANY KIND, either exp
ress or implied. See the License for the
specific


language governing permissions and limitations under the License.




From _The Busy Coder's Guide to Advanced Android Development_


http://commonsware.com/AdvAndroid

*/


package

com.michaelmotlhabi.signsupportv3;

/**Class created by
Buhle

Bongco


* The Class is a receiver class that extends the BroadCastReceiver


* */




67


import

android.app.KeyguardManager
;

import

android.app.Notification;
/**The Notification.Builder has
been added t
o make it easier to construct Notifications.*/


import

android.app.NotificationManager;
/**Notifications can take
different forms:


A persistent icon that goes in the status bar and is accessible
through the launcher, (when the user selects it, a designate
d
Intent can be launched),

Turning on or flashing LEDs on the device, or

Alerting the user by flashing the
backlight
, playing a sound, or
vibrating.


*/

import

android.app.PendingIntent;
/**

By giving a PendingIntent to another application, you are grant
ing
it the right to perform

the operation you have specified as if the other application was
yourself (with the same permissions and identity).


As such, you should be careful about how you build the
PendingIntent
: almost always, for example, the base Intent


you supply should have the component name explicitly set to one of
your own components, to ensure it is ultimately


sent there and nowhere else.

*/

import

android.app.KeyguardManager.
KeyguardLock
;

import

android.content.BroadcastReceiver;
/**If you don't need to
send broadcasts across applications, consider using this class

with LocalBroadcastManager instead of the more general facilities
described below. This will give you a much more efficient
implementa
tion

(no cross
-
process communication needed) and allow you to avoid
thinking about any security issues related to other applications
being able


to receive or send your broadcasts.

*/

import

android.content.Context;

import

android.content.Intent;
/**An In
tent provides a facility for
performing late runtime binding between the code in different
applications.

Its most significant use is in the launching of activities, where
it can be thought of as the glue between activities. It is
basically a passive data

structure holding an abstract description of an action to be
performed.

*/

import

android.os.PowerManager
;

import

android.os.Vibrator;
/**If your process exits, any vibration
you started with will stop.




68

To obtain an instance of the system
vibrator
, call
getSystemService(String) with VIBRATOR_SERVICE as argument. */

import

android.support.v4.app.NotificationCompat;

import

android.widget.Toast;
/**When the view is shown to the user,
appears as a floating view over the application. It will never
receive focus
.

The user will probably be in the middle of typing something else.
The idea is to be as
unobtrusive

as possible, while still showing
the user the information you want them to see.


Two examples are the volume control, and the brief message saying
that yo
ur settings have been saved.

The easiest way to use this class is to call one of the static
methods that constructs everything you need and returns a new Toast
object.

*/

/**The alarm receiver class starts here*/

public

class

AlarmReceiver
extends

Broadc
astReceiver {



private

static

final

int

MY_NOTIFICATION_ID
=1;
// A unique
notification id created so that it is not overwritten by other
notifications created.






NotificationManager
notificationManager
;
// an instance of
notification manager


Notification
myNotification
;
// an instance




/**When the alarm set by the
pharmacist

is received by this
receiver class it creates a notification, vibrates and calls up
the class RefresherViewInstruction



* Once the notification is opened by the deaf pa
tient it allows
the patient to view all the instruction and
dosages

that were given
by the
pharmacist

*/


@Override


public

void

onReceive(Context context, Intent intent) {



Toast.
makeText
(context,
"Alarm received!"
,
Toast.
LENGTH_LONG
).show();
// A toast is received the deaf patient







Vibrator vibrator = (Vibrator)
context.getSystemService(Context.
VIBRATOR_SERVICE
);
// The
vibrator

class is called up




vibrator.vibrate(10000);
//This creates a vibration that lasts
for 10 seconds




Inten
t myIntent =
new

Intent(context,
RefresherViewInstructions.
class
);
// when the notification is opened
it goes to the class RefresherViewInstructions.class



PendingIntent pendingIntent = PendingIntent.
getActivity
(





context,




69





0,





myIntent,





Intent.
FLAG_ACTIVITY_NEW_TASK
);
/**If set, this activity
will become the start of a new task on this history stack.





A task (from the activity that started it to the next
task activity) defines an atomic group o
f activities that the user
can move to.





Tasks can be moved to the foreground and background; all
of the activities inside of a particular task always remain in the
same order. */



/**This is where the notification details are entered like,

the icon that should be displayed, the sound made by the
notification (in my case the vibration)



* The title that should be displayed on the notification



* The text and ticker */



myNotification

=
new

NotificationCompat.Builder(context)





.setContentTitle(
"Medication Consumption Notification!"
)





.setContentText(
"Follow this instructions to take the correct
medication"
)





.setTicker(
"Notification!"
)





.setWhen(System.
currentTimeMillis
())





.setContentIntent(
pendingIntent)





.setDefaults(Notification.
DEFAULT_SOUND
)
//Use the default
notification sound. This will ignore any given sound





.setAutoCancel(
true
)





.setSmallIcon(R.drawable.
ic_launcher
)





.build();








/**This where the id
entity of the notification is called, if there
many notification it identifies which one is being called.*/




notificationManager

=





(NotificationManager)context.getSystemService(Context.
NOTIFICATION
_SERVICE
);



notificationManager
.notify(
MY_NOTIFICATION_ID
,
myNotification
);
// notification id


















}


}




70

The option for the pharmacist to set a second alarm

/**


*Author:
@Buhle

Bongco


*This calls allows for the
pharmacist

to set up to 3 alarms


*This asks the
pharmacist

if they would like to set another alarm


*This is included to the
Michael

Motlhabi

package*/

package

com.michaelmotlhabi.signsupportv3;



import

java.io.FileOutputStream
;

import

java.io.IOException
;

import

java.io.OutputStreamWriter
;


import

android.app.A
ctivity;
/**To be of use with
Context.startActivity(), all activity classes must have a
corresponding
<activity>


declaration in their package's AndroidManifest.xml.


*/

import

android.content.Intent;
/**An Intent provides a facility for
performing late
runtime binding between the code in different
applications.


Its most significant use is in the launching of activities, where
it can be thought of as the glue between activities.


It is basically a passive data structure holding an abstract
description o
f an action to be performed.

*/

import

android.os.Bundle;

import

android.os.Vibrator;
/**If your process exits, any vibration
you started with will stop.

To obtain an instance of the system
vibrator
, call
getSystemService(String) with VIBRATOR_SERVICE as a
rgument. */

import

android.view.View;
/**Visual indicator of progress in some
operation.


Space Space is a lightweight View subclass that may be used to
create gaps between components in general purpose layouts.


SurfaceView Provides a dedicated drawing
surface embedded inside
of a view hierarchy.


TextView Displays text to the user and optionally allows them to
edit it. TextureView

*/

import

android.widget.Button
;

import

android.widget.EditText
;

import

android.widget.ImageButton;
/**Displays a button with an
image (instead of text) that can be pressed or clicked by the user.

By default, an ImageButton looks like a regular Button, with the
standard button background that changes color during different
button states.




71


The image on t
he surface of the button is defined either by the
android:src attribute in the XML element or by the
setImageResource(
int
) method.

*/


/** The class that allows for the
pharmacist

have the option to set
another alarm*/

public

class

OptionForAlarm
extends

A
ctivity {




ImageButton
next
;
// the image button that allows the set another
alarm if clicked


ImageButton
conflict
;
//the image button that allows the
pharmacist

to go another page if clicked


private

Vibrator
myVib
;
// the vibration





/** Called

when the activity is first created. */


@Override


public

void

onCreate(Bundle savedInstanceState) {


super
.onCreate(savedInstanceState);


setContentView(R.layout.
second_alarm
);




next

= (ImageButton)
findViewById(R.id.
imageButton1
);
// the
image button identifier that allows the set another alarm if
clicked


conflict

= (ImageButton) findViewById(R.id.
imageButton2
);
//
the image button identifier that allows the
pharmacist

to go to the