ilmenau university of technology faculty of electrical...

Ilmenau University of Technology

Faculty of Electrical Engineering and Information Technology

Master Thesis

Assistance System Service Development using aMessage-Oriented Middleware

Submitted by: Muhammad Kamran Afridi

Submitted on: 15. 07. 2012

Born on:

Course of Study: Master of Science in Communications and Signal Processing

Department of thesis: Communication Networks

Responsible Professor: Prof. Dr. rer. nat. Jochen Seitz

Supervisor: Dipl.-Ing. Karsten Renhak

Acknowledgement

I would like thank Mr. Karsten Renhak for his continuous support all this time and

for answering all the queries that I had.

I am very grateful to my family, for without their love and support nothing would

have been possible.

At last, I would like to thank my friend Usman Ali Shah for providing me with his

Android phone during the thesis despite his personal needs.

Kurzfassung

In dieser Arbeit wird beschrieben, wie Android-Anwendungen fur ein Assistenzsys-

tem, das eine Message-Oriented Middleware (MOM) verwendet, entwickelt werden

konnen. MOM wird dabei aufgrund seiner Asynchronitat und der Moglichkeit der

Wahl des Kommunikationswegs sowie der Transformation als Programmiergrundlage

verwendet. Fur die Kommunikation wurde das Advanced Message Queuing Protocol

(AMQP) ausgewahlt, weil dieses eine vollstandige Interoperabilitat bietet. MAMMAS

AMQP erweist sich hierbei als erfolgreicher Kandidat fur die Realisierung des Assis-

tenzsystems als Anwendung fur das Betriebssystem Android.

Es werden verschiedene Software-Entwicklungsprozesse und -modelle (wie das Wasser-

fallmodell, das Spiralmodell, agile Software-Entwicklung, das “Code & Fix”-Modell

sowie das inkrementelle und das iterative Modell) diskutiert. Die Android-Anwendung

in dieser Masterarbeit wurde wegen ihrer Flexibilitat und Eignung fur kleine Projekte

nach dem agilen, dem inkrementellen und dem iterativen Modell entwickelt.

Um die Fahigkeit von Android zur Ad-hoc-Kommunikation zu testen, wurde ein

Bildtransfer uber Bluetooth realisiert.

Daruber hinaus wurden Android-Anwendungskomponenten fur folgende Anwendungs-

falle entwickelt: Chat, Benutzer-Lokalisierung, Benutzermonitoring, Notruf und Blue-

tooth”=Datenubertragung.

Die Arbeit kann in zwei logische Teile gegliedert werden. Der erste Teil behandelt das

fur die in der Arbeit behandelten Themen notwendige Hintergrundwissen. Im zweiten

Teil wird gezeigt, wie die Konzepte, die im ersten Teil diskutiert wurden, in Android

implementiert werden konnen, sodass am Ende daraus Schlussfolgerungen abgeleitet

werden konnen.

Alle Anwendungskomponenten wurden in eine einzigen Anwendung mit einer konsis-

tenten Benutzeroberflache integriert, die uber einen “Preferences”-Menupunkt verfugt

und durch ein Passwort geschutzt ist.

Abstract

In this thesis Android applications are developed for an assistance system which uses

Message-Oriented Middleware (MOM). MOM is used as a source of communication

for the assistance system because of it’s asynchronicity, routing and transformation.

MOM’s Advanced Message Queuing Protocol (AMQP) is used because it provides

complete interoperability. MOM’s AMQP proves to be a successful candidate for an

assistance system application in Android.

Different software development processes and models are also discussed such as Wa-

terfall model, Spiral model, Agile model , Code and Fix model, and Incremental and

Iterative model. The Android application in the support of this thesis is developed

according to Agile and, Incremental and Iterative model because of their flexibility and

suitability for small projects.

To test Android’s capability for Ad-hoc communication, a picture is sent over blue-

tooth.

Android applications for the following are developed: Chat Application, User Lo-

calization, Fence Area Management, Multiple Calls in Emergency and bluetooth data

transfer.

The thesis can be divided into two logical parts. The first the part provides the

necessary background knowledge about the topics on which this thesis is conducted. In

the second part it is shown how the concepts discussed in first part can be implemented

in Android and in the end conclusions are derived.

All sub-applications are integrated into one single application with a User Interface

which can controlled by ”Preferences” and it is also protected by a password.

Contents i

Contents

I Theoretical Knowledge 1

1 Introduction 2

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Goal of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Thesis Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Software Development Process 7

2.1 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 Implementation and Testing . . . . . . . . . . . . . . . . . . . . 8

2.1.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.6 Training and Support . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.7 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Software Development Models . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Waterfall model . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 Iterative and Incremental Model . . . . . . . . . . . . . . . . . . 10

2.2.4 Agile Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.5 Code and Fix Model . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Software Development Model and Process for Master Thesis . . . . . . 11

2.3.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2 Software Development Process . . . . . . . . . . . . . . . . . . . 12

2.3.2.1 Requirements: . . . . . . . . . . . . . . . . . . . . . . 14

Master Thesis, Muhammad Kamran Afridi

Contents ii

2.3.2.2 Planning: . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2.3 Implementation and Testing: . . . . . . . . . . . . . . 15

2.3.2.4 Documentation: . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2.5 Deployment: . . . . . . . . . . . . . . . . . . . . . . . 15

3 Message-Oriented Middleware 16

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 MOM Advantages and Concepts . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.3 Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 MOM proctocols and Implementations . . . . . . . . . . . . . . . . . . 17

4 Advanced Message Queuing Protocol 19

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Main Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.2 Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.2.1 Direct Exchange: . . . . . . . . . . . . . . . . . . . . . 20

4.2.2.2 Fanout Exchange: . . . . . . . . . . . . . . . . . . . . 21

4.2.2.3 Topic Exchange: . . . . . . . . . . . . . . . . . . . . . 21

4.2.2.4 Header Exchange: . . . . . . . . . . . . . . . . . . . . 21

4.2.3 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Ad-hoc in Android 22

5.1 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2.1 Initial Setup: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.2 Establishing a Connection: . . . . . . . . . . . . . . . . . . . . . 23

5.2.3 Data Transfer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

II Implementation 24

6 Prerequisites 25

6.1 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 JDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


Contents iii

6.3 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.4 ADT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.5 Erlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.6 RabbitMQ Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.7 Google API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Initial Interface 28

7.1 Password Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.2 Buttons Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8 Chat Application 32

8.1 Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.2 RabbitMQ Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.2.1 Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.2.2 Consuming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.3 RabbitMQ on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9 User localization and fence area 36

9.1 Latitude and Longitude . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9.2 User Location and Fence Area . . . . . . . . . . . . . . . . . . . . . . . 37

9.3 Fence Area Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.4 Fence Area Management . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9.4.1 Sending a Message to a server via MOM . . . . . . . . . . . . . 39

9.4.2 Toast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.4.3 Vibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

10 Emergency Calls 41

11 Preferences 43

11.1 Preferences for Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

11.2 Preferences for Fence Area Management . . . . . . . . . . . . . . . . . 45

12 Android Ad-hoc: Bluetooth 46

12.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

12.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

13 The Big Picture 50

14 Conclusion 52


Contents iv

15 Future Directions 53

A Android Application Development - Graphical User Interface 55

A.1 Master ThesisActivity.java . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.2 main.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A.3 string.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A.4 AndroidManifest.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliography 63

List of Figures 65

List of Abbreviations 66

Conclusion of the Master Thesis 67

Erklarung 68


1

Part I

Theoretical Knowledge


1 Introduction 2

1 Introduction

The Message-Oriented Middleware (MOM) is an end-to-end messaging system which

can be used over distributed systems. The MOM application modules can be installed

in end-systems across different networks over different platforms and still messaging

would take place.

An assistance system helps to improve the quality of life of physically and mentally

impaired people. As for example, assistance system can be used for senior citizens,

when the seniors are in emergency situations like sudden falls, heart attacks, strokes

... etc, and they need to be monitored continuously.

Android is an operating system for mobile phones and tablets, it is an operating

system based on Linux. Android consists of a software stack which includes operat-

ing system, middleware and sample applications.[And09b] Android is famous among

developers because it is open source and offers advanced functionalities. Today, there

are more than 200 million activated Android devices, and every day more than 550,000

new devices are activated in more than 137 countries and regions. [And09a] As of a

survey in 2010 by canalys the market share of Android was 33% among other Operating

systems for mobile phones as shown in Figure 1.1 and it’s use is increasing.

1.1 Motivation

A MOM encapsulates the application developer from the details of underlying architec-

ture. MOM provides scalability to the applications which span over different systems

and protocols. Message-Oriented Middleware offers message transformation across dif-

ferent platforms via brokers, and message routing. It also provides the capability of

asynchronous message store and forward.

MOM assures reliable message transfer between different applications running on

heterogeneous networks. It is also responsible for the ordering of messages, the mes-

sages are received or displayed in the order they were sent. MOM also provides the

functionality of message encryption and message privacy.

An assistance system can take advantage from MOM due to it’s scalability and ability


1 Introduction 3

Figure 1.1: Market Share of Android.[tec11]

to work over heterogeneous systems. The staff in a hospital will be able to interact

with the senior and will know about the senior’s position, where all the communication

between them takes place over MOM.

As Android has an open development platform, thus providing a chance for devel-

opers to build innovative applications while integrating other technologies. It has a

number of features that can be utilized for an assistance system along with MOM, like

GPS, GSM Telephony, WiFi for internet usage, ... etc.

Ad-hoc is a concept which can be applied in different scenarios and does not require a

pre-existing architecture. As Android phones are powerful computational devices with

wireless interfaces, one can investigate the possibilities of Android acting in ad-hoc

mode.


1 Introduction 4

1.2 Problem Statement

The need for MOM was felt in 1960s when the mainframes in banks would connect to

the Personal Computers (PC) running different applications. The developers at that

