A MOBILE APPLICATION TO

INTERACT WITH A MESH

BILLING SYSTEM

By
Zine Tshaka
A project document submitted in partial
fulfillment of the requirements for the
degree of

BSc Honours (Computer Science)

University of the Western Cape

2013

Date: November 09 ,2013

 University of the Western Cape
Abstract
A Mobile application to interact with a Mesh billing system
By
Zine Tshaka

Supervisory: Professor I.M Venter

Co-Supervisor: Professor WD Tucker
Mentor: Carlos Rey-Moreno
Department of Computer science
ABSTRACT
The cost of making a call and sending a text message in most parts of East-
ern Cape is extremely high. The mesh potato network aims to help people
from rural areas to make calls for free (or almost free). Due to the fact that
material needs to be maintained, it was decided by the authorities that
maintenance fee must be paid to keep the system going. Therefore a nominal
fee must be paid. The mesh billing system will be used to collect money for
the maintenance of the network. The aim of this project is to create an inter-
face between the billing system and the users so that monthly updates can be
received via Short Message Service or queried using Unstructured Supple-
mentary Service .The mesh billing system will specify the number of calls a
person can make for a certain fee before having to recharge again. To collect
the requirements of the system, seven people from the Delft community orig-
inally from Eastern Cape were interviewed. Discussing this with people and
after some interviews they indicated that a new system needs to be devel-
oped. A system was the designed developed and implemented using IDE for
java developers, android tools (android SDK), java development kit (JDK)
and Java Runtime Environment (JRE). The system was then tested using 2
types of testing which are usability and functionality testing. During testing a
positive feedback was received from participants
 TABLE OF CONTENTS

Table of Contents i
List of figures iii
List of tables iv
Acknowledgement v
Glossary vi
CHAPTER 1 1
user REQUIREMENTs DOCUMENT 1
Background 1
User’s view of the problem 1
Brief description of the problem domain 2
What is expected from the software 2
What is not expected from a software solution 2
Summary 2
CHAPTER 2 3
Requirement Analysis Document 3
Introduction 3
Designers interpretation of the user’s requirements 3
Breaking down the problem into high level constituent parts 4
Identify existing solutions 5
Technologies to be used 5
Devise ways to test the solution 5
Summary 5
CHAPTER 3 6
User interface specifications 6
Introduction 6
Description of the complete User Interface 6
What the user interface looks 6
How the user interface behaves 10
How the user interacts with the system 10
Summary 11
CHAPTER4 12
Object oriented ANALYSIS 12
Introduction 12
Data dictionary defining exactly what each object represents 12
Class diagram 13
Summary 15
CHAPTER5 17
Object oriented design or low level design 17
Introduction 17

i
 Inner details of class attributes (data types) 17
Inner details of class methods (functions) 19
Pseudo-code1 19
Summary 20
CHAPTER6 21
Implementation 21
Introduction 21
Software Deployment 21
Progress 22
Challenges 23
Source code 23
Reading Text File 32
SUMMARY 33
CHAPTER 7 34
Testing 34
Introduction 34
What is testing? 34
Planning the test 34
Functionality testing 35
Usability testing 35
Functionality testing procedure 35
Usability testing procedure 36
Testing discussion 38
Summary 38
CHAPTER8 40
USER GUIDE 40
Introduction 40
System’s requirements 40
Installing application 40
How the system works? 41
Summary 47

Appendices 48
Appendix A 48
Interview probes 48
Project description 48
APPENDIX B 49
Appendix C 51
Appendix D 52
Appendix E 53
Appendix f 54
Appendix f 58
Bibliography 60

Index 61

ii
 LIST OF FIGURES

Number Page
FIGURE 1 HOW USSD WORKS FOR MANY USERS (MIG, 2012) 4
FIGURE 2 DIALING A CODE 7
FIGURE 3 ERROR MESSAGE 7
FIGURE 4 DISPLAYING OPTIONS 8
FIGURE 5 LOGIN 9
FIGURE 6 USER’S BALANCE DISPLAYED 9
FIGURE 7 REGISTERING A NEW USER 10
FIGURE 8 USE CASE DIAGRAM 11
FIGURE 9 CLASS DIAGRAM 15
FIGURE 10 IMPLEMENTATION 22
FIGURE 11 CHANGES IN AN INTERFACE 22
FIGURE 12 FUNCTIONALITY TESTING RESULTS 36
FIGURE 14 ANDROID MAIN SCREEN 41
FIGURE 15 APPLICATION MAIN SCREEN 42
FIGURE 16 ERROR MESSAGE 43
FIGURE 17 OPTIONS 44
FIGURE 18 REGISTRATION FORM 45
FIGURE 19 LOG IN 46
FIGURE 20 SHOWING USER'S BALANCE 47

iii
 LIST OF TABLES

Number Page
TABLE 1 CLASSES 12
TABLE 2 USER 13
TABLE 3 REGISTER 13
TABLE 4 UPDATE 14
TABLE 5 CHECK BALANCE 14
TABLE 6 ATTRIBUTES EXPLAINED 18
TABLE 7 FUNCTIONS EXPLAINED 19
TABLE 8 PROJECT PLAN FOR TERM 1 51
TABLE 9 TERM 2 PROJECT PLAN 52
TABLE 10 TERM4 PLANNING 54

iv
 ACKNOWLEDGEMENT

Firstly, I would like to acknowledge the Almighty God for his guidance and
wisdom throughout the process of completing this project. I would like to
express my gratitude to my supervisor Professor Isabelle Venter who gave
me the golden opportunity to do this wonderful project which also helped me
in doing a lot of Research and I came to know about so many new things I
am really thankful to her. It is not often that one finds a supervisor that al-
ways finds the time for listening to the little problems and roadblocks that
unavoidably crop up in the course of performing research.
My parents, Mr and Mrs Tshaka, receive my deepest gratitude and love for
their dedication and the many years of support during my undergraduate
studies that provided the foundation for this project.
The friendship of Buhle Bongco, Siphokazi Dayile and all of my classmates
is much appreciated and has led to many interesting and good-spirited dis-
cussions relating to this project.

v
 GLOSSARY

Emulator - a software application that can accurately imitate another