time had to install network gateways if the source (PCs or mainframes) and destination

(mainframes or PCs) were operating on different network protocols. In case of slow

processing of PCs, the mainframes had to wait for the output of PCs for processing of

the data and vice versa. Software engineers would develop software which would act

as intermediate-software to translate the data from source applications to destination

applications and vice versa.

The specific problem statement for this thesis would be: to find out the ways to

develop and integrate MOM into Android, as both are quite new research fields in

terms of integration. To choose the best Software Development Life Cycle (SDLC) for

making an assistance system Android application which integrates a MOM. To find out

the limitations of android ad-hoc network as Android does not support native ad-hoc

connections.

1.3 Goal of the thesis

The thesis will show the demonstration of the complete development process for ser-

vices or applications of an assistance system from design to implementation. The

application supporting MOM has to be tested on a mobile phone running Android

Operating System.

A chat application using MOM will be developed, which can be simulated for doctor

patient conversation. The senior citizen has to be monitored by knowing the location

of the user (senior), where the location information is sent over MOM. An application

should be developed which makes multiple calls in case of emergency for the assistance

system. In general one can show usefulness of MOM for an assistance system.

1.4 Thesis Task List

To give the reader a clear picture of the thesis, a task list is summarized. These tasks

will be referenced several times in the thesis.

(a) Description of Software Development Processes and Models, and sorting out of the

Software Development Models suitable to the application developed in the thesis.


1 Introduction 5

(b) Explanation of Message-Oriented Middleware.

(c) Explanation of MOM’s protocol (AMQP).

(d) Investigation of the possibility of Ad-hoc communication in Android.

(e) Development of Chat Application using MOM.

(f) To develop an Android application for user localization, which informs the as-

sistance system about user’s location periodically. The assistance system should

receive the information through a MOM protocol (AMQP).

(g) Management of the fence areas on Android Device for the user.

(h) Implementation of multiple calls in case of emergency.

(i) Implementation of Ad-hoc mode for Android.

1.5 Structure

The thesis is dived into two parts logically, part I provides the theoretical background

of topics covered in thesis such as Software Development Process, MOM, AMQP and

Ad-hoc communication in Android. Part II is about the transforming the theoretical

knowledge into practical coding. In part II not all of code is discussed only commentary

is made on the main code which is fundamental to the application.

Further Part I and II are divided into chapters as follows:

Part I:

Chapter 1. Introduction

Chapter 2. Software Development Process

Chapter 3. Message-Oriented Middleware

Chapter 4. Advanced Message Queuing Protocol

Chapter 5. Ad-hoc in Android

Part II:

Chapter 6. Prerequisites

Chapter 7. Initial Interface

Chapter 8. Chat Application

Chapter 9. User Localization and fence area

Chapter 10. Emergency Calls

Chapter 11. Preferences


1 Introduction 6

Chapter 12. Android Ad-hoc: Bluetooth

Chapter 13. The Big Picture

Chapter 14. Conclusion

Chapter 15. Future Directions



2 Software Development Process

Software Development Process is also known as Software Development Life Cycle

(SDLC). It is the structure which is followed when developing new softwares or ap-

plications. Most development processes include the following activities in different

stages:

• Requirement gathering

• Design

• Implementation

• Testing

• Maintenance

There are some international standards available, one being ISO/IEC 12207 which

defines tasks for development and maintenance. There are also different software de-

velopment models which a development company may adopt according to their needs

and resources.

In this chapter the basic concepts of software development process are discussed.

Then a model is being selected which is deemed suitable to the application that has

been developed in the master thesis.

”Task a” from Chapter 1 Section 1.4 (Thesis Task List) is accomplished in this

chapter.

2.1 Activities

2.1.1 Requirements

Knowing about the requirements of the software from the customer is the first step that

software development firm goes through. In the start the requirements can be ambigu-

ous but experienced software engineers can sort out the confusions and ambiguities of

the software’s end results.



2.1.2 Planning

Once the requirements are clear, the software firm estimates the resources that will

be spent. The budget for the software development is presented to the client. An

architecture is also made which shows the path the software firm is going to adhere to.

2.1.3 Implementation and Testing

In implementation the coding takes place for the project. Testing can take place when

implementation is complete. In testing, the code is checked for bugs and the aim is to

recognize the faults as early as possible.

2.1.4 Documentation

The internal design and architecture is recorded. It can be used by the developers for

the further enhancement of the software and maintenance.

2.1.5 Deployment

Deployment of the software can begin when the software has been tested. It can involve

installation of the software to the clients systems or customization of the software

according to the needs of the customers.

2.1.6 Training and Support

Some may not consider it as an important activity but some projects might fail because

at customers end users don’t know how to use the software. Sometimes workers at the

client location are also hesitant to change as they don’t want to go to the unexplored

territories. So it is important that training should be given to the users to make the

software user friendly for them.

2.1.7 Maintenance

When the actual use of the software is started, unknown new bugs can appear in the

software. Maintenance not only includes fixing the bugs but also includes enhancing

the software for users, because sometimes the requirement phase misses some required

functionalities.



2.2 Software Development Models

These models defines phases the software development has to go through and prescribes

the order in which the development has to be done. There are different pros and cons

for each model but it is up to the development team which model it has to choose.

Sometimes a combination of different models for development can also take place.

2.2.1 Waterfall model

Figure 2.1: Waterfall Model [MJ97]

It is one of most common models for software development. In waterfall model the

development can not progress until a phase has been completed. After completion of

each phase a review takes place to determine whether the project is in right path or

not. The following steps in waterfall model are followed in order:

a. Requirements Specification

b. Design

c. Coding (or Implementation)

d. Testing

e. Deployment (or Installation)



f. Maintenance

Waterfall model is simple and easily understandable but has some disadvantages,

due to strict phase completion policy no code might be produced until later stages. It

is not suitable if the requirements have a probability to be changed.

In Figure 2.1 a waterfall model is illustrated.

2.2.2 Spiral Model

This model is normally applied to large-scale projects. The key component is risk-

analysis throughout the development process at regular stages. The phases are cate-

gorized into four different parts:

a. Determining Objectives / Planning

b. Identifying Risks / Risk Analysis

c. Planning next iteration

d. Development and testing

After each iteration the spiral grows which denotes the size increment of the software

product.

Figure 2.2: Spiral Model

2.2.3 Iterative and Incremental Model

This model is developed in response to the weaknesses of waterfall model.



The work is divided into a series of iterations which are composed of analysis, design,

implementation and testing. After each iteration new features are included and added

to the software hence making it ”incremental” in nature.

The advantage of this model is that it can be chosen for smaller projects as well as

larger projects.

2.2.4 Agile Model

It can be considered similar to iterative and incremental development model but instead

of planning, feedback is used. The feedback is derived from the tests and releases of

the software.

There are different variations of agile development but Extreme Programming (XP)

is one of most famous. XP is newer in terms of phases as compared to older agile

approaches, as the phases uses smaller steps and the programmers are in constant

interaction with the customers. Normally two programmers make a team in XP for the

implementation phase. In XP ”Coders” are also responsible for designing the software.

2.2.5 Code and Fix Model

It is used in the softwares which does not require maintenance and it is considered as

an old model. Though it is deemed suitable for smaller projects. This model doesn’t

include strategies and architectures. The programmers immediately start coding and

the bugs have to be cleared before the application is released.

2.3 Software Development Model and Process for

Master Thesis

2.3.1 Model

Before analyzing the model for master thesis it would be better to rephrase the tasks

and then decide which model or combination of models would be better for the software

project of master thesis (though most of the application has been developed at this

point according to agile, and iterative and incremental model, though it would be

better to have an interactive and case-study approach for better explanation).

Application Design

Design an application for a mobile android device which provide the features from the

list below.



• Robust person localization via cell network, WLAN or GPS to inform an external

service (the assistance system) about the location of a user periodically.

• All communication between the users device and the service provider should go

via the AMQP MOM.

• Fence area calculation. Alert messages if the device leave the area.

• Management of the fence areas on the local device and/or an external service.

• Emergency button with a manageable list of actions to perform. E.g. according

to the location or other context information.

• Chat mode to interact (text chat) with some friends.

• Ad-hoc mode to interact with near by devices e.g. if no cell network is available.

Implementation and demonstration

• Based on the previous tasks and in consultation with the thesis supervisor, im-

plement a android application with as much as possible services listed before.

Waterfall and spiral model can be eliminated as these models are suitable for large

companies developing large complex softwares. Waterfall model is rigid in sense as

there is no way going back to a phase in case of change of tasks or requirements.

Risk analysis in spiral model is a concept which is applied to large-scale projects in

terms of project completion and budget, hence making spiral model less useful for the

application develop in the master thesis.

A combination of iterative and increment model, and agile model with feedback from

the supervisor can be considered as an ideal model for this application in support of

the master thesis. In this master thesis the supervisor can be considered as customer

or client. This basic flow chart (Figure 2.3) shows the steps while developing the

application. The developer/student and the supervisor co-ordinate time to time for a

duration of six months or less before submitting the final thesis for evaluation.

2.3.2 Software Development Process

As this application follows agile and, incremental and iterative development model the

activities presented here are the final version or are the final increments. These main

activities were followed during this application development.



Figure 2.3: A combination of iterative and icremental model, and agile model

As this application development process follows agile, and incremental and iterative

model. The application development processes had incremental stages in requirements,

planning, implementation and testing, and documentation. As for example the initial

application did not had the password interface (discussed in chapter 7), single call

were made for ”emergency call” instead of multiple calls, fence area management did

not had the functionality of phone vibration, and many other new functionalities were

added over time.



2.3.2.1 Requirements:

The application has to be developed within six months and the following tasks have

to be implemented:

• Chat Service using MOM

• Localization of User

• Fence Area Management

• Ad-hoc communication in Android

2.3.2.2 Planning:

Planning can be divided into three parts: Background study, installation of softwares

necessary to build the application and how to make it useful for an assistance system.

The knowledge and skills of following topics are necessary for the application devel-

opment: Java, Android Development, Message-Oriented Middleware.

These necessary components or softwares have to be installed for the development

of the application:

• Operating System

• Java Development Kit, which is necessary for developing java applications as

Android development is done in specialized Java

• Eclipse and Android Development Tools (ADT), ADT enables Android applica-

tion development in Eclipse. Eclipse is the software development environment

(SDE) used to develop Android applications though it will not work without

ADT.

• Google APIs (Application Program Interface), Google APIs are used to show

Google maps which are necessary for user localization.

To make the application useful for assistance systems the following functionalities

are planned to be included in the application:

• Chat Application: The doctor and senior should be able to chat with each other.

The doctor has some suggestions in case of an emergency or general treatment,

or the senior has some enquiries.



• User Localization and Fence Area Management: The staff in the hospital should

be able track the user. A radius can be implemented which can be considered as

”Safe-Area” for an elderly or a patient. If the user moves out the radius the staff

at the hospital can be informed, a message can be shown on the screen and the

phone will vibrate.

• Emergency Call: In case of emergency one can plan to implement not only one

call but a number of calls.

• Android Ad-hoc: What sort of data can be sent over a wireless channel from one

Android phone to other, so that an Android phone can be deemed suitable for

Ad-hoc communication.

• Preferences: The application should be capable of controlling the features of an

application. It should also protect the application from misuse.

2.3.2.3 Implementation and Testing:

In Part 2, Chapter 5 and onwards a commentary is made on how the applications

have to be coded to accomplish the tasks, though only main part of the code are

discussed (full code can be referenced in the CD provided with the thesis). Testing can

be included in implementation, if there is an error or bug in the code the application

crashes or error message is shown when the application is running.

2.3.2.4 Documentation:

This thesis itself can be considered as the documentation. As it gives the background

knowledge about the application and discusses the ways it can be developed, and

can provide technical specifications for academia or industry interested to develop

applications related to assistance system, Android and Message-Oriented Middleware.

2.3.2.5 Deployment:

This application can be considered as deployed in a software development process when

it has been submitted for final evaluation.



3 Message-Oriented Middleware

Message-Oriented Middleware (MOM) is a middleware that allows an application to

send a message to another application regardless of availability of other application.

”Task b” i.e. Explanation of Message-Oriented Middleware, from Chapter 1. Section

1.4 is covered in this chapter.

3.1 Introduction

Before MOM, the question that comes into one’s mind is what is ”middleware”? Though

there are many definitions for middleware but a general definition would be ”Middle-

ware is a general term for any piece of software that serves to ’glue together’, mediate

between, or enhance separate existing programs.” [cap02].

So one can ask the question what is the difference between middleware and MOM?

There are two types of communications synchronous and asynchronous. A telephone

call can be considered as synchronous while an email would be an example for asyn-

chronous. MOM have the functionality of being asynchronous, an application can send

message and consumer of that message does not have to be available.

Though MOM can be forced to become synchronous by acknowledgements. The

receiver when receives a message sends an acknowledgement to sender and sender will

do further processing on the receipt of an acknowledgement.

3.2 MOM Advantages and Concepts

The main reasons for considering MOM to be advantageous are: buffering, transform-

ing and routing of messages.

The MOM systems contains intermediatory-softwares which has built-in intelligence

of transforming the messages. The sender will send the message in its native format

and will be transformed to the receivers native format.

Message queues are an integral part of MOM systems. These queues are able to store

data temporarily or permanently. Queues helps the MOM systems to be asynchronous



in nature hence keeping the communication online, no matter the receiver is busy or

off-line.

Figure 3.1 shows the basic architecture for a MOM system, where the message

traverses through the queues. The message is also routed and transformed on it’s way

to destination.

Figure 3.1: Message-Oriented Middleware.[CCP11]

These are the basic concepts used in MOM:

3.2.1 Message Broker

It can translate the language of a system to another language from other system.

MOM can manage the connections between different clients. It can store, route and

transform a message.

3.2.2 Client

An end application can be considered as a client and it communicates with the MOM

in the format and language of the Message broker.

3.2.3 Message Structure

The message of MOM is composed of two parts: header and body. Header contains

the information about the message itself and the destination. Message body contains

the data which has to be transferred.

3.3 MOM proctocols and Implementations

All the major vendors have their own implementations, each with its own API and

management tools. JMS (Java Message Service) is developed by sun microsystems.



JMS can send and receive messages across MOM systems. MSMQ (Microsoft Mes-

saging Queue) is a messaging queue, capable of asynchronous messaging. It has been

included since Windows operating system Win95 and Windows NT 4 though for using

it, it needs to be installed.

”The Java EE programming environment provides a standard API called JMS, which

is implemented by most MOM vendors and aims to hide the particular MOM API

implementations; however, JMS does not define the format of the messages that are

exchanged, so JMS systems are not interoperable. Microsoft’s MSMQ doesn’t support

JMS, although there are third-party products that can offer this. WebSphere Message

Broker, from IBM, does provide JMS support, as well as a whole suite of modern

functionality.

The Advanced Message Queuing Protocol (AMQP) is an emerging standard that

defines the protocol and formats used in the messaging server and client, so imple-

mentations are interoperable. AMQP is defined to provide flexible routing, includ-

ing common messaging paradigms like point-to-point, fanout, publish/subscribe, and

request-response. It also supports transaction management, queuing, distribution, se-

curity, management, clustering, federation and heterogeneous multi-platform support.

Java applications that use AMQP are typically written in Java JMS. Other implemen-

tations provide APIs for C++, PHP, Python, Ruby, and other languages.” - [Wik02].



4 Advanced Message Queuing

Protocol

Advanced Message Queuing Protocol (AMQP) is a protocol which is used to connect to

the MOM brokers. These brokers receives messages from source entity and it delivers

it to the destination entity. These MOM brokers are also a part of AMQP standard.

Task c from the Thesis Task List (Chapter 1) is covered in this chapter.

4.1 Introduction

A server in AMQP at first receives data, routes them to a destination and stores the

messages if the destination is not available. In AMQP the concepts of exchanges and

queues are used. An exchange receives a message and routes it to a queue. The

queue stores the message and forward it to a consumer. The exchange forwards the

message according to some rules called bindings. Exchanges, queues and bindings can

be referred as ”Entities”. The terms Producer and Consumer are used instead of Sender

and Receiver respectively.

In figure 4.1 a publisher, exchange, queue and consumers are shown. The consumers

are represented by Cn where n represents a number.

4.2 Main Components

The following components play an important part in the working of AMQP protocol:

4.2.1 Queues

A queue stores a message and delivers it to the consumers in order. It can have the

following properties: private or shared, permanent or temporary. A queue can operate

in a number of modes, as for example, round-robin, temporary reply queue; which



Figure 4.1: Adanced Message Queuing Protocol.[SS08]

are temporary and are private to a subscriber. The queues can be named to have

individuality and, the name of the queue should be unique within its scope.

4.2.2 Exchanges

An exchange accepts a message from the producer and forwards it to the queues. An

exchange does not store a message like a queue. The forwarding to the queues are

done by matching the ”bindings”.

Like queues the exchanges can also be named.

There are different types of exchanges:

4.2.2.1 Direct Exchange:

It can route messages from zero to N queues whenever the message routing key matches

the binding of the queue to the exchange.



4.2.2.2 Fanout Exchange:

Fanout exchange forwards the messages to the all queues within an exchange irrespec-

tive of the routing key.

4.2.2.3 Topic Exchange:

It provides routing to the bound queues based on pattern matching between routing key

in a message and the binding key. For example, the binding key ”*.stock.#” matches

the binding key ”usd.stock” and ”eur.stock.db” but not ”stock.nasdaq”.

4.2.2.4 Header Exchange:

It provides routing based on complex expressions of a message’s header. It can be

considered as a direct exchange but the routing takes place based on header rather

than routing key.

4.2.3 Bindings

It can be considered as a relationship between an exchange and a queue. Bindings tell

the exchange which messages should be forwarded to which queues. The life span of

binding is exchange or queue dependent. The binding is destroyed whenever the queue

or the exchange is destroyed. The bindings are created at the client side and can have

the following pseudo syntax:

Exchange.Bind <exchange-name> TO <queue-name> WHERE <conidition>

4.3 RabbitMQ

There are a number of message brokers but RabbitMQ is one of the most famous

software brokers available, which is being based on AMQP and is open source. Erlang

is the language in which RabbitMQ is developed and uses the Open Telecom Platform

(OTP) for failover and clustering. The qualities of RabbitMQ are: portability and

reliability. RabbitMQ has support for SMTP, STOMP and HTTP gateways.

It is being supported by contributions from a high number of contributors.