computer, mobile phone, device or even arcade machine and run software
from that computer (http://cplus.about.com/od/glossar1/g/emulator.htm)
GSMG - Global System for Mobile communications
(http://cellphones.about.com/od/phoneglossary/g/gsm.htm)
Graphical user interface - A visual way of interacting with a computer using
items such as windows, icons, and menus, used by most modern operating
systems.(http://www.webopedia.com/TERM/G/Graphical_User_Interface_GU
I.html)
High level Design – A first step to analyze and consider all requirements for a
software and attempt to define a structure which is able to fulfill them
(http://www.the-software-experts.de/e_dta-sw-design-high-level.htm)
Mobile phone - a wireless handheld device that allows users to
make calls and send text messages, among other features
(http://www.techopedia.com/definition/2955/mobile-phone)
MSC - the mobile service center, a switching center for mobile
device
Mysql- a relational database management system (RDBMS) that
runs as a server providing multi-user access to a number of
databases (http://dev.mysql.com/doc/refman/5.5/en/mysql.html)
MySQLite (http://answers.oreilly.com/topic/1914-what-is-sqlite/)
SMS- Short message service is a system that allows one to send
and receive a text message in a cell phone (1)
USSD -Unstructured Supplementary Service Data is a protocol
used by GSM based mobile phones to communicate with the
network operator's compute
(http://searchnetworking.techtarget.com/definition/USSD)

vi
 Chapter 1

USER REQUIREMENTS DOCUMENT

Background
A mesh potato is a device that provides low-cost telephony and Internet
services in areas where alternative access doesn’t exist or is too expen-
sive. A mesh potato system was implemented in the Mankosi district (a
rural area in Eastern Cape) to overcome the communication problems that
are faced by the people of Mankosi. A mesh billing system will be im-
plemented to collect money for the maintenance of the mesh network.
The system that is proposed will allow people of Mankosi easy access to
their mesh potato network bills/status.
Currently to see how much they owe, they will have to go the place
where the mesh potato is situated and ask for the current status of their
account. The proposed system will allow the Mankosi community easy
access to their account whenever they want to do so. In this chapter the
requirements of such a system are described as elicited and described by
users acquired with the situation in Mankosi. The proposed application
will be used to interact with the mesh billing system as well as the admin-
istrator of the system.

User’s view of the problem

To get to know the user’s view of the problem, people from Delft (origi-
nally from Eastern Cape) were interviewed using a list of probes (see
Appendix A). Most of these cell phones users seem to have experienced
the same problems with their cell phones: they do not know exactly when
to recharge their phones and they do not have easy access to the status of
their “pre-paid bills”.
Some indicated that they would not like to cover long distances just to
recharge their credit for when they still have credit on their accounts. If it
cannot be done remotely they would have to walk to the mesh potato of-
fice in order to view the amount they still have to their accounts. They
were also concerned that such system might not be easy for them to un-
derstand and suggested that the new system should be clear and easy to
use.
Brief description of the problem domain
If the people from Mankosi village using the mesh potato network can
only access their mesh network account access physically going to the
place where the mesh network office is located – it will be inconvenient.

What is expected from the software

The system is expected to be able to accurately send information to the
user when the user requests it via USSD. The system is expected to ac-
commodate everyone, even those who do not use a “smart” phone

What is not expected from a software solution

The system will not be expected to keep all the previous bills. After 30
days the system will no longer have records of the previous month.

Summary
In this chapter the problem is stated and the user’s requirements for the
billing of a mesh system (to be implemented) are stated. In the next chap-
ter the user’s requirements will be analyzed in terms of what is possible
with the technologies available and the time allocated for the project.

2
 Chapter 2

REQUIREMENT ANALYSIS DOCUMENT

Introduction
In the previous chapter the user’s requirements and the problems of a
mobile phone application that can interact with a mesh billing system,
were identified and explained. In this chapter the requirements will be
analyzed and solutions to the problems will be posed.

Designers interpretation of the user’s requirements

In the previous chapter the problem and the user’s requirements for the
system was briefly described. The requirements are now revisited and
possible solutions for each requirement are stated below
Requirements
1. Users specified that the system must not require a specific phone; a
user must be able to use the system even on a non-smart phone.
2. The system must not require some passwords in order to access it
3. System must not involve long and complicated processes
4. System must be safe and secured
Solutions
Solutions to all of these requirements are:
1. An automatic monthly statement will be sent to all us-
ers
2. And USSD will be used the query the bills during the
month,
The system will be free to all the users; a user could use the system even
if their airtime credit is “0” on their cell phone account. The user must
register once with the system, the system must be able to retrieve the us-
er’s information for the registered user using a user’s phone number. The
figure below is an illustration of how a USSD is sent to many users. It
shows a number of users dialing a USSD code and that code is then veri-
fied on the server if correct it the send the request, each phone number
will then be checked if it is registered on the database.
 Figure 1 How USSD works for
many users (MIG, 2012)

Breaking down the problem into high level

constituent parts
The user interacts with the system using a mobile phone using a certain
USSD code to check his or her mesh network account. The following is
the breakdown of how the system works:

4
 A user sends USSD code to the server. The server receives a request
from the user and a communication between a user and a network is cre-
ated. The server checks the user’s bill from the database and sends the
current status to the user.

Identify existing solutions

There are a lot of successful and implemented systems that are using
USSD system. One of these systems includes a Vodacom system for Air-
time transfer
This system has been used by Vodacom subscribers to send airtime from
your cell phone to any other Vodacom Prepaid phone *120*1234#. This
airtime transfer system is available and can be used by any Vodacom
prepaid customers. For this system users do not have to register at all if
you are a Vodacom subscriber the system is already registered.
This mobile application to interact with mesh billing system application
will adapt some of the features from this Airtime transfer system of
Vodacom.

Technologies to be used
Net Beans Java
MySQL for database installations
NET, PHP, Java for connecting applications to the mobile world
Android JDK and Eclipse

Devise ways to test the solution

An evaluation of a system’s functionality will be done by testing it on a
group of users. The users that initially gave the requirements (the people
from Delft) will be asked to evaluate the system. When testing system
users will be asked to interact with the system using a mobile phone to
determine whether the system produces the expected results or performs
in the desired manner and see what must be improved from the system.

Summary
This chapter gives a brief description of designer’s view of the problem,
the possible solutions to the problem; ways in which the system will be
tested and Breaking down the problem into high level constituent parts
 Chapter 3

USER INTERFACE SPECIFICATIONS

Introduction
In Chapter 2, the user’s requirements were identified; analyzed and some
possible solutions were identified. This chapter will be describing what
the user interface is going to do and how the user will interact with the
interface of this application. The requirements from Chapter 2 will be
used to detail the behavior of the program. The user interface provides
the means for the user to interact with the program. The user interface
specification (UIS) is intended to convey the general idea for the user in-
terface design and the operational concept for the application.

Description of the complete User Interface

The application is designed to be very user friendly since it will be used
by rural people. The application provides a simple user interface that is
very easy to use with less text and more graphics this way makes it easy
for the user to find whatever they will be looking for with less effort.
The application will be used in 2 ways SMS and USSD code request. An
SMS will be sent using the system to everyone that owns a device in their
house in the village but if a user is interested to know his/her status dur-
ing the month they can still do so by dialing a USSD that will be given to
them. Using that USSD code a user is able to register, update a profile
and check their mesh network balances for the month.

What the user interface looks

The first screen that the user will see when starting an application is the
screen below (figure 2). This screen allows a user to enter a USSD code.
It looks like any mobile phone dialing screen. The screen contains a send
button that will be used to send a code when done dialing. If a user wants
to end an application they can still do so by just shutting an application.

6
 Figure 2 Dialing a code

After sending a USSD code, the code is then verified if it is the correct
code. If the code is incorrect an error message will popup, a user will then
be given an option to correct the code or to end an application. The figure
below (figure3) shows how the error message screen looks like.

Figure 3 Error message

More so; if a code is correct a user will then be taken through to the next
screen. The screen below will be displayed on the user’s phone. Figure 4
shows options that will be given to the user, a user can choose to check
balance or update a user profile.
 Figure 4 Displaying options

A user can choose any of the above showed options. If a user wants to
check a balance they will have to choose “Check Balance” option. And if
a user is new to the system they can register their mesh potato and phone
numbers to “register” option so that they may have a full access to the
system. when a user choose “Check Balance” option then a user will have
to provide his/ her details just to confirm that a user exists on the system.
Figure 6 below shows a screen where users will be requested to enter
their login details. A user phone number is the unique identifier; it is used
to uniquely identify each user on the system. A user phone number must
match with a password and an access will be granted. However if a pass-
word or a phone number is incorrect a user cannot login, again an error
message “incorrect username or password” will popup.

8
 Figure 5 Login

When correct details have been entered a user’s balance will be displayed
on the screen. Figure 6 below shows how the use’s balance will be
displayed to the user.

Figure 6 User’s balance

displayed

The screen below will be displayed when a user chooses “register” option
in screen displayed in figure 3. A user will be requested to enter their full
details in the registration form that will popup. However if a user enters a
phone number that is already on the system, a user can there not be
registered because a phone number is a unique identifier and it must
belong to only one user.

Figure 7 Registering a new user

How the user interface behaves

A user interface is designed to be a very user friendly interface. All the
USSD applications require a user to enter an input using a phone key-
board. This application is designed to use buttons instead of the usual text
to choose an option. This is will helpful because this application will then
later be used in Mankosi and most of rural people are old people and they
cannot write. Every time a system requests a user to enter an input, an
input is then verified and processed if it is correct else an error message is
displayed on the screen. A system first verifies users input (USSD code)
and displays an error message if the user enters incorrect code or moves
to the next screen if the code is correct. It then gives a user options and
still verifies the details. If the user provides appropriate data, he will be
authenticated and a balance will be displayed on the user’s screen.

How the user interacts with the system

The user starts an interaction with the application by dialing a code. The
system response by giving a user 2 options one for the new user and one

10
for the registered user. Or if a user is using an application for the first
time they will be directed to a page for new users for registration.
There are 2 options for the registered users which are update information
and check balance.
If a user wants to update their profile they enter their new details on a
given page and it will be saved on the database

Figure 8 Use case Diagram

Summary
This chapter deals with the user interface and how it interacts with the
user. A detailed user interface has been specified here, it explains how the
user interface will look like and also how it is expected to behave and in-
teract with the user .This chapter contains of a number of screen shots
that shows how the desired system will looks like and also a use case dia-
gram to show interaction between user and the system. In the next chap-
ter, the object oriented analysis (OOA) design will be specified.
 Chapter4

OBJECT ORIENTED ANALYSIS

Introduction
In the previous chapter the user interface specification was discussed and
how the user will interact with the system was explained. In this chapter
the high level design will be analyzed using the requirements as stated in
RAD (Chapter 2). This is an object-oriented view of the problem that is
the various objects required for the solution are defined and analyzed.
The relationship between the objects is shown while the class diagram
display the attributes and methods of each class.

Data dictionary defining exactly what each object

represents
A complete system will consist of 4 objects which are user, register, up-
date and check balance the following table (table1) explains each of these
objects into details. Each object is mentioned on the left column and ex-
plained on the right column with detailed description
Table 1 Classes

Objects Description
User This is any one that will be accessing the system.
Register This class will be used by the new users of the sys-
tem to get their details into the system so that they
may have full access to the system
Update This section will only be accessible to registered
users. If a user wants to change their information
they will be able to so by using this class
Check This class will be used by only registered users to
check balances every time they want to see their
balance.

12
Class diagram
Table 2 below represents user table. A user can be any one accessing an
application. Each user must be uniquely identified hence the attribute
User_ID. A user_cell number will be used when requesting a balance.
Table 2 User

User
attributes explanation
User_ID This will be used to uniquely identify each
user
User_cell number This will be used for sending a balance, a
requested balance will be sent to an
alternative cell phone number

A register object, this is the class that will be used by the users to register
their details on the system. The class is described into details below (Ta-
ble3). Like any object the must be an attribute that uniquely identifies it,
its primary key is registration number.
Table 3 Register

Register

Attributes explanation

Registration_number Uniquely identify each registration for

each user

Registration_date This will indicate the date when the user

first registered for the system

If a user changes his/her details and want to update their new details this
class that will be used to do so, an update class will have an update date
just to keep track of when the last time a user updated his / her details
was. The table below (table 4) explains the attributes that will be used for
this class

Table 4 Update

Update
Attributes explanation
Update-date A date when the users information was
updated
User_ID Will be used to identify which user is
updating information in a system. Will link
with a user’s primary key .this key is known
as foreign key

A check object will be used when a user is requesting a check balance

option; table5 below explains its attributes.
Table 5 check balance

Check
Attributes explanation
Check-date A date where the check balance was
requested
User_ID Identifying a user that is requesting a balance

Each objects of the system must communicate with each other to ensure
the feasibility of the system. The class diagram (Figure 9) shows the rela-
tionship between the all the possible objects of the system and how they
work together. The administrator controls the registration processes, up-
date and balance check process. It is also shown on the figure that a user
can register, update, or check balance.

14
 Figure 9 Class diagram

Summary
In this chapter the high level design was discussed .The various classes
involved in the completion of a project and how they are expected to in-
teract with each other was shown by means of diagrams and tables .In the
next chapter, the system design will be explained in terms of pseudo code
for each of the objects.

16
 Chapter5

OBJECT ORIENTED DESIGN OR LOW LEVEL

DESIGN

Introduction
In Chapter 4 classes that will be used to program the solution to the de-
fined problem were described looked at together with their attributes and
operations and the relationship between these classes was shown by
means of a diagram. In this chapter we take an even closer look at those
classes, so much as almost touching one the code. This will be developed
in a form of a pseudo code, which is very close to the actual code.

Inner details of class attributes (data types)

The following table shows the inner details of the objects with their at-
tributes. It is the description of the attribute with regards to the type of
data that they represent. The table consists of objects on the left column
and the attributes for each object are explained on the right column.
 Table 6 attributes explained

Objects attribute
User User_ID

Description: stores a user’s identity number to identify each

user
Type: int
Example: 0922
User_cellnumber

Description: user’s cell number to identify a user, will be used to

send by an administrator to send an SMS and to reply in an USSD
request

Type: int

Example: 0733356017

Administrator Admin_name

Description : administrator name to identify the administrator

Type : string

Example:

Admin_password

Description: will store a unique password for an administrator to

Type varchar

Example: tshaka0922

Update Update date

Description: Will keep records of when the user updated their pro-
file

Type : date

Example : 29 May 2013

Check date
Check
Description: will store dates of checking the balance, also used for
limitation purpose, if a user wants to check a statement of 3 months
ago, an error will be displayed

Type : date

Example: 29 may 2013

18
Inner details of class methods (functions)
The following table (table7) shows the inner details of classes with their
functions. It is the description of classes with regards to the type of func-
tions that they represent.

Table 7 Functions explained

class functions
Public void_register()- this function will be used by the administrator to registor a
Administrator
new user into the system

Public void_check balance ()- if a user wants to check a balance this method will
be used.

Public void_update a profile() will be used to update a profile of a user when

requested to do so

User Public void_register()- this function will called in a program when a new user
wants to register in a system

Public void_check balance () - used to check balance of a user.

Public void_update a profile() if a user requests a profile update this function

will be used

Pseudo-code1
When button1.click {
Do
If (input = “*1351#”)
Show option screen
Else (close screen);
}
If (input= 1)
Retrieve a balance from the system ();
Show a feedback screen ()
Else if (input = 2)
Show update a profile screen ()
 Send info database ();
Display updated profile on the screen();
Else close screen ()

Summary
In this chapter the pseudo code required to understand the solution was
developed. The various attributes and functions of a class were explained
in detail.

20
 Chapter6

IMPLEMENTATION

Introduction
In Chapter 5, the Object Oriented Design of the application was given as
well as a detailed outline of the class functions/methods and the pseudo-
code for each class method of the system. It also analyzed the functions
which show how the user will interact with the application. Chapter 5
was more like an introduction to this chapter, where the implementation
is explained in more detail. In this chapter, a method of implementation
(USSD) is discussed and the source code of the full program is docu-
mented

Software Deployment
In the deployment of this mobile application eclipse, SQL databases and
SQLite databases was used.
It works in two ways:
 Send data application –allows a user to send a request to the server
(indicated by blue arrows in the Figure 10 below)
 Application on the server receives USSD code and verifies if cor-
rect gateway and register, updates the database, or the application
on the server sends feedback to the mobile
phone/emulator.(indicated by long black arrow in the Figure 10
below)

USSD Database/Billing
Verifi- System
cation
 Figure 10 Implementation

This application uses MySQL databases to store data, when a user enters
a USSD code it will be verified if correct and go through if correct. To
link a Database with MySQL I used PHP script which I used notepad++
to write them. JSON (JavaScript Object Notation) was used to store in-
formation in an organized, easy-to-access manner in a database

Progress

Figure 11 changes in an
interface

Both screens in Figure 10 can be used to access the application however

since the application will be used by rural people and I decided to use
button as well as text. The screen on the left above is a normal screen we
see when using any USSD.A user is expected to enter an option as text on a
text box. And the screen on the right is the alternative application; a user
will only press on the option they want to use without having to type any
text. This will make it easier for them to select an option without having to
type anything.

22
The tools and languages I used have been added to the tools described
earlier in this book. The following are the tools used
 MySQL
 Android emulator
 Apache
 Notepad++ for PHP script
 Eclipse for Java Developers
 Android Developer Tools (ADT)
 SQLite

Challenges

Like any other software engineering project/ application development

project I went through some hardships and rough patches. Several tech-
nical problems were encountered throughout the development of this ap-
plication. I experienced a very hard time when it came to identify a cor-
rect phone number. Since I do not have access to any service provider’s
internal information. During the development and implementation of this
application, an emulator was used to test the application and a USSD ap-
plication is not easy to simulate, this presented a huge challenge. It was
not easy to see if USSD code is correct or incorrect but since the database
is saved on the computer it would not be easy to connect a database from
the computer to the application on a mobile phone and an emulator makes
it easy to test an application

Source code
Main screen (USSD request) Class
/*
Author: Zine Tshaka

This is the first screen that will pop up when an application

starts. This code shows an implementation of an application
which is designed to use USSD code. the following class is de-
signed to determine if an entered code is correct or incorrect,
it allows a user to make a query then checks if code is valid.
INPUT: This class is designed to go through only if a correct
input has been entered by the user will be taking an input from
the user
OUTPUT: After getting an input from the user an input will be
sent and second screen will pop up. The output for this class is
2 options which are check balance and update profile
CAVEAT: This program only take *1351# from the user otherwise an
error screen will be shown and an application will be closed and
a user will have to restart an application again
*/

//importing all the java libraries that will be used in a pro-

gram
package com.example.androidhive;
import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;

public class screen1 extends Activity {

// Initializing variables that are used in the program
EditText inputName;
TextView registerErrorMsg;

@Override
//creates an instance by connecting this java code to an XML
file called screen 1
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.screen1);
//takes what will be entered by the user in a text box in XML
and make it inputName which is a variable used in java code
inputName = (EditText) findViewById(R.id.name);
//btnNextScreen is defined in XML screen1 as a button, this
part of java code defines btnNextScreen as a button in java. af-
ter this step btnNextScreen will be added in R.java which is an
automatic genereted class of android
Button btnNextScreen = (Button) findViewBy-
Id(R.id.btnNextScreen);

registerErrorMsg = (TextView) findViewBy-

Id(R.id.register_error);

24
 //Listening to button event
btnNextScreen.setOnClickListener(new View.OnClickListener() {

public void onClick(View arg0) {

//Starting a new Intent
String StrName = inputName.getText().toString();
//checks if an entered code is correct
if(StrName.equals("*1351#")){

Intent nextScreen = new In-

tent(getApplicationContext(),TreatNext.class);

//Sending data to another Activity

nextScreen.putExtra("name", inputName.getText().toString());

// starting new activity

startActivity(nextScreen);
}
else {
registerErrorMsg.setText("");
// Error in login
registerErrorMsg.setText("Incorrect USSD code, enter a
coreect code");

{
// finish ();

}
}
});
}
}

Displaying options

/*Description: This class is called in the main menu when a cor-

rect code has been entered. It is connected to an XML file
called screen3
* Input: the only input that is required from the user is
pressing a required button either check balance or update a pro-
file, otherwise this class does not ask/require any input from
the user
 * OUTPUT: the user output will depend on the user input, there
are 2 output that are produced in this class
* 1. Check balance outputs an authorization page and
* 2. Update a profile outputs a form that a user will have to
fill in order to update his/ her profile
*
* CAVEAT: No caveat
* */

public class SecondScreenActivity extends Activity {

// Initializing variables that are used in the program
EditText inputName;

// Called when the activity is first created.

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//fetches a layout from XML file called screen3
setContentView(R.layout.screen3);
inputName = (EditText) findViewById(R.id.name);
// Importing 2 assets/ buttons
Button btn_checkBalance = (But-
ton)findViewById(R.id.btn_checkBalance);
Button update= (Button)findViewById(R.id.update);
//Listening to update button event
update.setOnClickListener(new View.OnClickListener() {
public void onClick(View arg0) {
Intent next3rdScreen = new In-
tent(getApplicationContext(),CopyOfTreatNext.class);

startActivity(next3rdScreen);

}
});

//Listening to btn_checkBalance button event

btn_checkBalance.setOnClickListener(new
View.OnClickListener() {
public void onClick(View arg0) {
Intent next3rdScreen = new In-
tent(getApplicationContext(),LoginActivity.class);

startActivity(next3rdScreen);

26
 }
});

}
}

Registering class

/*DESCRIPTION: This class is for registering a user on the sys-

tem.
* INPUT:it takes an input from the user, a user must input
name, phone number, and a password that will be used when en-
quiring for a balance
* OUTPUT: the is no output for this class, after taking an in-
put from the user the user details will be sent to the database
* CAVEAT: a user must be a first time user or else a user will
not be registered on the database if the same phone number is
used to register a new user
* */
Importing all libraries

package com.example.androidhive;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.os.Environment;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;
import android.widget.Toast;
public class RegisterActivity extends Activity implements On-
ClickListener{

// Initializing variables and buttons that will be used in the

program
Button btnRegister;
Button btnLinkToLogin;
EditText inputFullName;
EditText inputPhoneNO;
EditText inputPassword;
 TextView registerErrorMsg;
Button btnDate;

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);
setContentView(R.layout.register);

// Importing all assets like buttons, text fields

inputFullName = (EditText) findViewById(R.id.registerName);
inputPhoneNO = (EditText) findViewById(R.id.registerPhoneNO);
inputPassword = (EditText) findViewBy-
Id(R.id.registerPassword);
btnRegister = (Button) findViewById(R.id.btnRegister);
btnDate = (Button) findViewById(R.id.btnDate);

findViewById(R.id.btnRegister).setOnClickListener(this);
findViewById(R.id.btnDate).setOnClickListener(this);

private void ensure() {

File sdcard = Environment.getExternalStorageDirectory();
File file = new File(sdcard,"/zee.txt");
if(!file.exists()) {
try {
file.createNewFile();
} catch (IOException e) {
Toast.makeText(getApplicationContext(),"Error creating
file!",Toast.LENGTH_LONG).show();
}
}
}

@Override
public void onClick(View v) {
switch(v.getId()) {
case R.id.btnDate:
Intent chooseDate = new In-
tent(getApplicationContext(),date.class);
startActivity(chooseDate);
break;

case R.id.btnRegister:
save();

28
 Intent goingback = new In-
tent(getApplicationContext(),SecondScreenActivity.class);

startActivity(goingback);
break;
}
}

private void save() {

ensure();
String firstLine = ((EditText) findViewBy-
Id(R.id.registerName)).getText().toString().trim();
String secondLine = ((EditText) findViewBy-
Id(R.id.registerPhoneNO)).getText().toString().trim();
String thirdLine = ((EditText) findViewBy-
Id(R.id.registerPassword)).getText().toString().trim();

String sdcard = Environ-

ment.getExternalStorageDirectory().getAbsolutePath();
File file = new File(sdcard,"/zee.txt");
try {
BufferedWriter fw = new BufferedWriter(new FileWriter(file,
true));
BufferedWriter bw = new BufferedWriter(fw);
bw.append("Name:"+firstLine+"\n"+"Phone Num-
ber:"+secondLine+"\n"+"Password:"+thirdLine+"\n"+"Balance:R0.00"
+"\n"+"\n");
bw.close();
} catch (IOException e) {
Toast.makeText(getApplicationContext(),"Error writing
file!",Toast.LENGTH_LONG).show();
}

}
}

Login Class
/*DESCRIPTION: This is a login page, it allows a user to login
into the system and checks if they are correct it should return
the balance if the login details are correct
* INPUT: This class takes an input from the user, the input is
the login details
* OUTPUT:The out put that is produced by this class is a user
balance
* CAVEAT: the class will only produce an output if a correct
login details has been entered
*//*DESCRIPTION: This is a login page, it allows a user to log-
in into the system and checks if they are correct it should re-
turn the balance if the login details are correct
* INPUT: This class takes an input from the user, the input is
the login details
* OUTPUT:The out put that is produced by this class is a user
balance
* CAVEAT: the class will only produce an output if a correct
login details has been entered
*/

package com.example.androidhive;

import java.util.HashMap;

import org.json.JSONException;
import org.json.JSONObject;

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;

import com.example.androidhive.library.DatabaseHandler;
import com.example.androidhive.library.UserFunctions;

public class LoginActivity extends Activity {

Button btnLogin;
Button btnLinkToRegister;
EditText inputPhoneNO;
EditText inputPassword;
TextView loginErrorMsg;

30
 // JSON Response node names
private static String KEY_SUCCESS = "success";
private static String KEY_ERROR = "error";
private static String KEY_ERROR_MSG = "error_msg";
private static String KEY_UID = "uid";
private static String KEY_NAME = "name";
private static String KEY_PhoneNO = "PhoneNO";
private static String KEY_CREATED_AT = "created_at";

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.login);

// Importing all assets like buttons, text fields

inputPhoneNO = (EditText) findViewById(R.id.loginPhoneNO);
inputPassword = (EditText) findViewById(R.id.loginPassword);
btnLogin = (Button) findViewById(R.id.btnLogin);
// btnLinkToRegister = (Button) findViewBy-
Id(R.id.btnLinkToRegisterScreen);
loginErrorMsg = (TextView) findViewById(R.id.login_error);

// Login button Click Event

btnLogin.setOnClickListener(new View.OnClickListener() {

public void onClick(View view) {

String PhoneNO = inputPhoneNO.getText().toString();
String password = inputPassword.getText().toString();
UserFunctions userFunction = new UserFunctions();
Log.d("Button", "Login");
JSONObject json = userFunction.loginUser(PhoneNO, password);

Intent dashboard = new In-

tent(getApplicationContext(),Copy_2_of_TreatNext.class);

// Close all views before launching Dashboard

dashboard.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(dashboard);

// check for login response

}
});
 }
}

Reading Text File

/*DESCRIPTION: This class reads a text file and displays a bal-
ance on the after verifying the login details ,
* INPUT: no input
* OUTPUT:The out put that is produced by this class is a user
balance
* CAVEAT: the class will only produce an output if a correct
login details has been entered
*/

package com.example.androidhive;
import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileReader;
import java.io.IOException;
import java.io.InputStreamReader;
import android.app.Activity;
import android.os.Bundle;
import android.os.Environment;
import android.view.View;
import android.widget.LinearLayout;
import android.widget.TextView;

public class ReadFileSDCardActivity extends Activity {

/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView tv =
(TextView)findViewById(R.id.fileContent);
File dir = Environ-
ment.getExternalStorageDirectory();
StringBuilder text = new StringBuilder();
try {
File file = new File(dir,"zinetrying.txt");
FileInputStream fInWei = new FileInputStream(file);
BufferedReader myReaderWei = new BufferedReader(
new InputStreamReader(fInWei));
String aDataRowWei = "";

32
 String aBufferWei = "";
while ((aDataRowWei = myReaderWei.readLine()) != null) {
aBufferWei += aDataRowWei;
}

LinearLayout hiddenLayout = (LinearLay-

out)findViewById(R.id.hiddenLayout);
if(hiddenLayout == null){
//Inflate the Hidden Layout Information View
LinearLayout myLayout = (LinearLay-
out)findViewById(R.id.linearLayout1);
View hiddenInfo = getLayoutInflat-
er().inflate(R.layout.hidden, myLayout, false);
myLayout.addView(hiddenInfo);
}

TextView weight = (TextView) findViewBy-

Id(R.id.textView11);
weight.setText(aBufferWei);

}
catch (IOException e) {

tv.setText(text);
}

SUMMARY
In this chapter an approach for implementing a mobile application was
discussed and its source code documented. This chapter has also dis-
cussed how the project was implemented on an emulator. The challenges
that I met during the implementation are discussed into detail. The next
chapter describes how the system will be tested to check whether the
functionality is correct.
 Chapter 7

TESTING

Introduction
Through all the previous 6 chapters, the system has been planned, ana-
lyzed, designed, developed and implemented. Chapter 6 briefly explained
the code implementation and code documentation was presented. In this
chapter, the user interface testing as well as evaluation of the system
functionalities will be carried out to ensure the strength and effectiveness
of the system. The main goal of testing is to explore the user interface as
to identify features that could be improved; test out system’s perceived
usefulness and perceived ease of use.

What is testing?
Software testing is a process of executing a program or application with
the intent of finding the software bugs.
It can also be stated as the process of validating and verifying that a soft-
ware program or application or product that has been designed:
 Meets the business and technical requirements that guided it’s de-
sign and development
 Works as expected

Planning the test

To test application 8 users that were used to collect the requirements of
the system were then asked to test and evaluate the system. User’s guide
was distributed to 8 users. These participants were asked to participate on
testing of a completed application. Participants were asked to sign a con-
sent form (see appendix B) to confirm that they understand the purpose of
the study and they acknowledge that they will be participating in the
study. The application was then installed on a mobile phone using user’s
guide. Two types of system testing were used to test the application.
1. Answering questions when done – this is also known as function-
ality testing
2. Performing given task – this is also known as usability testing

34
Functionality testing
Functionality testing is an evaluation of program based on functional re-
quirements to ensure the program works as it was specified to do.
In Functionality testing the testing of the functions of component or sys-
tem is done. It refers to activities that verify a specific action or function
of the code. Functional test tends to answer the questions like “can the
user do this” or “does this particular feature of the system work”.

Usability testing
Usability testing is a type of testing that is done from the user’s point of
view. This testing type makes an attempt to describe the “look and feel”
and usage features or usage aspects of a designed system. Definition of
Good usability is person dependent and varies from user to user. For ex-
ample, a developer or system administrator feels that use of command
line is a good user interface. But an end user would definitely like to have
everything in terms of Graphical User Interface (GUI) such as dialog
boxes, menus etc.

Functionality testing procedure

To conduct Functionality testing for a designed system, users were first
asked to sign a consent form. Functionality testing was conducted with
people from Delft; these people were chosen for testing because they are
the ones that were used for the collection of system requirements. The
testing was done individually. An application was then installed in four
mobile phones. Users were divided into 4 categories with 2 users per cat-
egory. Each category was asked to share a phone because we did not have
enough mobile phones. Each person was asked to register their details
with the system and interact with the system once done with registration
process. The user requirements and requirements analysis document were
reexamined again. Users were then asked to perform different tasks of
application. It was then assessed if the application does what was ex-
pected from it. They were then given the user requirements document and
state whether or not the requirements specified on the document were
met. After that each user was requested to hand over a mobile phone to
their pairs and they also performed the same instructions until all 8 users
have done the testing.
The users were then asked to give a feedback; results of the testing and
users feedback were then recorded to the graph below.
 10

5 user1
user2
4

2
Score

0
Category 1 Category 2 Category 3 Category 4

Figure 12 functionality testing

results

The graph above indicates that none of the users gave a negative feed-
back for the application. Users were asked to rate the functionality of the
system out of 10. Most users gave a score more than eight.

Usability testing procedure

Usability testing tests the usability, or ease of use, of a specific object or
set of objects. To perform usability testing, the same participants were
asked to evaluate the usability of the system by giving a score between 1
and 10, where 1 indicated ineffective and 10 being very effective. While
measuring functionality and usability, the system was tested by the same
eight users previously interview during requirements specification of this
system.
Each participant was given the user guide to read through before they
were asked to interact with different options of an application. Partici-
pants were then given mobile phones, they were asked to start an applica-

36
tion and register their details on the system. They were then asked to play
around with different functions of an application such as check balance
and log in. The users were then asked to answer the questionnaire (see
Appendix). the main aim of the questionnaire was to test the perceived
usefulness of designing an application and to find out if are the any fea-
ture work that can be added on the application.
The testing helped to discover errors and areas of the system that required
improvement. Five participants were able to register onto the system and
view their details without any problems. They were also able to request
their balance.
The graph below shows how each participant responded and rated each
question from the questionnaire that is given on Appendix
 12

10

user1
8 user2
user3
user4
6
user5
user6
Score

4 user7
user8

0
Question1 Question2 Question3 Question4 Question5 Question6 Question7 Question8 Question9

Figure 13 participants rating application

Testing discussion

The participants were able to perform almost all of the tasks that were
given to them during the testing. They also gave a positive feedback
about the application but only few participants could not understand some
of the instructions. Instructions were then explained and clarified to these
participants. During the requirements collection users also indicated that
an SMS based system would be helpful as well, few participants pointed
out that a system did not meet all the requirements

Summary
During system testing, users made significant comments and recommen-
dations about possible ways of improving this system. Some corrections
were made to rectify errors. Some functionality was not successfully im-
plemented on the system due to time constraints and therefore will be
recommended for future work. For instance, sending an SMS to the users
with user’s monthly statement.

38
 C h a p t e r 8

USER GUIDE

Introduction
This chapter gives guidance to the user on how to use the application. It
explains step by step every function of the application and also gives
clear instructions to the user on how to use application correctly. A user
guide helps both a user and an administrator that is not familiar with an
application. A user guide also gives clear instructions on how to install an
application on a mobile phone.

System’s requirements
The requirements of this system are simple. This application only re-
quires an android mobile phone

Installing application
In order for the user to have the application on their android mobile
phone, the user must download the application from
http://www.cs.uwc.ac.za/~ztshaka/#downloads. The file which the user
must download is ApplicationForDownload . Once the user has the file
on their mobile phone, he or she can navigate to wherever they have
saved it and tap on it to run it. When the user has tapped the file, the in-
stall interface will pop-up. When the install screen shows up, the user will
be shown a number of permissions that the application needs in order to
perform all its tasks. At this point, the user should select install and wait
for a few seconds depending upon the performance of the device being
used. After the user selects the install button, the application will install
and save itself and the application icon will be found on the phones menu
screen. A user can now be able to use this application.

40
How the system works?

Figure 13 android main screen

Figure 12 above shows android phone home screen; it is shown to the

user when a user switches on a phone or when a user navigates to the
home button. This screen shows a list of all the applications that can be
found on the phone.
The figure above also illustrates an application that was created (top right
coner) for the completion of this project, to open this application a user
needs to touch once on the icon and wait for the response.
 Figure 14 application main
screen

After touching the icon a new screen will pop up, Figure 13 above shows
the first screen that a user will see when opening an application. This
screen requires a user to enter a USSD code, after that a code will be veri-
fied and if correct an application will proceed to the next screen or a pop
up message will be displayed.
The next figure shows how a popup message is displayed on the user
screen this will only be displayed when an incorrect USSD code has been
entered

42
Figure 15 error message
 Figure 16 options

The figure above is a display of options that will be given to a user after
entering a correct USSD code. As shown on the figure, a user will have 2
options
1. Check Balance
2. Register
This application works different from the other USSD applications, a user
will not have to input their response as most USSD applications does they
have to click on the button they want. so a user cannot skip any step, for
example with MTN if you want to access an application and a predeter-
mined USSD code is *145# and an option you would like to access is op-
tion 1 you can do so by just dialing *145*1# and it will take you straight
to option 1, in this case we cannot do that because this application is not
working with user’s input.

44
 Figure 17 registration form

The figure above is an illustration of option 2 (Register). If a user is a

first time user of the system he/she must first register his/ her details on
the system. The figure above shows a registration form that must be filled
in by the first time users of the system. This application is designed in
such a way that if a user chooses to register as new it checks on the sys-
tem if a user’s phone number does not exist on the system already, if it is
a registered phone number a user cannot be registered with that phone
number. The reason for this is, a mesh potato device will be registered
with a mobile phone number on the system so if a phone number is al-
ready on the system that means there is already an existing user for that
device.
If a user chooses first option (Check Balance), the screen below will be
display on the phone

Figure 18 Log in

After choosing Check Balance option a user will then be taken through
some steps to verify that a user is really a correct user for that device.
This will avoid other users accessing others information when a user los-
es a device due to theft or robbery.

46
 Figure 19 showing user's balance

The figure above is an example of what can be displayed after a user have
been logged in correctly using his/her phone number and a password.

Summary
This chapter has discussed the user guide documentation. The user guide
included instructions to install a system and system requirements. Users
are provided with the information relevant to their respective tasks.
 APPENDICES

APPENDIX A

Interview probes
A mobile application to interact with a mesh billing system

Project description
A mesh potato network is implemented in some rural area in Eastern
Cape. This network is used to make calls within the community. Even
thou a mesh potato network is for free but a maintenance fee must be paid
for the maintenance of devices. This project aims to help people from ru-
ral areas where the mesh potato network is implemented. It focuses on
helping them get their status of mesh potato network without any difficul-
ties.
1). Do you think such a system will be helpful to the people of Mankosi?
How?
2). what would you like a system to do?
3). what is it that you do not want from the new implementation?
4). Can you please describe the way you would like the system work like

48
 APPENDIX B

Consent form
University of the Western Cape
Faculty of Science
Department of Computer Science

Title of the research project:

A mobile application to interact with a mesh billing system

Computer Science
Department:

Telephone:

Email:

Name of participant:

research project

and had the opportunity to ask questions about them.

research on condition my privacy is respected, subject to the

following.
- I understand that my personal details may be included in the
research/ will be used in aggregation form only, so that will
not be personally identifiable.

this project.
 ave the right to withdraw from this project at
any stage.
Signature of Participant:
………………………………….
Name of participant:
…………………………………………………
…

50
 APPENDIX C

Table 8 Project Plan for Term 1

Topic Project plan 2013
February March April Term2 Term3 Term4
 Choosing a project
 Identify users to interview
 Start writing up a URD
 Understand how to use the
Styles and how to compile an
Index, the Table of Contents,
and List of Figures etc.
 Finish URD
 Start writing up RAD
 Finish RAD
 break
 Mock presentation
 Actual presentation

Designing and preparing the

prototype

Implementation and coding

Application and testing

 APPENDIX D

Table 9 Term 2 project plan

52
APPENDIX E
 APPENDIX F

Table 10 Term4 Planning

th rd th h th st th th
Tasks 16 23 Se 30 7 14 21 28 6
for the Sept p Sep Oc- Oct Oct Oct Nov
week to-
Presen
of the ber
tation
on the
th
6

54
Project Finalise Com- Finalise Cre- Hand in
Docu- the edit- plete all user’s ate a docu-
Do the editing f the
ment ing of editing guide & small menta-
rd previous term’s
the of 3 Project video tion on
documentation.
docu- term’s docu- or Monday
th
menta- docu- menta- demo 4 No-
tion menta- tion. of vember
Start by identifying
tion. Ask your
all the tasks that the
col- pro-
program must be
league ject
able to do - write the
or on
User’s guide
some- your
one to web-
edit site.
/proofre
And
ad it!!
put an
exec-
utive
See
sum-
Page 12
mary
of the
of
hand-
your
out.
pro-
ject
on the
web-
site
as
well.

Pro- Revise programme & add what is still out- Revise Re- Revise
gram- standing pro- vise pro-
ming gramme pro- gramme
And make changes to thesis doc to reflect
tasks & create gram
this! Finalise
not installa- me &
Installa-
com- tion create
tion
pleted disc. instal-
disc.
lation
disc.
Design Read up Add the Design test
Test about theoret- suites
suites evalua- ical part
Choose your
tion of of eval-
“users”
pro- uation
grams – to your Question-
get ide- docu- naires etc.
as of menta-
Ethical as-
how you tion.
pects
want to Edit the
do eval- chap-
uation. ters
Add to where
docu- you
menta- referred
tion. to it
Edit the initially.
chap-
ters
where
you
referred
to it
initially.

Exe- Execute tests & keep

cute record of it by writing it up
tests, in Thesis doc. Create
revise graphs that can be in-
code or cluded in Projectdoc.
even
project
design

56
Presen Mock
tation Presen-
tation
on the
th
5 Nov.
Prepare
for
presen-
tation
and
install
on rele-
vant
com-
puters.
Test if it
works!!

Web- Update Update Ex- Ex- Ex- Final

site NB NB ecu- ecu- ecu- Update
tive tive tive NB with
sum sum sum a video
mary mary mary or link
of of of to a
the the the demo.
Pro- Pro- Pro-
ject. ject. ject.
 APPENDIX F

Questionnaire
Rate a system by giving a score between 1 and 10. 1 means ineffective
and 10 means effective

Question Score

1. Easy to install an application

2. Instructions clear on the user guide

3. Able to register on the system without any problems

4. Able to login with no problems

5. Is the interface of the system ok?

6. Is the system user friendly?

7. Is it safe to use the system?

8. Would you use this application on your daily basis?

9. Were requirements of the system met?

10. What would you like to be improved on the system?

58
11. What is it that you do not like about the system?
Bibliography
1. about.com. [Online] 2000.
http://cellphones.about.com/od/phoneglossary/g/smstextmessage.htm.
2.
http://www.logossolvo.com/news.php?start_from=48&ucat=&archive=&su
baction=&id=&. [Online] february 1996. [Cited: 03 10, 2013.]
3. https://groups.google.com/forum/?fromgroups=#!topic/village-telco-
dev/95vOPMpXg2I. [Online] april 1999. [Cited: 03 10, 2013.]
4. stephen, michael adeyeye and paul gardner. The Village Telco project:
a reliable and practical wireless mesh telephony infrastructure. 2008.
5. Tamanda, Ravi. androidhive. [Online] July 01, 2013. [Cited: September 10,
2013.] http://www.androidhive.info/.
6. Traynor, Patrick. On Cellular Botnets: Measuring the Impact of
Malicious. Mobile Phone Architecture. 2012.
7. Ufitamahoro, Josée Marie. [Online] [Cited: May 18, 2013.]
http://www.cs.uwc.ac.za/~mufitamahoro/project.html.
8. Yiyao Lu 1, Weiyi Meng 1, Liangcai Shu 1, Clement Yu 2, King-Lup
Liu. Evaluation of Result Merging Strategies. 2003.
9. about.com. about.com. cell phone glossary. [Online]
http://cellphones.about.com/od/phoneglossary/g/smstextmessage.htm..
10. —. About.com.cell phones. About.com. [Online]
http://cellphones.about.com/od/phoneglossary/g/smstextmessage.htm.
11. Marie , Josée Ufitamahoro. A Mesh Network Implementation In
Mankosi, South Africa. Marie Josée. [Online] july 2006. [Cited: 03 26, 2013.]
http://www.cs.uwc.ac.za/~mufitamahoro/project.html.
12. Bila, Ntsako Welcome. MOBILE MONEY TRANFER FOR
UNBANKED. COMPUTER SCIENCE, University Of The Western Cape.
Cape Town : s.n., 2011.
13. Mobile Internet Gateway. Welcome Mobile Internet Gateway. [Online] 06 2012.
[Cited: April 03, 2013.] http://www.mig.co.za/images/ussdSAMPLE.jpg.
14. crew, Village Telco. Mesh potato. villa telco. [Online] September 2011.
[Cited: March 26, 2013.] http://villagetelco.org/mesh-potato/.
15. sms gateway. send mode. [Online] 2002. [Cited: April 05, 2013.]
http://www.sendmode.co.za/sms-gateway.
16. Airtime Transfer. Vodacom. [Online] Vodacom, 2012.
https://www.vodacom.co.za/personal/services/stayintouch/airtimetransferse
rvice/?pageUrl=/personal/services/stayintouch/airtimetransferservice&first
Load=true.

60
 INDEX

Mysql, vi
MySQLite, vi
A
application, 1, i, ii, iii, vi, 1, 3, 5, 7, 8, 11, 15, N
23, 24, 25, 26, 35, 37, 38, 39, 40, 41, 43,
44, 45, 47, 48, 51, 52, 61 NetBeans Java, 5

B O
balance, iii, iv, 9, 10, 11, 14, 15, 16, 17, 20, object oriented analysis, 13
21, 26, 28, 29, 32, 34, 40, 50 onCreate, 28

C P
Check balance, 12 Progress, 24
pseudo code, 18, 19, 22

D
R
Delft, i, 1, 5, 38
Designers, 3 Register, 14, 15
requirements, 1, i, i, ii, vi, 1, 2, 3, 5, 7, 14,
37, 38, 40, 41, 43, 50, 61
F Requirements, 3
rural area, 1
Functionality testing, ii, 38

S
G
screen, 12, 21, 22, 24
GSMG, vi server, vi, 5, 23
SMS, vi
I
T
interface, i, i, iii, vi, 7, 11, 12, 14, 24, 37, 38,
43, 61 The user interface specification, 7

L U
Log in, iii, 49 Update, 14, 16, 20, 28
Update information, 12
M Usability testing, ii, 38, 39
User, 1, 7, 12, 14, 15, 16, 20, 21
Mankosi, 1, 2, 51 USSD, vii, 2, 3, 5, 7, 20, 23, 24, 25
mesh potato, 1, 2 USSD code, 4, 7, 8, 11, 25, 27, 45, 47
mobile phone, 3, 5
MyQsl, 5