Other message brokers are also available like Apache Qpid (http://qpid.apache.

org/), JORAM (Java Open Reliable Aysnchronous Messageing) ( http://joram.ow2.

org/) and StormMQ (http://stormmq.com/).


http://qpid.apache.org/

http://qpid.apache.org/

http://joram.ow2.org/

http://joram.ow2.org/

http://stormmq.com/


5 Ad-hoc in Android

Ad-hoc is the ability of communicating with users with out the existence of Infras-

tructure. [HT00] In Ad-hoc communication a user acts as a source of communication

for other user. Ad-hoc is predominantly considered to be wireless. Android supports

WiFi and Bluetooth technology. One can investigate these technologies to check-out

the limitations one can face while implementing Ad-hoc in Android. Though there is

no support for Ad-hoc in previous releases of Android. We can check the usefulness of

these Bluetooth or WiFi for Ad-hoc if it is able to transfer a decent amount of data as

for an image.

In this chapter, task d is investigated from the task list.

5.1 WiFi

WiFi has a data rate of 54 Mbps and the IEEE standard is 802.11x. WiFi is extensively

used in the buildings to provide internet connections via a router or an access point.

WiFi is classified as W-LAN (Wireless Local Area Network) and range of WiFi is about

32 meter indoors.

We can also use WiFi in our Android phones for Ad-hoc. Though in Android

release 14, it will provide a library for peer-to-peer connections over WiFi. Namely

the phones, HTC One X and Samsung S3 are the one of the famous phones that has

Android Release 14. So it would be advisable to use the WiFi’s p2p package as it

provides the required Ad-hoc functionality with less coding and will be more bug-free.

5.2 Bluetooth

Bluetooth is also a wireless technology and used for communication over short dis-

tances. Bluetooth can be classified into PAN (Personal Area Network) and has a

range of 10 meters or less. It provides a data rate of 1 Mbps. In this thesis Bluetooth

is used as a source of wireless data transfer and Ad-hoc.



5.2.1 Initial Setup:

For using Bluetooth in Android, Bluetooth must be enabled from settings, or can be

enabled using an intent. In case, if two of the devices have not been paired before, one

of the devices has to be made discoverable, for the first time connection.

5.2.2 Establishing a Connection:

For the communication to take place between two Bluetooth devices first a connection

has to be established. For the connection one device has to act as a server and ”listen”

to the incoming connections. It will listen using an instance of ”BluetoothServer-

Socket” class and when the connection is established it will transfer the connection to

the ”BluetoothSocket”. Whenever the connection is established the ”BluetoothServer-

Socket” should be closed if there are no more connections to make.

If one acts as a server the other phone with the Bluetooth device can act as a client.

This Bluetooth device will ”create” channels which connects with the channels from

Server, when the Server is ”listening”. Here the connection is made in a ”Bluetooth-

Socket”. The ”BluetoothSocket” has two possibilities either it connects or it closes.

There can be many phones trying to connect to each other within a small area though

it is distinguished by UUID (Universally Unique Identifier). The UUID also differen-

tiates among types of channels that are made as for example, serial communication,

OBEX transfer protocol, RFCOMM,...etc.

5.2.3 Data Transfer:

The data can be transferred between two devices, one device can send it through ”Out-

putStream” of a ”BluetoothSocket” and the other can receive it through ”InputStream”

of a ”BluetoothSocket”. The data is sent and received in bytes and has to be converted

into its desired type from bytes.


24

Part II

Implementation


6 Prerequisites 25

6 Prerequisites

In order to run the application in support of the master thesis the following softwares

are needed to be already installed on the PC.

1. Operating System

2. JDK

3. Eclipse

4. ADT

5. Erlang

6. RabbitMQ Server

7. Google API

This chapter will provide the basic information for setting up the software environment

for execution and development of the Android application in support of the master

thesis.

6.1 Operating System

An Operating System is a set of softwares which works as a single unit and helps

in accomplishing different tasks by making use of computer hardware. The main

component used for development of the application in the thesis is Android Software

Development Kit (SDK). The Android SDK is runnable on the following Operating

Systems (OS) [AD09e]:

• Windows XP (32-bit), Vista (32- or 64-bit), or Windows 7 (32- or 64-bit)

• Mac OS X 10.5.8 or later (x86 only)

• Linux (tested on Ubuntu Linux, Lucid Lynx)


6 Prerequisites 26

• GNU C Library (glibc) 2.7 or later is required.

• On Ubuntu Linux, version 8.04 or later is required.

• 64-bit distributions must be capable of running 32-bit applications.

One of these OS needs to be present in a computer for Android SDK.

6.2 JDK

JDK stands for Java Development Kit. It is necessary to be present for develop-

ment of applications in Java. It can be downloaded from http://www.oracle.com/

technetwork/java/javase/downloads/index.html.

6.3 Eclipse

Eclipse is a Software Development Environment (SDE) mainly used for Java applica-

tions development. The Android Applications are also developed in specialized Java.

Eclipse can be downloaded from http://www.eclipse.org/downloads/.

6.4 ADT

Android applications can be developed in Eclipse until ADT is installed, ADT stands

for Android Development Tools. ADT is a plug-in which is integrated in Eclipse for

making powerful Android applications.

When JDK and Eclipse have been installed then ADT can be downloaded by going to

”Help > Install New Software...”. Then clicking ”Add”which is present on top right por-

tion of the screen. In the Add Respository dialog ”https://dl-ssl.google.com/android/eclipse”

should be provided. After which it is installed as other ordinary softwares.

6.5 Erlang

Erlang is a general-purpose programming language and runtime environment [Erl99].

RabbitMQ is written in Erlang and RabbitMQ uses Erlang to carry it’s operations. Er-

lang’s windows binary file has to be installed from http://www.erlang.org/download.

html before using RabbitMQ in Eclipse for Android.


http://www.oracle.com/technetwork/java/javase/downloads/index.html

http://www.oracle.com/technetwork/java/javase/downloads/index.html

http://www.eclipse.org/downloads/

http://www.erlang.org/download.html

http://www.erlang.org/download.html

6 Prerequisites 27

6.6 RabbitMQ Server

As mentioned in previous sections of thesis, RabbitMQ is used as message broker

software for MOM. It can be downloaded from http://www.rabbitmq.com/download.

html.

6.7 Google API

For localization of user, Google maps can be used for spotting out the user. To use

the Google maps, Google APIs are used which provides Add-ons for the Android SDK

so that custom set of libraries and services provided by Google can be made use of.

The Google APIs can be installed from ”Window > Android SDK Manager” in

Eclipse. Figure 6.1 represents a snapshot of the screen which should appear after

clicking ”Android SDK Manager”.

Figure 6.1: Screen shot while installing Google API.


http://www.rabbitmq.com/download.html

http://www.rabbitmq.com/download.html


7 Initial Interface

When a user starts the application the screen that appears first would be the ”Initial

Interface” after which the user can move on to the other interface and access the fea-

tures of the application. Initial Interface in this application has two stages: Password

Interface and Buttons Interface. In this chapter the commentary is only made on the

main components and ideas in the code, full code is provided in Appendix A.

It is suggested that reader should have knowledge of Java and Android Application

development in order to understand and develop such applications.

7.1 Password Interface

An ”AlertDialog” appears when the application starts as shown in figure 7.1. Which

provides basic information about application. An ”AlertDialog” is a subclass of Dialog

class and is used to display buttons. ”setMessage()” method can be used to display a

string in this dialog. It can be made by making an instance of ”AlertDialog.Builder”

and can be shown by calling ”show()” on the ”AlertDialog.Builder” object. When the

”OK” button is clicked the dialog disappears.

1 Aler tDia log . Bui lder b u i l d e r = new Aler tDia log . Bui lder ( t h i s ) ;

2 b u i l d e r . setMessage ( ” . . . ”) ;

3 b u i l d e r . show ( ) ;

The application can be protected by a simple string comparison. First of all an

”EditText” object is created for letting the user to enter some text for the password.

”EditText” class is a layer implemented over ”TextView” class which has the property

of being editable. A ”TextView” class is used for displaying text to users. A ”Button”

can be implemented with ”onClick”, which is a method of ”Button” class.

The text entered for password can be retrieved by calling ”getText().toString()” from

”EditText”. If the string is equal to the string stored as the intended password, then

we can initiate an ”Intent” to an other class. An ”Intent” provides a rough description

of an task which is going to be performed. Else we can show a message to enter a



Figure 7.1: The Alert dialog that appears when the applicaton starts.

correct password. This password interface is shown in figure 7.2.

1 name = ( EditText ) etv1 . getText ( ) . t oS t r i ng ( ) ;

2 i f (name . equa l s ( password ) )

3 {4 In tent a = new Intent ( th i s , xxx . c l a s s ) ;

5 s t a r t A c t i v i t y ( a ) ;

6 f i n i s h ( ) ;

7 }

7.2 Buttons Interface

Figure 7.3 shows the button interface of the application.

Buttons can be touched or clicked, buttons can used in a number of ways to perform

different tasks. ”onClick” can be registered with a button to perform an action.

For this interface four instances of ”Button”class have been made. These four objects

or intsances implements ”onClick” method. Four different intents are registered for

four different classes. When a button is clicked or pressed an ”Intent” is passed to



Figure 7.2: The password interface.

Figure 7.3: The Buttons interface.

”startActivity” method. These buttons are designed and defined in an XML file in

”layout” folder.

1 View hardwareButton = findViewById (R. id . chatButton ) ;

2 hardwareButton . s e tOnCl i ckL i s t ene r ( t h i s ) ;

3 case R. id . chatButton :

4 In tent a = new Intent ( th i s , ActivityHome . c l a s s



) ;

5 s t a r t A c t i v i t y ( a ) ;



8 Chat Application

One of the task of this Master Thesis is to implement a chat service in Android where

the messaging goes through a message broker on a MOM. The internet permission

needs to be included in the Android application manifest, as the chat application will

need access to the internet for connecting to a server.

Task e i.e. Development of Chat Application using MOM, from Thesis Task List is

implemented in this Chapter. Figure 8.1 shows the snapshot of the chat application.

8.1 Pre-requisites

RabbitMQ is a message broker for MOM and it provides Java Client Library which can

downloaded from http://www.rabbitmq.com/java-client.html. First of all these

libraries should be included into Build Path of the project, Project > Build Path >

Add External Archives. The internet permission is used because the MOM messaging

needs an internet connection

<uses-permission android:name=”android.permission.INTERNET” />

8.2 RabbitMQ Background

In the chat service application it is intended that a number of users can be included in

the application. For multiple users a ”fanout” exchange is used because it broadcasts

a message and any queue with a fanout exchange will receive the message. The fanout

exchange is explained in chapter 4.

8.2.1 Publishing

For publishing a message first a connection to the server is made and channel creation

is done. This is accomplished by the following code:

1 ConnectionFactory f a c t o r y = new ConnectionFactory ( ) ;


http://www.rabbitmq.com/java-client.html


2 f a c t o r y . setHost ( ” l o c a l h o s t ”) ;

3 Connection connect ion = f a c t o r y . newConnection ( ) ;

4 Channel channel = connect ion . createChannel ( ) ;\ newl ine

The channel needs to declare an exchange and actually publish a message.

1 channel . exchangeDeclare (EXCHANGE NAME, ”fanout ”) ;

2 St r ing message = ”Hello World ! ” ;

3 channel . ba s i cPub l i sh (EXCHANGE NAME, ”” , nu l l , message . getBytes

( ) ) ;

4 System . out . p r i n t l n ( ” [ x ] Sent ’ ” + message + ” ’ ”) ;\ newl ine

At last the channel and the connection needs to be closed

1 channel . c l o s e ( ) ;

2 connect ion . c l o s e ( ) ;

8.2.2 Consuming

The implementation for receiving or consuming is almost similar except that instead

of publishing, consumption of messages is done. ”QueueingConsumer” is a class which

consumes the messages from a queue. The following is the code for consuming:

1 St r ing queueName = channel . queueDeclare ( ) . getQueue ( ) ;

2 channel . queueBind (queueName , EXCHANGE NAME, ””) ;

3 QueueingConsumer consumer = new QueueingConsumer ( channel ) ;

4 channel . basicConsume (QUEUE NAME, true , consumer ) ;

5 while ( t rue ) {6 QueueingConsumer . De l ive ry d e l i v e r y = consumer .

nextDe l ive ry ( ) ;

7 St r ing message = new St r ing ( d e l i v e r y . getBody ( ) ) ;

8 System . out . p r i n t l n ( ” [ x ] Received ’ ” + message + ” ’ ”) ;

9 }



8.3 RabbitMQ on Android

The publishing/consuming for MOM using RabbitMQ is more complicated in Android

Environment. It requires efficient threading to send and receive messages via MOM.

The concepts of threads, handlers and runnables needs to discussed for sending and

receiving a message via MOM. A thread is a concurrent unit of execution [AD09f]. A

Handler allows us to send messages and runnable objects in associated with a thread

[AD09c]. While Runnable is a command that can be executed [AD09d]. First an

object of ”Handler” is created, then an object of ”Runnable” is defined. The ”Runnable”

instance is passed to ”post()” method of ”Handler”. Then a thread is declared where

runnable is passed in its default ”run()” method.

The following pseudo-code illustrates the method:

1 handler=new Handler ( ) ;

2 Runnable r=new Runnable ( )

3 {4 pub l i c void run ( )

5 {6 . . .

7 }8 } ;

9 handler . postDelayed ( r , 1000) ;

10 Thread thread = new Thread ( )

11 {12 @Override

13 pub l i c void run ( ) {14 t ry {15 while ( t rue ) {16 RABBITMQ COMMANDS. . .

17 }18 } catch ( Inter ruptedExcept ion e ) {19 e . pr intStackTrace ( ) ;

20 }21 }22 } ;

23 thread . s t a r t ( ) ;



Now the code for sending and receiving is implemented as explained above.

This chat application is intended for many users so, a ”fanout” exchange serves the

purpose. The ”fanout” exchange sends the messages to all the queues in an exchange.

The following code declares a ”fanout” exchange.

1 channel . exchangeDeclare (EXCHANGE NAME, ”fanout ” , t rue ) ;

Figure 8.1: Chat Application using AMQP.



9 User localization and fence area

By using the Global Positioning System (GPS) of an Android Phone we can locate

the user and define the areas where the user can move. The location of a user can be

shown on Google maps. Google API is a necessary component for the maps. The main

package used for accessing location is ”android.location” and the maps can be obtained

from Google maps external library. When showing the maps the key has to be included

in the application which can be obtained from http://code.google.com/android/

add-ons/google-apis/mapkey.html. For using GPS and Google maps the following

permissions are needed: ”ACCESS FINE LOCATION”, ”ACCESS COARSE LOCATION”

and ”INTERNET”.

In this chapter two tasks are implemented i.e. task f & task g.

9.1 Latitude and Longitude

Location is retrieved by calling ”requestLocationUpdates()” from ”LocationManager”

class. The following code shows how to get the updates:

1 LocationManager locat ionManager = ( LocationManager )

2 getSystemServ ice ( Context .LOCATION SERVICE) ;

3 C r i t e r i a c r i t e r i a = new C r i t e r i a ( ) ;

4 c r i t e r i a . setAccuracy ( C r i t e r i a .ACCURACY FINE) ;

5 prov ide r = locat ionManager . getBestProv ider ( c r i t e r i a , f a l s e ) ;

6 locat ionManager . requestLocat ionUpdates ( prov ider , 0 , 1 , t h i s ) ;

In above code ”Criteria” is defined as ”ACCURACY FINE” which helps in getting

fine readings.

For getting recent latitude and longitude the method ”onLocationChanged()” is im-

plemented. The latitude and longitude can be obtained from an ”LocationManager”

object which is passed in ”onLocationChanged()” method.


http://code.google.com/android/add-ons/google-apis/mapkey.html

http://code.google.com/android/add-ons/google-apis/mapkey.html


1 pub l i c void onLocationChanged ( Locat ion l o c a t i o n ) {2 double l a t 1 = (double ) ( l o c a t i o n . ge tLat i tude

( ) ) ;

3 double lng1= (double ) ( l o c a t i o n . getLongitude ( )

) ;

4 }

9.2 User Location and Fence Area

The user location can be represented by a dot and fence area by a circle as in figure

9.1. The fence area is the region where the user can roam.

To draw the point and the circle, ”Canvas” class is used. To draw anything on

android there are four basic components [AD09b]:

1. Bitmap

2. Canvas

3. Drawing primitive

4. Paint

The main method for drawing the dot and circle is to create an object of canvas and

passing the parameters to ”drawBitmap()” and ”drawCircle()” methods.

1 canvas . drawBitmap (bmp, sc reenPts . x , s c reenPts . y−( f loat )

mPixRadius , lp4 ) ;

2 canvas . drawCirc le (mapView . getWidth ( ) /2 , mapView . getHeight ( )

/2−( f loat ) mPixRadius , ( f loat ) mPixRadius , lp4 ) ;

The point can be synchronized with current latitude and longitude readings by

passing the coordinates to an object of ”Geopoint” class. A ”Geopoint” is a class

representing the latitude and longitude in microdegrees.

9.3 Fence Area Calculation

The readings that are obtained from ”LocationManager” are in latitude and longitude,

represented in degrees. Haversine formula [MT99] is used to calculate the distance



Figure 9.1: User Location: User near Haus I in the campus of TU-Ilmenau.

in kilometers between two different coordinates. The Haversine formula can be im-

plemented in the ”onLocationChanged()” method of the ”LocationManager” class as

following:

1 double d la t = (double ) l a t 2 − l a t 1 ;

2 double dlng = (double ) lng2 − lng1 ;

3 d la t = Math . toRadians ( d l a t ) ;

4 dlng = Math . toRadians ( dlng ) ;

5 double d la t1 = Math . toRadians ( l a t 1 ) ;

6 double dlng1 = Math . toRadians ( lng1 ) ;

7 double d la t2 = Math . toRadians ( (double ) l a t 2 ) ;

8 double dlng2 = Math . toRadians ( (double ) lng2 ) ;

9 double a = Math . s i n ( d l a t /2) ∗ Math . s i n ( d l a t /2) +

10 Math . s i n ( dlng /2) ∗ Math . s i n ( dlng /2) ∗ Math . cos ( d la t1 ) ∗Math . cos ( d la t2 ) ;

11 double c = 2 ∗ Math . atan2 (Math . s q r t ( a ) , Math . s q r t (1−a ) ) ;

12 Result = 6371 ∗ c ;



9.4 Fence Area Management

The fence area management will take place in ”onLocationChanged()”method when the

GPS of the mobile retrieves new values of longitude and latitude. If a user moves out

of fence area (circle) which is calculated as in ”Fence Area Calculation”, the following

actions are implemented:

9.4.1 Sending a Message to a server via MOM

One can install a RabbitMQ server software on a server. As this application is for

elderly assistance system, the server can be considered to be in a hospital. As the

distance increases then a specific radius, a message will be sent to the server showing

the current latitude and longitude of the user.

As discussed in chapter 8 that RabbitMQ on Android is implemented using threads.

For this particular application a non-blocking User Interface (UI) thread is needed for

which ”AsyncTask” class can be used. The advantage of ”AsyncTask” is that in can

perform thread operations in the background.

The location information about the latitude and longitude can be stored in a string

inside ”onLocationChanged()”method. The string can be sent to the ”execute”method

from a class which ”extends” the ”AysncTask” class. The ”AsyncTask” class can imple-

ments the string in ”doInBackground()” method.

1 pub l i c c l a s s Sender extends AsyncTask<Str ing , Void , Void >{2 @Override

3 protec ted Void doInBackground ( St r ing . . . Message ) {4 RabbitMQ Commands . . .

5 }6 }

As in chat service we used a ”fanout” exchange which can be utilized to send the

messages to a number of users. As in this case the server at the hospital needs to know

about the location of user. For critical messages a ”direct” exchange would be ideal

because it consumes the messages when routing key matches the bindings key, hence

only delivering the messages to server at hospital.

For publishing the messages via ”direct” exchange the code will be as following:

1 channel . exchangeDeclare (EXCHANGE NAME, ” d i r e c t ”) ;

2 channel . ba s i cPub l i sh (EXCHANGE NAME, ”rout ing key ” , nu l l ,

message . getBytes ( ) ) ;



For consuming or subscribing to the messages from a ”direct” exchange the code will

be as following:

1 channel . exchangeDeclare (EXCHANGE NAME, ” d i r e c t ”) ;

2 St r ing queueName = channel . queueDeclare ( ) . getQueue ( ) ;

3 channel . queueBind (queueName , EXCHANGE NAME, ”rout ing key ”) ;

9.4.2 Toast

A toast is a message which is shown on the phone screen for a short amount of time.

If the user moves out of area a toast can be shown to the user that he/she is out of

the ”safezone”.

Safezone can be considered a region in assistance system where the elder/patient is

safe to roam.

9.4.3 Vibration

The phone also vibrates when the user moves out of safezone. It is also implemented

in ”onLocationChanged()” method. The vibration time can also set by passing a pa-

rameter to ”vibrate” method. The units of parameters passed to ”vibrate” method are

in milliseconds.

1 Vibrator v = ( Vibrator ) getSystemServ ice ( Context .

VIBRATOR SERVICE) ;

2 v . v ib r a t e (1000) ;



10 Emergency Calls

”Implementation of multiple calls in case of emergency” which is ”task h” from the task

list (chapter 1) is covered in this chapter.

Figure 10.1: Call snapshot.

In an assistance system a number of calls are made in case of emergency. Fortunately

in android there is a possibility of making calls. The ”TelephonyManager” can be used

to make a call by making an object of ”TelephonyManager” and making a reference to

an instance through Context.getSystemService(Context.TELEPHONY SERVICE). It

can be done as following:

1 TelephonyManager telephonyManager = ( TelephonyManager )

getSystemServ ice ( Context .TELEPHONY SERVICE) ;



”Intent” can be used to initiate the call, an object of ”Intent” which refers to an

instance of ”ACTION CALL” is made. The number is parsed to the object of ”Intent”.

1 In tent c a l l I n t e n t 1 = new Intent ( Intent .ACTION CALL) ;

2 c a l l I n t e n t 1 . setData ( Uri . parse ( ” t e l :999888111 ”) ) ;

Multiple calls can be made and an option can be given to the user for making another

call.

The ”Make Another Call?” dialog is achieved via ”AlertDialog” explained in Section

1 of Chapter 7. In this application the ”Make Another Call?” option as in figure

10.2 appears three times, if the user clicks ”yes” each time. Three different dummy

phone numbers are dialed when ”yes” is clicked, which can be replaced by actual phone

numbers.

Figure 10.2: Make another call? option.


11 Preferences 43

11 Preferences

Preferences or settings is necessary for the application where user can provide trivial

information regarding application’s functionality. In this application preferences is

used for MOM, where user can feed information related hosts, exchanges...etc.

Figure 11.1 will appear when ”Preferences” button is clicked in buttons interface

(figure 7.3), which gives acces to settings for chat application, and fence area manage-

ment.

Figure 11.1: Preferences main page.

For preferences ”SharedPreferences” class is used, which provides key-value pairs to

store and get the data. The values are stored even the application is killed.

For retrieving data from ”SharedPreferences” a string indetifier is used and a mode

is used to access them. The mode defines the access level for example, read-only, write-

only,...etc.


11 Preferences 44

1 SharedPre f e rences p r e f = getSharedPre f e r ence s (PREF NAME,

MODE PRIVATE) ;

Data from preferences can be read directly from preferences,

1 p r e f . read ( St r ing i d e n t i f i e r , default ) ;

For modifying data an editor should be called and then committing it.

1 p r e f . e d i t ( ) . putStr ing ( ”NAME” , ”Simone ”) . commit ( ) ;

11.1 Preferences for Chat

As the chat service uses a ”fanout”exchange as explained earlier. Two fields are needed:

host and exchange.

Figure 11.2: Preferences for chat application.


11 Preferences 45

11.2 Preferences for Fence Area Management

As explained earlier in Fence area Management the direct exchange is used. In direct

exchange the following information is needed:

• Host (Server address at the hospital)

• Name of exchange

• Routing key

• Radius (where user is allowed to move)

Figure 11.3: Preferences for fence area management.



12 Android Ad-hoc: Bluetooth

An Ad-hoc network does not rely on pre-existing network. In wireless Ad-hoc, data is

forwarded from one node to other. There is no generic way of providing peer-to-peer

connection in Android except Android’s p2p package in Release 14.

In this chapter it is shown that data in form of an image can be sent over Bluetooth,

as shown in figure 12.1. Hence proving the Bluetooth as a possible client for Ad-hoc

in Android.

For using Bluetooth for a phone we need to give permission for ”BLUETOOTH”. If

we want to make the phone discoverable programmatically we will also need ”BLUE-

TOOTH ADMIN” permission.

For Ad-hoc communication in Android two mobiles phones are needed, one phone

acts as a server and the other phone acts as a client.

”Implementation for Ad-hoc in Android” which is task I, is discussed in this chapter.

12.1 Client

A client connects to a server, i.e., A ”BluetoothSocket” from client mobile will connect

to ”BluetoothServerSocket” class on the mobile acting as a server. This client will send

the data to the server mobile.

First of all the Blueetooth adapter of the mobile is need.

1 BluetoothApadter mBluetoothAdapter = BluetoothAdapter .

getDefaultAdapter ( ) ;

Some of Bluetooth operations are blocking calls so it would be better to run them

in a separate thread. A class which extends the thread, we try to make a connection

with a channel from client mobile to server mobile with the same UUID (Universally

Unique Identifier).



1 BluetoothSocket btSocket = dev i ce .

createRfcommSocketToServiceRecord (MY UUID) ;

2 btSocket . connect ( ) ;

Once connected the client can send data by writing on the ”OutputStream” of the

”BluetoothSocket”.

1 outStream = btSocket . getOutputStream ( ) ;

As we are sending images we transform an image to bytes and send the image as

bytes.

1 Bitmap bm = BitmapFactory . decodeResource ( getResources ( ) , R.

drawable . i c l a u n c h e r ) ;

2 ByteArrayOutputStream baos = new ByteArrayOutputStream ( ) ;

3 bm. compress ( Bitmap . CompressFormat .JPEG, 100 , baos ) ;

4 byte [ ] b = baos . toByteArray ( ) ;

and then writing to bytes to ”OutputStream” when a button is clicked.

1 outStream . wr i t e (b) ;

12.2 Server

The server listens to the incoming connections and receives the data. The data received

is loaded into an ”ImageView”.

Same like in client the Bluetooth operations for server are blocking calls and it would

be better to run them in a thread.

1 BluetoothServerSocket Tmp = mBluetoothAdapter .

l istenUsingRfcommWithServiceRecord ( ”Bluetooth ” , MY UUID) ;

When bluetooth is listening for a channel through ”BluetoothServerSocket” we can

transfer the channel to ”BluetoothSocket”, for receiving that data.

1 BluetoothSocket bt socke t = Tmp. accept ( ) ;



From this BluetoothSocket we can read the bytes from the InputStream to a buffer

which has been sent by the client.

1 int byteNo = InputStream . read ( b u f f e r ) ;

We have to ensure that all the data packets should be read.

1 i f ( byteNo != −1) {2 // ensure DATAMAXSIZE Byte i s read .

3 int byteNo2 = byteNo ;

4 int b u f f e r S i z e = 2691 ;

5 while ( byteNo2 != b u f f e r S i z e ){6 b u f f e r S i z e = b u f f e r S i z e − byteNo2 ;

7 byteNo2 = mmInStream . read ( bu f f e r , byteNo , b u f f e r S i z e )

;

8 i f ( byteNo2 == −1){9 break ;

10 }11 byteNo = byteNo+byteNo2 ;

12 }13 }

At last we will close the ”BluetoothServerSocket” if there are no more connections

to make.

1 b lue toothServe rSocket . c l o s e ( ) ;

We need to take care of bufferSize it should equal the length of the bytes being sent

by the client.



Figure 12.1: Image received via bluetooth for Ad-hoc communication.



13 The Big Picture

In this chapter an effort is made to give the user an overview of the thesis, through

a diagram (13.1). The figure illustrates how different tasks and concepts can be con-

nected to each other. The master thesis is divided into five fields or tasks namely,

Software Development Processes and Models, MOM, User Localization, Multiple Calls

and Android Ad-hoc.

Figure 13.1: Diagram representing the whole thesis

In ”Software Development Processes and Models” different software development

processes and models are discussed. A combination of agile, and incremental and

iterative model is chosen as suitable model for the application developed in this thesis.

The ”chat application” solely uses the MOM. The users send and receive messages

over the MOM.

The User Localization primarily uses the GPS by reading the latitude and longitude

co-ordinates. The user localization application is extended to the fence area manage-

ment application which is connected to ”MOM”. When the user moves out of the circle



which represents the fence area, a message is sent through the server (supposedly in a

hospital) which uses MOM.

Besides sending the message, the smart phone shows a message on the screen that

the user is out of ”safe-zone” and also the phone vibrates.

In the figure, ”Multiple Calls” rectangle is also shown which represents a completion

of task. The senior is able to call multiple numbers in case of emergency.

At last the Ad-hoc communication in Android is shown, which extends to ”Bluetooth

Image Transfer”. It means that Android is capable of Ad-hoc as bluetooth in Android

is capable of transfering an image.


14 Conclusion 52

14 Conclusion

The application in this Master thesis is developed according to a combination of agile,

and iterative and incremental model. This combination of models gives an opportunity

to the student or developer to change the application in later stages, as opposed to

waterfall model. The supervisor will be considered as a client and feedback from the

supervisor can be considered as the feedback in the agile model.

The AMQP from the MOM can be chosen as a platform for a chat application in

Android. Though the RabbitMQ commands have to be executed in threads and the

code can be considered as a bit humongous. The final conclusion of MOM for Android

is that MOM serves the purpose well while developing the chat application. Once

the RabbitMQ clients are installed, easy messaging can take place without worrying

about difference of platforms and softwares. Different type of exchanges can be used

for the chat application, a fanout exchange can be used for a group chat while a direct

exchange can be used for discreet chat.

The localization application for the Assistance System has a radius which can be

altered in ”Preferences” and when the user goes out of the radius, a server in a hospital

can be sent a message showing the latitude and longitude of the patient or elder.

Though for showing the maps the user must have a SIM card which supports internet,

as internet is not available out-doors everywhere.

Emergency Call is a simple application but can be considered as important part

to the Assistance Systems. There is no intelligent way of distinguishing between the

called number responses, so an option should be provided for making another call.

While testing the Ad-hoc for Bluetooth, it would be better if a Server-Client topology

is implemented where one phone sends and other receives. It will keep the code small,

less-error prone and understandable. If the data sent is large in size (more than 970

bytes), an algorithm should be implemented to retrieve all the data.


15 Future Directions 53

15 Future Directions

As the functionality of AMQP has been tested on Android for sending messages in

this thesis. It would be interesting to find the possibility of streaming of audio and

video over MOM as the buffer size increases. RabbitMQ C-clients for Android NDK

can also be tested.

As of Android Release 14, the WiFi will be able to support Ad-hoc connections.

One can try transferring data in WiFi as done in Bluetooth in this thesis. The data

can tested for multiple hops in an Android ad-hoc network and we can look for any

loss of data and apply different data error correction schemes. Android for Ad-hoc,

can be also an interesting topic to TU-Ilmenau’s graduate program ”Mobicom” as they

are investigating telecommunications aspects in disaster scenarios.

In Android API 14, the Bluetooth Health Device Profile (HDP) is also available.

HDP can connect to health devices with bluetooth, such as thermometers, blood meters

and heart-rate monitors [AD09a]. One can experiment with the health profiles for

interesting new features for an assistance system application and try to integrate it with

localization application from this thesis for a smaller radius as it involves Bluetooth.


54

Appendix



A Android Application Development -

Graphical User Interface

In this Appendix the code for buttons interface (Chapter 7) is shown, to give the reader

an idea of Android application development.

Mostly in Android application four files are used for development: Java file / class

(source folder), main.xml (res/layout folder), string.xml (res/values folder) and An-

droid Manifest file (main project folder).

Java files consists of main code for an application, main.xml helps in layout and

designing, string.xml is mainly used to provide information which is shown in user

interface components in main.xml. AndroidManifest.xml is also an important file in

the application, it is used to provide the permissions for different resources used as for

example, bluetooth, internet and GPS.

A.1 Master ThesisActivity.java

1 package com . master . t h e s i s ;

2

3 import android . app . Ac t i v i ty ;

4 import android . content . In tent ;

5 import android . os . Bundle ;

6 import android . view . View ;

7 import android . view . View . OnCl ickLis tener ;

8

9 pub l i c c l a s s Maste r Thes i sAct iv i ty extends Act i v i ty implements

OnCl ickListener {10 /∗∗ Cal l ed when the a c t i v i t y i s f i r s t c r e a t e d . ∗/11 St r ing name ;

12 @Override

13 pub l i c void onCreate ( Bundle savedIns tanceSta te ) {



14 super . onCreate ( savedIns tanceState ) ;

15 setContentView (R. layout . main ) ;

16

17 // Set up c l i c k l i s t e n e r s f o r a l l the b u t t o n s

18 View hardwareButton = findViewById (R. id .

chat button ) ;

19 hardwareButton . s e tOnCl i ckL i s t ene r ( t h i s ) ;

20

21 View systemButton = findViewById (R. id .

l o c a l i z a t i o n b u t t o n ) ;

22 systemButton . s e tOnCl i ckL i s t ene r ( t h i s ) ;

23

24 View emergencyButton = findViewById (R. id .

emergency button ) ;

25 emergencyButton . s e tOnCl i ckL i s t ene r ( t h i s ) ;

26

27 View pre fe renceButton = findViewById (R. id .

p r e f e r enc e s bu t t on ) ;

28 pre fe renceButton . s e tOnCl i ckL i s t ene r ( t h i s ) ;

29

30 View bluetoothButton = findViewById (R. id .

b luetooth button ) ;

31 bluetoothButton . s e tOnCl i ckL i s t ene r ( t h i s ) ;

32

33 }34

35 pub l i c void onCl ick ( View v ) {36 switch ( v . ge t Id ( ) ){37 case R. id . chat button :

38 In tent a = new Intent ( th i s ,

ActivityHome . c l a s s ) ;

39 s t a r t A c t i v i t y ( a ) ;

40

41 break ;

42

43 case R. id . l o c a l i z a t i o n b u t t o n :



44 In tent b = new Intent ( th i s ,

Maps newActivity . c l a s s ) ;

45 s t a r t A c t i v i t y (b) ;

46 break ;

47

48 case R. id . emergency button :

49 In tent c = new Intent ( th i s , Emergency .

c l a s s ) ;

50 s t a r t A c t i v i t y ( c ) ;

51 break ;

52

53 case R. id . p r e f e r enc e s bu t ton :

54 In tent d = new Intent ( th i s ,

P r e f e r e n c e s A c t i v i t y . c l a s s ) ;

55 s t a r t A c t i v i t y (d) ;

56 break ;

57

58 case R. id . b luetooth button :

59 In tent e = new Intent ( th i s ,

Bluetooth main . c l a s s ) ;

60 s t a r t A c t i v i t y ( e ) ;

61 break ;

62

63 }64 }65 }

A.2 main.xml

1 <?xml ve r s i on=”1 .0 ” encoding=”utf−8”?>

2 <LinearLayout xmlns : android=”http :// schemas . android . com/apk/

r e s / android ”

3 android : layout width=” f i l l p a r e n t ”

4 android : l ayou t he i gh t=” f i l l p a r e n t ”

5 android : g rav i ty=” c e n t e r v e r t i c a l ”

6 android : o r i e n t a t i o n=” v e r t i c a l ”



7 android : background=”#6495ED”>

8

9 <TextView


11 android : l ayou t he i gh t=”wrap content ”

12 android : t ex t=”@str ing / h e l l o ” />

13

14 <Button

15 android : id=”@+id / chat button ”



18 android : t ex t=”@str ing / c h a t l a b e l ” />

19

20 <Button

21 android : id=”@+id / l o c a l i z a t i o n b u t t o n ”



24 android : t ex t=”@str ing / l o c a l i z a t i o n l a b e l ” />

25 <Button

26 android : id=”@+id / emergency button ”



29 android : t ex t=”@str ing / emergency labe l ” />

30 <Button

31 android : id=”@+id / b luetooth button ”



34 android : t ex t=”Bluetooth−Adhoc ”

35 />

36

37 <Button

38 android : id=”@+id / p r e f e r enc e s bu t t on ”



41 android : t ex t=”@str ing / p r e f e r e n c e s l a b e l ” />

42



43 </LinearLayout>

A.3 string.xml

1


3 <r e source s>

4

5 <s t r i n g name=” h e l l o ”></s t r i ng>

6 <s t r i n g name=”app name ”>Master Thesis</s t r i ng>

7 <s t r i n g name=”save ”>Show Ci r l c e </s t r i ng>

8 <s t r i n g name=”c h a t l a b e l ”>Chat Serv ice </s t r i ng>

9 <s t r i n g name=” l o c a l i z a t i o n l a b e l ”>Loca l i z a t i on </s t r i ng>

10 <s t r i n g name=”password labe l ”>Enter Password</s t r i ng>

11 <s t r i n g name=”emergency labe l ”>Emergency Call</s t r i ng>

12 <s t r i n g name=” p r e f e r e n c e s l a b e l ”>Pre f e r ence s </s t r i ng>

13 <s t r i n g name=” p r e f c h a t l a b e l ”>Chat Serv ice </s t r i ng>

14 <s t r i n g name=” p r e f l o c a l i z a t i o n l a b e l ”>Loca l i z a t i on </

s t r i ng>

15 <s t r i n g name=”pre f emergency l abe l ”>Enter Password</s t r i ng

>

16

17 </re source s>

A.4 AndroidManifest.xml

This is the manifest file for the whole application developed in thesis. It includes

different permissions like CALL PHONE, BLUETOOTH, VIBRATE ...etc which is

used by the application. Along with permissions, classes/java files needed for the

application are also mentioned in it.


2 <mani fe s t xmlns : android=”http :// schemas . android . com/apk/ r e s /

android ”

3 package=”com . master . t h e s i s ”

4 android : vers ionCode=”1 ”

5 android : versionName=”1 .0 ” >

6



7 <uses−sdk android : minSdkVersion=”7 ” />

8 <uses−permis s ion

9 android : name=”android . permis s ion .INTERNET” />

10

11 <a p p l i c a t i o n

12 android : i con=”@drawable/ i c l a u n c h e r ”

13 android : l a b e l=”@str ing /app name ” >

14

15 <uses−l i b r a r y android : name=”com . goog l e . android . maps”

/>

16

17 <a c t i v i t y

18 android : name=” . Entery ”


20 <in tent− f i l t e r >

21 <ac t i on android : name=”android . i n t e n t . a c t i on .

MAIN” />

22

23 <category android : name=”android . i n t e n t .

category .LAUNCHER” />

24 </intent− f i l t e r >

25 </a c t i v i t y >

26 <a c t i v i t y android : name=” . Maste r Thes i sAct iv i ty ”


28 </a c t i v i t y >

29 <a c t i v i t y android : name=” . Maps newActivity ”

30 android : l a b e l=”@str ing / l o c a l i z a t i o n l a b e l ” >

31 </a c t i v i t y >

32 <a c t i v i t y android : name=” . ActivityHome ”

33 android : l a b e l=”@str ing / c h a t l a b e l ” >

34 </a c t i v i t y >

35 <a c t i v i t y android : name=” . Emergency ”

36 android : l a b e l=”@str ing / emergency labe l ” >

37 </a c t i v i t y >

38 <a c t i v i t y android : name=” . P r e f e r e n c e s A c t i v i t y ”

39 android : l a b e l=”@str ing / p r e f e r e n c e s l a b e l ” >



40 </a c t i v i t y >

41 <a c t i v i t y android : name=” . Pre fe rences Chat ”

42 android : l a b e l=”@str ing / p r e f e r e n c e s l a b e l ” >

43 </a c t i v i t y >

44 <a c t i v i t y android : name=” . P r e f e r e n c e s L o c a l i z a t i o n ”

45 android : l a b e l=”@str ing / p r e f l o c a l i z a t i o n l a b e l ” >

46 </a c t i v i t y >

47 <a c t i v i t y android : name=” . Bluetooth main ”

48 >

49 </a c t i v i t y >

50 <a c t i v i t y android : name=” . SendingdataAct iv i ty ”

51 >

52 </a c t i v i t y >

53 <a c t i v i t y android : name=” . Send ingdata s e rve rAct iv i ty ”

54 >

55 </a c t i v i t y >

56

57 </app l i c a t i on>

58


60 android : name=”android . permis s ion .INTERNET” />


62 android : name=”android . permis s ion .ACCESS FINE LOCATION”

/>


64 android : name=”android . permis s ion .

ACCESS COARSE LOCATION” />


66 android : name=”android . permis s ion .VIBRATE” />

67 <uses−permis s ion android : name=”android . permis s ion .

CALL PHONE” />


READ PHONE STATE” />


BLUETOOTH” />




BLUETOOTH ADMIN” />

71

72

73 </mani fest>


Literaturverzeichnis 63

Bibliography

[AD09a] Android Developers, w.A.: Bluetooth | Android Developers. http:

//developer.android.com/guide/topics/wireless/bluetooth.html,

2009

[AD09b] Android Developers, w.A.: Canvas | Android Developers. http:

//developer.android.com/reference/android/graphics/Canvas.html,

2009

[AD09c] Android Developers, w.A.: Handler | Android Developers. http://

developer.android.com/reference/android/os/Handler.html, 2009

[AD09d] Android Developers, w.A.: Runnable | Android Developers. http:

//developer.android.com/reference/java/lang/Runnable.html, 2009

[AD09e] Android Developers, w.A.: System Requirements | Android Developers.

http://developer.android.com/sdk/requirements.html, 2009

[AD09f] Android Developers, w.A.: Thread | Android Developers. http://

developer.android.com/reference/java/lang/Thread.html, 2009

[And09a] Android, w.A.: Android - Developers. http://www.android.com/

developers/, 2009

[And09b] Android, w.A.: What is Android? http://developer.android.com/

guide/basics/what-is-android.html, 2009

[cap02] capitalware, w.A.: Message Oriented Middleware and MQseries. http:

//www.capitalware.biz/dl/docs/MQOverview.pdf, 2002

[CCP11] Cloud Computing Patterns, w.A.: Message Oriented Middleware

Cloud Computing Patterns. http://cloudcomputingpatterns.org/

?page_id=191, 2011


http://developer.android.com/guide/topics/wireless/bluetooth.html

http://developer.android.com/guide/topics/wireless/bluetooth.html

http://developer.android.com/reference/android/graphics/Canvas.html

http://developer.android.com/reference/android/graphics/Canvas.html

http://developer.android.com/reference/android/os/Handler.html

http://developer.android.com/reference/android/os/Handler.html

http://developer.android.com/reference/java/lang/Runnable.html

http://developer.android.com/reference/java/lang/Runnable.html

http://developer.android.com/sdk/requirements.html

http://developer.android.com/reference/java/lang/Thread.html

http://developer.android.com/reference/java/lang/Thread.html

http://www.android.com/developers/

http://www.android.com/developers/

http://developer.android.com/guide/basics/what-is-android.html

http://developer.android.com/guide/basics/what-is-android.html

http://www.capitalware.biz/dl/docs/MQOverview.pdf

http://www.capitalware.biz/dl/docs/MQOverview.pdf

http://cloudcomputingpatterns.org/?page_id=191

http://cloudcomputingpatterns.org/?page_id=191

Literaturverzeichnis 64

[Erl99] Erlang, w.A.: What is Erlang. http://developer.android.com/sdk/

requirements.html, 1999

[HT00] Haas, Zygmunt J. ; Tabrizi, Siamak: ON SOME CHALLENGES AND

DESIGN CHOICES IN AD-HOC COMMUNICATIONS. (2000)

[MJ97] Michal Jasinski, Rafal L.: QBase - Software Development

Plan 1.3. http://www.cs.put.poznan.pl/mjasinski/QBase/docs/

qbase-sdp-1.3.html, 1997

[MT99] Moval Type, w.A.: Calculate distance, bearing and more between

Latitude/Longitude points. http://www.movable-type.co.uk/scripts/

latlong.html, 1999

[SS08] Spring Source, w.A.: Understanding AMQP, the protocol

used by RabbitMQ. http://blog.springsource.org/2010/06/14/

understanding-amqp-the-protocol-used-by-rabbitmq/, 2008

[tec11] techreuters, w.A.: Android Platform: Definition

of Smart Phones. http://techreuters.com/2011/03/

android-platform-definition-of-smartphones/, 2011

[Wik02] Wikipedia, w.A.: Message-Oriented Middleware. http://en.wikipedia.

org/wiki/Message-oriented_middleware, 2002




http://www.cs.put.poznan.pl/mjasinski/QBase/docs/qbase-sdp-1.3.html

http://www.cs.put.poznan.pl/mjasinski/QBase/docs/qbase-sdp-1.3.html

http://www.movable-type.co.uk/scripts/latlong.html

http://www.movable-type.co.uk/scripts/latlong.html

http://blog.springsource.org/2010/06/14/understanding-amqp-the-protocol-used-by-rabbitmq/

http://blog.springsource.org/2010/06/14/understanding-amqp-the-protocol-used-by-rabbitmq/

http://techreuters.com/2011/03/android-platform-definition-of-smartphones/

http://techreuters.com/2011/03/android-platform-definition-of-smartphones/

http://en.wikipedia.org/wiki/Message-oriented_middleware

http://en.wikipedia.org/wiki/Message-oriented_middleware

List of Figures 65

List of Figures

1.1 Market Share of Android.[tec11] . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Waterfall Model [MJ97] . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 A combination of iterative and icremental model, and agile model . . . 13

3.1 Message-Oriented Middleware.[CCP11] . . . . . . . . . . . . . . . . . . 17

4.1 Adanced Message Queuing Protocol.[SS08] . . . . . . . . . . . . . . . . 20

6.1 Screen shot while installing Google API. . . . . . . . . . . . . . . . . . 27

7.1 The Alert dialog that appears when the applicaton starts. . . . . . . . 29

7.2 The password interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.3 The Buttons interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8.1 Chat Application using AMQP. . . . . . . . . . . . . . . . . . . . . . . 35

9.1 User Location: User near Haus I in the campus of TU-Ilmenau. . . . . 38

10.1 Call snapshot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

10.2 Make another call? option. . . . . . . . . . . . . . . . . . . . . . . . . . 42

11.1 Preferences main page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

11.2 Preferences for chat application. . . . . . . . . . . . . . . . . . . . . . . 44

11.3 Preferences for fence area management. . . . . . . . . . . . . . . . . . . 45

12.1 Image received via bluetooth for Ad-hoc communication. . . . . . . . . 49

13.1 Diagram representing the whole thesis . . . . . . . . . . . . . . . . . . 50


List of Abbreviations 66

List of Abbreviations

ADT . . . . . . . . . . . . . . . Android Development Tools

AMQP . . . . . . . . . . . . . Advanced Message Queuing Protocol

API . . . . . . . . . . . . . . . . Application Programming Interface

GPS . . . . . . . . . . . . . . . Global Positioning System

GSM . . . . . . . . . . . . . . . Global System for Mobile communications

HDP . . . . . . . . . . . . . . . Health Device Profile

JDK . . . . . . . . . . . . . . . Java Development Kit

JMS . . . . . . . . . . . . . . . Java Messaging Service

MOM . . . . . . . . . . . . . . Message-Oriented Middleware

MSMQ . . . . . . . . . . . . . Microsoft Message Queuing

OS . . . . . . . . . . . . . . . . . Operating System

OTP . . . . . . . . . . . . . . . Open Telecom Platform

PAN . . . . . . . . . . . . . . . Personal Area Network

PC . . . . . . . . . . . . . . . . . Personal Computer

SDE . . . . . . . . . . . . . . . Software Development Environment

SDK . . . . . . . . . . . . . . . Software Development Kit

SDLC . . . . . . . . . . . . . . Software Development Life Cycle

UUID . . . . . . . . . . . . . . Universally Unique Identifier

WiFi . . . . . . . . . . . . . . . Wireless Fidelity

WLAN . . . . . . . . . . . . . Wireless Local Area Network

XP . . . . . . . . . . . . . . . . . Extreme Programming


Conclusion of the Master Thesis 67

Conclusion of the Master Thesis

1. MOM can be used for an assistance system.

2. MOM can be implemented in Android. The AMQP commands are programmed

using threads and ”AsyncTasks”.

3. Android is capable of Ad-hoc communication in bluetooth. An image is trans-

fered to another mobile via the bluetooth.

4. Multiple cascaded calls are possible, for an assistance system. An option is

provided after every call, to make another call.

5. Chat Application can be developed using MOM in Android, where group chat is

also possible.

6. User can be localized with the help of GPS.

7. Fence area can be managed by increasing or decreasing the radius.

8. Agile, and iterative and incremental model can be considered suitable for devel-

oping such applications.

Ilmenau, den 10. 07. 2012 Muhammad Kamran Afridi


Erklarung 68

Erklarung

Hiermit erklure ich, dass ich diese Arbeit selbstandig durchgefuhrt und abgefasst

habe. Quellen, Literatur und Hilfsmittel, die von mir benutzt wurden, sind als solche

gekennzeichnet.

Ilmenau, den 15. 07. 2012 Muhammad Kamran Afridi


ilmenau university of technology faculty of electrical...

Documents