Ilmenau University of Technology Faculty of Electrical

Transcription

Ilmenau University of Technology
Faculty of Electrical Engineering and Information Technology
Master Thesis
Assistance System Service Development using a
Message-Oriented Middleware
Submitted by:
Muhammad Kamran Afridi
Submitted on:
15. 07. 2012
Born on:
Course of Study:
Department of thesis:
Responsible Professor:
Supervisor:
Master of Science in Communications and Signal Processing
Communication Networks
Prof. Dr. rer. nat. Jochen Seitz
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 für ein Assistenzsystem, das eine Message-Oriented Middleware (MOM) verwendet, entwickelt werden
können. MOM wird dabei aufgrund seiner Asynchronität und der Möglichkeit der
Wahl des Kommunikationswegs sowie der Transformation als Programmiergrundlage
verwendet. Für die Kommunikation wurde das Advanced Message Queuing Protocol
(AMQP) ausgewählt, weil dieses eine vollständige Interoperabilität bietet. MAMMAS
AMQP erweist sich hierbei als erfolgreicher Kandidat für die Realisierung des Assistenzsystems als Anwendung für das Betriebssystem Android.
Es werden verschiedene Software-Entwicklungsprozesse und -modelle (wie das Wasserfallmodell, 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 Flexibilität und Eignung für kleine Projekte
nach dem agilen, dem inkrementellen und dem iterativen Modell entwickelt.
Um die Fähigkeit von Android zur Ad-hoc-Kommunikation zu testen, wurde ein
Bildtransfer über Bluetooth realisiert.
Darüber hinaus wurden Android-Anwendungskomponenten für folgende Anwendungsfälle entwickelt: Chat, Benutzer-Lokalisierung, Benutzermonitoring, Notruf und Bluetooth”=Datenübertragung.
Die Arbeit kann in zwei logische Teile gegliedert werden. Der erste Teil behandelt das
für 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 können, sodass am Ende daraus Schlussfolgerungen abgeleitet
werden können.
Alle Anwendungskomponenten wurden in eine einzigen Anwendung mit einer konsistenten Benutzeroberfläche integriert, die über einen “Preferences”-Menüpunkt verfügt
und durch ein Passwort geschützt 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 Waterfall 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 bluetooth.
Android applications for the following are developed: Chat Application, User Localization, 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 Introduction
1.1 Motivation . . . . .
1.2 Problem Statement
1.3 Goal of the thesis .
1.4 Thesis Task List . .
1.5 Structure . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Software Development Process
2.1 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Implementation and Testing . . . . . . . . . . . . . .
2.1.4 Documentation . . . . . . . . . . . . . . . . . . . . .
2.1.5 Deployment . . . . . . . . . . . . . . . . . . . . . . .
2.1.6 Training and Support . . . . . . . . . . . . . . . . . .
2.1.7 Maintenance . . . . . . . . . . . . . . . . . . . . . . .
2.2 Software Development Models . . . . . . . . . . . . . . . . .
2.2.1 Waterfall model . . . . . . . . . . . . . . . . . . . . .
2.2.2 Spiral Model . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Iterative and Incremental Model . . . . . . . . . . . .
2.2.4 Agile Model . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 Code and Fix Model . . . . . . . . . . . . . . . . . .
2.3 Software Development Model and Process for Master Thesis
2.3.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Software Development Process . . . . . . . . . . . . .
2.3.2.1 Requirements: . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
4
4
4
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
8
8
8
8
9
9
10
10
11
11
11
11
12
14
Master Thesis, Muhammad Kamran Afridi
Contents
ii
2.3.2.2
2.3.2.3
2.3.2.4
2.3.2.5
Planning: . . . . . . . . . . .
Implementation and Testing:
Documentation: . . . . . . . .
Deployment: . . . . . . . . .
3 Message-Oriented Middleware
3.1 Introduction . . . . . . . . . . . . . . .
3.2 MOM Advantages and Concepts . . . .
3.2.1 Message Broker . . . . . . . . .
3.2.2 Client . . . . . . . . . . . . . .
3.2.3 Message Structure . . . . . . .
3.3 MOM proctocols and Implementations
4 Advanced Message Queuing Protocol
4.1 Introduction . . . . . . . . . . . . .
4.2 Main Components . . . . . . . . .
4.2.1 Queues . . . . . . . . . . . .
4.2.2 Exchanges . . . . . . . . . .
4.2.2.1 Direct Exchange: .
4.2.2.2 Fanout Exchange:
4.2.2.3 Topic Exchange: .
4.2.2.4 Header Exchange:
4.2.3 Bindings . . . . . . . . . . .
4.3 RabbitMQ . . . . . . . . . . . . . .
5 Ad-hoc in Android
5.1 WiFi . . . . . . . . . . . . . . . .
5.2 Bluetooth . . . . . . . . . . . . .
5.2.1 Initial Setup: . . . . . . .
5.2.2 Establishing a Connection:
5.2.3 Data Transfer: . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
15
15
15
.
.
.
.
.
.
16
16
16
17
17
17
17
.
.
.
.
.
.
.
.
.
.
19
19
19
19
20
20
21
21
21
21
21
.
.
.
.
.
22
22
22
23
23
23
II Implementation
24
6 Prerequisites
6.1 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 JDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
25
26
Contents
6.3
6.4
6.5
6.6
6.7
Eclipse . . . . . .
ADT . . . . . . .
Erlang . . . . . .
RabbitMQ Server
Google API . . .
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
26
27
27
7 Initial Interface
7.1 Password Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Buttons Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
28
29
8 Chat Application
8.1 Pre-requisites . . . . .
8.2 RabbitMQ Background
8.2.1 Publishing . . .
8.2.2 Consuming . .
8.3 RabbitMQ on Android
.
.
.
.
.
32
32
32
32
33
34
.
.
.
.
.
.
.
36
36
37
37
39
39
40
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9 User localization and fence area
9.1 Latitude and Longitude . . .
9.2 User Location and Fence Area
9.3 Fence Area Calculation . . . .
9.4 Fence Area Management . . .
9.4.1 Sending a Message to a
9.4.2 Toast . . . . . . . . . .
9.4.3 Vibration . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . .
. . . . . .
. . . . . .
. . . . . .
server via
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
MOM
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10 Emergency Calls
41
11 Preferences
11.1 Preferences for Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Preferences for Fence Area Management . . . . . . . . . . . . . . . . .
43
44
45
12 Android Ad-hoc: Bluetooth
12.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
46
47
13 The Big Picture
50
14 Conclusion
52
Contents
iv
15 Future Directions
53
A Android Application Development - Graphical User Interface
A.1 Master ThesisActivity.java . . . . . . . . . . . . . . . . . .
A.2 main.xml . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 string.xml . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4 AndroidManifest.xml . . . . . . . . . . . . . . . . . . . . .
55
55
57
59
59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Bibliography
63
List of Figures
65
List of Abbreviations
66
Conclusion of the Master Thesis
67
Erklärung
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 operating 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 architecture. MOM provides scalability to the applications which span over different systems
and protocols. Message-Oriented Middleware offers message transformation across different 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 messages 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 developers 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 services 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 assistance 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
Chapter
Chapter
Chapter
Chapter
12.
13.
14.
15.
6
Android Ad-hoc: Bluetooth
The Big Picture
Conclusion
Future Directions
7
Software Development Process is also known as Software Development Life Cycle
(SDLC). It is the structure which is followed when developing new softwares or applications. 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 development 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 ambiguous but experienced software engineers can sort out the confusions and ambiguities of
the software’s end results.
8
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.
9
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)
10
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 riskanalysis throughout the development process at regular stages. The phases are categorized 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.
11
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.
12
• 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, implement 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.
13
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.
14
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 development: 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 application 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.
15
• 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.
16
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 ”Middleware 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 asynchronous. 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, transforming 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
17
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.
18
JMS can send and receive messages across MOM systems. MSMQ (Microsoft Messaging 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 implementations are interoperable. AMQP is defined to provide flexible routing, including common messaging paradigms like point-to-point, fanout, publish/subscribe, and
request-response. It also supports transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support.
Java applications that use AMQP are typically written in Java JMS. Other implementations provide APIs for C++, PHP, Python, Ruby, and other languages.” - [Wik02].
19
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
20
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.
21
4.2.2.2 Fanout Exchange:
Fanout exchange forwards the messages to the all queues within an exchange irrespective 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/).
5 Ad-hoc in Android
22
5 Ad-hoc in Android
Ad-hoc is the ability of communicating with users with out the existence of Infrastructure. [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 distances. 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 Ad-hoc in Android
23
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 ”BluetoothServerSocket” class and when the connection is established it will transfer the connection to
the ”BluetoothSocket”. Whenever the connection is established the ”BluetoothServerSocket” 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 ”BluetoothSocket”. 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 differentiates 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 ”OutputStream” 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 development 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 applications 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 portion 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. Erlang’s windows binary file has to be installed from http://www.erlang.org/download.
html before using RabbitMQ in Eclipse for Android.
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.
7 Initial Interface
28
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 features 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
2
3
A l e r t D i a l o g . B u i l d e r b u i l d e r = new A l e r t D i a l o g . B u i l d e r ( t h i s ) ;
b u i l d e r . s e t M e s s a g e ( ” . . . ”) ;
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
7 Initial Interface
29
Figure 7.1: The Alert dialog that appears when the applicaton starts.
correct password. This password interface is shown in figure 7.2.
1
2
3
4
5
6
7
name = ( EditText ) e t v 1 . getText ( ) . t o S t r i n g ( ) ;
i f ( name . e q u a l s ( password ) )
{
I n t e n t a = new I n t e n t ( t h i s , xxx . c l a s s ) ;
startActivity (a) ;
finish () ;
}
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
7 Initial Interface
30
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
2
3
4
View hardwareButton = findViewById (R. i d . chatButton ) ;
hardwareButton . s e t O n C l i c k L i s t e n e r ( t h i s ) ;
case R. i d . chatButton :
I n t e n t a = new I n t e n t ( t h i s , ActivityHome . c l a s s
7 Initial Interface
31
);
5
startActivity (a) ;
8 Chat Application
32
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
C o nne c ti on Fa c to r y f a c t o r y = new C on ne c t io nFa c t or y ( ) ;
8 Chat Application
2
3
4
33
f a c t o r y . s e t H o s t ( ” l o c a l h o s t ”) ;
Connection c o n n e c t i o n = f a c t o r y . newConnection ( ) ;
Channel c h a n n e l = c o n n e c t i o n . c r e a t e C h a n n e l ( ) ; \ n e w l i n e
The channel needs to declare an exchange and actually publish a message.
1
2
3
4
c h a n n e l . e x c h a n g e D e c l a r e (EXCHANGE NAME, ”f a n o u t ”) ;
S t r i n g message = ”Hello World ! ” ;
c h a n n e l . b a s i c P u b l i s h (EXCHANGE NAME, ”” , n u l l , message . g e t B y t e s
() ) ;
System . out . p r i n t l n ( ” [ x ] Sent ’ ” + message + ” ’ ”) ; \ n e w l i n e
At last the channel and the connection needs to be closed
1
2
channel . c l o s e ( ) ;
connection . close () ;
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
2
3
4
5
6
7
8
9
S t r i n g queueName = c h a n n e l . q u e u e D e c l a r e ( ) . getQueue ( ) ;
c h a n n e l . queueBind ( queueName , EXCHANGE NAME, ””) ;
QueueingConsumer consumer = new QueueingConsumer ( c h a n n e l ) ;
c h a n n e l . basicConsume (QUEUE NAME, t r u e , consumer ) ;
while ( t r u e ) {
QueueingConsumer . D e l i v e r y d e l i v e r y = consumer .
nextDelivery () ;
S t r i n g message = new S t r i n g ( d e l i v e r y . getBody ( ) ) ;
System . out . p r i n t l n ( ” [ x ] Re c e ive d ’ ” + message + ” ’ ”) ;
}
8 Chat Application
34
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
h a n d l e r=new Handler ( ) ;
Runnable r=new Runnable ( )
{
p u b l i c void run ( )
{
...
}
};
h a n d l e r . p o s t D e l a y e d ( r , 1000) ;
Thread t h r e a d = new Thread ( )
{
@Override
p u b l i c void run ( ) {
try {
while ( t r u e ) {
RABBITMQ COMMANDS. . .
}
} catch ( InterruptedException e ) {
e . printStackTrace () ;
}
}
};
thread . s t a r t () ;
8 Chat Application
35
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
c h a n n e l . e x c h a n g e D e c l a r e (EXCHANGE NAME, ”f a n o u t ” , t r u e ) ;
Figure 8.1: Chat Application using AMQP.
36
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
2
3
4
5
6
LocationManager l o c a t i o n M a n a g e r = ( LocationManager )
g e t S y s t e m S e r v i c e ( Context . LOCATION SERVICE) ;
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 ( ) ;
c r i t e r i a . s e t A c c u r a c y ( C r i t e r i a .ACCURACY FINE) ;
provider = locationManager . getBestProvider ( c r i t e r i a , f a l s e ) ;
locationManager . requestLocationUpdates ( provider , 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 implemented. The latitude and longitude can be obtained from an ”LocationManager”
object which is passed in ”onLocationChanged()” method.
1
2
3
4
37
p u b l i c void onLocationChanged ( L o c a t i o n l o c a t i o n ) {
double l a t 1 = ( double ) ( l o c a t i o n . g e t L a t i t u d e
() ) ;
double l n g 1= ( double ) ( l o c a t i o n . g e t L o n g i t u d e ( )
);
}
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
2
canvas . drawBitmap (bmp , s c r e e n P t s . x , s c r e e n P t s . y−( f l o a t )
mPixRadius , l p 4 ) ;
canvas . d r a w C i r c l e ( mapView . getWidth ( ) / 2 , mapView . g e t H e i g h t ( )
/2−( f l o a t ) mPixRadius , ( f l o a t ) mPixRadius , l p 4 ) ;
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
38
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 implemented in the ”onLocationChanged()” method of the ”LocationManager” class as
following:
1
2
3
4
5
6
7
8
9
10
11
12
double d l a t = ( double ) l a t 2 − l a t 1 ;
double dlng = ( double ) l n g 2 − l n g 1 ;
d l a t = Math . toRadians ( d l a t ) ;
d ln g = Math . toRadians ( dlng ) ;
double d l a t 1 = Math . toRadians ( l a t 1 ) ;
double dlng1 = Math . toRadians ( l n g 1 ) ;
double d l a t 2 = Math . toRadians ( ( double ) l a t 2 ) ;
double dlng2 = Math . toRadians ( ( double ) l n g 2 ) ;
double a = Math . s i n ( d l a t / 2) ∗ Math . s i n ( d l a t / 2) +
Math . s i n ( dlng /2 ) ∗ Math . s i n ( dlng /2 ) ∗ Math . c o s ( d l a t 1 ) ∗
Math . c o s ( d l a t 2 ) ;
double c = 2 ∗ Math . atan2 ( Math . s q r t ( a ) , Math . s q r t (1−a ) ) ;
R e s u l t = 6371 ∗ c ;
39
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 implements the string in ”doInBackground()” method.
1
2
3
4
5
6
p u b l i c c l a s s Sender e x t e n d s AsyncTask<S t r i n g , Void , Void >{
@Override
p r o t e c t e d Void doInBackground ( S t r i n g . . . Message ) {
RabbitMQ Commands . . .
}
}
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
2
c h a n n e l . e x c h a n g e D e c l a r e (EXCHANGE NAME, ” d i r e c t ”) ;
c h a n n e l . b a s i c P u b l i s h (EXCHANGE NAME, ” r o u t i n g key ” , n u l l ,
message . g e t B y t e s ( ) ) ;
40
For consuming or subscribing to the messages from a ”direct” exchange the code will
be as following:
1
2
3
c h a n n e l . e x c h a n g e D e c l a r e (EXCHANGE NAME, ” d i r e c t ”) ;
S t r i n g queueName = c h a n n e l . q u e u e D e c l a r e ( ) . getQueue ( ) ;
c h a n n e l . queueBind ( queueName , EXCHANGE NAME, ” r o u t i n g 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 parameter to ”vibrate” method. The units of parameters passed to ”vibrate” method are
in milliseconds.
1
2
V i b r a t o r v = ( V i b r a t o r ) g e t S y s t e m S e r v i c e ( Context .
VIBRATOR SERVICE) ;
v . vibrate (1000) ;
10 Emergency Calls
41
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 )
g e t S y s t e m S e r v i c e ( Context .TELEPHONY SERVICE) ;
10 Emergency Calls
42
”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
2
I n t e n t c a l l I n t e n t 1 = new I n t e n t ( I n t e n t . ACTION CALL) ;
c a l l I n t e n t 1 . s etData ( Uri . p a r s e ( ” t e l : 9 9 9 8 8 8 1 1 1 ”) ) ;
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 management.
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, writeonly,...etc.
11 Preferences
1
44
S h a r e d P r e f e r e n c e s p r e f = g e t S h a r e d P r e f e r e n c e s (PREF NAME,
MODE PRIVATE) ;
Data from preferences can be read directly from preferences,
1
p r e f . read ( S t r i n g 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 ( ) . p u t S t r i n g ( ”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.
46
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 ”BLUETOOTH 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
2
47
BluetoothSocket btSocket = device .
createRfcommSocketToServiceRecord (MY UUID) ;
btSocket . connect ( ) ;
Once connected the client can send data by writing on the ”OutputStream” of the
”BluetoothSocket”.
1
outStream = b t S o c k e t . getOutputStream ( ) ;
As we are sending images we transform an image to bytes and send the image as
bytes.
1
2
3
4
Bitmap bm = BitmapFactory . d e c o de R e s o ur c e ( g e t R e s o u r c e s ( ) , R.
drawable . i c l a u n c h e r ) ;
ByteArrayOutputStream baos = new ByteArrayOutputStream ( ) ;
bm. compress ( Bitmap . CompressFormat . JPEG, 1 0 0 , baos ) ;
byte [ ] b = baos . toByteArray ( ) ;
and then writing to bytes to ”OutputStream” when a button is clicked.
1
outStream . w r 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
B l u e t o o t h S e r v e r S o c k e t Tmp = mBluetoothAdapter .
listenUsingRfcommWithServiceRecord ( ”B l u e t o o t h ” , MY UUID) ;
When bluetooth is listening for a channel through ”BluetoothServerSocket” we can
transfer the channel to ”BluetoothSocket”, for receiving that data.
1
B l u e t o o t h S o c k e t b t s o c k e t = Tmp. a c c e p t ( ) ;
48
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
2
3
4
5
6
7
8
9
10
11
12
13
i f ( byteNo != −1) {
// e n s u r e DATAMAXSIZE Byte i s read .
int byteNo2 = byteNo ;
int b u f f e r S i z e = 2 6 9 1 ;
while ( byteNo2 != b u f f e r S i z e ) {
b u f f e r S i z e = b u f f e r S i z e − byteNo2 ;
byteNo2 = mmInStream . read ( b u f f e r , byteNo , b u f f e r S i z e )
;
i f ( byteNo2 == −1){
break ;
}
byteNo = byteNo+byteNo2 ;
}
}
At last we will close the ”BluetoothServerSocket” if there are no more connections
to make.
1
bluetoothServerSocket . close () ;
We need to take care of bufferSize it should equal the length of the bytes being sent
by the client.
49
Figure 12.1: Image received via bluetooth for Ad-hoc communication.
13 The Big Picture
50
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 connected 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 management application which is connected to ”MOM”. When the user moves out of the circle
13 The Big Picture
51
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.
53
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
55
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 Android 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
4
5
6
7
import
import
import
import
import
a n d r o i d . app . A c t i v i t y ;
android . content . Intent ;
a n d r o i d . os . Bundle ;
a n d r o i d . view . View ;
a n d r o i d . view . View . O n C l i c k L i s t e n e r ;
8
9
10
11
12
13
p u b l i c c l a s s M a s t e r T h e s i s A c t i v i t y e x t e n d s A c t i v i t y implements
OnClickListener {
/∗ ∗ C a l l e d when t h e a c t i v i t y i s f i r s t c r e a t e d . ∗/
S t r i n g name ;
@Override
p u b l i c void onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) {
56
s u p e r . onCreate ( s a v e d I n s t a n c e S t a t e ) ;
setContentView (R. l a y o u t . main ) ;
14
15
16
// S e t up c l i c k l i s t e n e r s f o r a l l t h e b u t t o n s
View hardwareButton = findViewById (R. i d .
chat button ) ;
hardwareButton . s e t O n C l i c k L i s t e n e r ( t h i s ) ;
17
18
19
20
View systemButton = findViewById (R. i d .
localization button ) ;
systemButton . s e t O n C l i c k L i s t e n e r ( t h i s ) ;
21
22
23
View emergencyButton = findViewById (R. i d .
emergency button ) ;
emergencyButton . s e t O n C l i c k L i s t e n e r ( t h i s ) ;
24
25
26
View p r e f e r e n c e B u t t o n = findViewById (R. i d .
preferences button ) ;
preferenceButton . setOnClickListener ( this ) ;
27
28
29
View b l u e t o o t h B u t t o n = findViewById (R. i d .
bluetooth button ) ;
bluetoothButton . setOnClickListener ( t h i s ) ;
30
31
32
33
}
34
p u b l i c void o n C l i c k ( View v ) {
switch ( v . g e t I d ( ) ) {
case R. i d . c h a t b u t t o n :
I n t e n t a = new I n t e n t ( t h i s ,
ActivityHome . c l a s s ) ;
startActivity (a) ;
35
36
37
38
39
40
41
break ;
42
43
case R. i d . l o c a l i z a t i o n b u t t o n :
57
I n t e n t b = new I n t e n t ( t h i s ,
Maps newActivity . c l a s s ) ;
44
startActivity (b) ;
45
break ;
46
47
case R. i d . emergency button :
I n t e n t c = new I n t e n t ( t h i s , Emergency .
class ) ;
startActivity (c) ;
break ;
48
49
50
51
52
case R. i d . p r e f e r e n c e s b u t t o n :
I n t e n t d = new I n t e n t ( t h i s ,
PreferencesActivity . class ) ;
startActivity (d) ;
break ;
53
54
55
56
57
case R. i d . b l u e t o o t h b u t t o n :
I n t e n t e = new I n t e n t ( t h i s ,
Bluetooth main . c l a s s ) ;
startActivity (e) ;
break ;
58
59
60
61
62
}
63
}
64
65
}
A.2 main.xml
1
2
3
4
5
6
<?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”u t f −8”?>
<LinearLayout xmlns : a n d r o i d=”http : / / schemas . a n d r o i d . com/ apk /
r e s / android ”
a n d r o i d : l a y o u t w i d t h=” f i l l p a r e n t ”
a n d r o i d : l a y o u t h e i g h t=” f i l l p a r e n t ”
a n d r o i d : g r a v i t y=” c e n t e r v e r t i c a l ”
a n d r o i d : o r i e n t a t i o n=” v e r t i c a l ”
7
58
a n d r o i d : background=”#6495ED”>
8
9
10
11
12
<TextView
a n d r o i d : l a y o u t h e i g h t=”w r a p c o n t e n t ”
a n d r o i d : t e x t=”@ s t r i n g / h e l l o ” />
13
14
15
16
17
18
<Button
a n d r o i d : i d=”@+i d / c h a t b u t t o n ”
a n d r o i d : t e x t=”@ s t r i n g / c h a t l a b e l ” />
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<Button
a n d r o i d : i d=”@+i d / l o c a l i z a t i o n b u t t o n ”
a n d r o i d : t e x t=”@ s t r i n g / l o c a l i z a t i o n l a b e l ” />
<Button
a n d r o i d : i d=”@+i d / emergency button ”
a n d r o i d : t e x t=”@ s t r i n g / e m e r g e n c y l a b e l ” />
<Button
a n d r o i d : i d=”@+i d / b l u e t o o t h b u t t o n ”
a n d r o i d : t e x t=”Bluetooth−Adhoc ”
/>
36
37
38
39
40
41
<Button
a n d r o i d : i d=”@+i d / p r e f e r e n c e s b u t t o n ”
a n d r o i d : t e x t=”@ s t r i n g / p r e f e r e n c e s l a b e l ” />
42
43
59
</LinearLayout>
A.3 string.xml
1
2
3
<r e s o u r c e s >
4
5
6
7
8
9
10
11
12
13
14
15
<s t r i n g name=” h e l l o ”></s t r i n g >
<s t r i n g name=”app name ”>Master Thesis </ s t r i n g >
<s t r i n g name=”s a v e ”>Show C i r l c e </ s t r i n g >
<s t r i n g name=” c h a t l a b e l ”>Chat S e r v i c e </ s t r i n g >
<s t r i n g name=” l o c a l i z a t i o n l a b e l ”>L o c a l i z a t i o n </ s t r i n g >
<s t r i n g name=” p a s s w o r d l a b e l ”>Enter Password </ s t r i n g >
<s t r i n g name=” e m e r g e n c y l a b e l ”>Emergency C a l l </ s t r i n g >
<s t r i n g name=” p r e f e r e n c e s l a b e l ”>P r e f e r e n c e s </ s t r i n g >
<s t r i n g name=” p r e f c h a t l a b e l ”>Chat S e r v i c e </ s t r i n g >
<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 ”>L o c a l i z a t i o n </
string >
<s t r i n g name=” p r e f e m e r g e n c y l a b e l ”>Enter Password </ s t r i n g
>
16
17
</ r e s o u r c e 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.
1
2
3
4
5
<m a n i f e s t xmlns : a n d r o i d=”http : / / schemas . a n d r o i d . com/ apk / r e s /
android ”
package=”com . master . t h e s i s ”
a n d r o i d : v e r s i o n C o d e=”1 ”
a n d r o i d : versionName=” 1 . 0 ” >
6
7
8
9
60
<uses −sdk a n d r o i d : minSdkVersion=”7 ” />
<uses −p e r m i s s i o n
a n d r o i d : name=”a n d r o i d . p e r m i s s i o n .INTERNET” />
10
11
12
13
<a p p l i c a t i o n
a n d r o i d : i c o n=”@drawable / i c l a u n c h e r ”
a n d r o i d : l a b e l=”@ s t r i n g /app name ” >
14
15
<uses −l i b r a r y a n d r o i d : name=”com . g o o g l e . a n d r o i d . maps ”
/>
16
17
18
19
20
21
<a c t i v i t y
a n d r o i d : name=” . Entery ”
<i n t e n t −f i l t e r >
<a c t i o n a n d r o i d : name=”a n d r o i d . i n t e n t . a c t i o n .
MAIN” />
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<c a t e g o r y a n d r o i d : name=”a n d r o i d . i n t e n t .
c a t e g o r y .LAUNCHER” />
</ i n t e n t −f i l t e r >
</ a c t i v i t y >
< a c t i v i t y a n d r o i d : name=” . M a s t e r T h e s i s A c t i v i t y ”
< a c t i v i t y a n d r o i d : name=” . Maps newActivity ”
a n d r o i d : l a b e l=”@ s t r i n g / l o c a l i z a t i o n l a b e l ” >
< a c t i v i t y a n d r o i d : name=” . ActivityHome ”
a n d r o i d : l a b e l=”@ s t r i n g / c h a t l a b e l ” >
< a c t i v i t y a n d r o i d : name=” . Emergency ”
a n d r o i d : l a b e l=”@ s t r i n g / e m e r g e n c y l a b e l ” >
< a c t i v i t y a n d r o i d : name=” . P r e f e r e n c e s A c t i v i t y ”
a n d r o i d : l a b e l=”@ s t r i n g / p r e f e r e n c e s l a b e l ” >
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
61
< a c t i v i t y a n d r o i d : name=” . P r e f e r e n c e s C h a t ”
a n d r o i d : l a b e l=”@ s t r i n g / p r e f e r e n c e s l a b e l ” >
< a c t i v i t y a n d r o i d : name=” . P r e f e r e n c e s L o c a l i z a t i o n ”
a n d r o i d : l a b e l=”@ s t r i n g / p r e f l o c a l i z a t i o n l a b e l ” >
< a c t i v i t y a n d r o i d : name=” . Bluetooth main ”
>
< a c t i v i t y a n d r o i d : name=” . S e n d i n g d a t a A c t i v i t y ”
>
< a c t i v i t y a n d r o i d : name=” . S e n d i n g d a t a s e r v e r A c t i v i t y ”
>
56
57
</ a p p l i c a t i o n >
58
59
60
61
62
63
64
65
66
67
68
69
a n d r o i d : name=”a n d r o i d . p e r m i s s i o n .INTERNET” />
a n d r o i d : name=”a n d r o i d . p e r m i s s i o n . ACCESS FINE LOCATION”
/>
a n d r o i d : name=”a n d r o i d . p e r m i s s i o n .
ACCESS COARSE LOCATION” />
a n d r o i d : name=”a n d r o i d . p e r m i s s i o n .VIBRATE” />
<uses −p e r m i s s i o n a n d r o i d : name=”a n d r o i d . p e r m i s s i o n .
CALL PHONE” />
READ PHONE STATE” />
BLUETOOTH” />
70
62
BLUETOOTH ADMIN” />
71
72
73
</m a n i f e s t >
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.
developers/, 2009
http://www.android.com/
[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
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
List of Figures
65
List of Figures
1.1
Market Share of Android.[tec11] . . . . . . . . . . . . . . . . . . . . . .
3
2.1
2.2
2.3
Waterfall Model [MJ97] . . . . . . . . . . . . . . . . . . . . . . . . . .
Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A combination of iterative and icremental model, and agile model . . .
9
10
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
7.2
7.3
The Alert dialog that appears when the applicaton starts. . . . . . . .
The password interface. . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Buttons interface. . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
30
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Make another call? option. . . . . . . . . . . . . . . . . . . . . . . . . .
41
42
11.1 Preferences main page. . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Preferences for chat application. . . . . . . . . . . . . . . . . . . . . . .
11.3 Preferences for fence area management. . . . . . . . . . . . . . . . . . .
43
44
45
12.1 Image received via bluetooth for Ad-hoc communication. . . . . . . . .
49
13.1 Diagram representing the whole thesis . . . . . . . . . . . . . . . . . .
50
66
ADT . . . . . . . . . . . . . . .
AMQP . . . . . . . . . . . . .
API . . . . . . . . . . . . . . . .
GPS . . . . . . . . . . . . . . .
GSM . . . . . . . . . . . . . . .
HDP . . . . . . . . . . . . . . .
JDK . . . . . . . . . . . . . . .
JMS . . . . . . . . . . . . . . .
MOM . . . . . . . . . . . . . .
MSMQ . . . . . . . . . . . . .
OS . . . . . . . . . . . . . . . . .
OTP . . . . . . . . . . . . . . .
PAN . . . . . . . . . . . . . . .
PC . . . . . . . . . . . . . . . . .
SDE . . . . . . . . . . . . . . .
SDK . . . . . . . . . . . . . . .
SDLC . . . . . . . . . . . . . .
UUID . . . . . . . . . . . . . .
WiFi . . . . . . . . . . . . . . .
WLAN . . . . . . . . . . . . .
XP . . . . . . . . . . . . . . . . .
Android Development Tools
Advanced Message Queuing Protocol
Application Programming Interface
Global Positioning System
Global System for Mobile communications
Health Device Profile
Java Development Kit
Java Messaging Service
Message-Oriented Middleware
Microsoft Message Queuing
Operating System
Open Telecom Platform
Personal Area Network
Personal Computer
Software Development Environment
Software Development Kit
Software Development Life Cycle
Universally Unique Identifier
Wireless Fidelity
Wireless Local Area Network
Extreme Programming
67
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 transfered 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 developing such applications.
Ilmenau, den 10. 07. 2012
Erklärung
68
Erklärung
Hiermit erklüre ich, dass ich diese Arbeit selbständig durchgeführt und abgefasst
habe. Quellen, Literatur und Hilfsmittel, die von mir benutzt wurden, sind als solche
gekennzeichnet.
Ilmenau, den 15. 07. 2012

Ilmenau University of Technology Faculty of Electrical

Transcription

Similar documents

What is Dozuki? - Amazon Web Services

Able2Extract mobile Quick Start Guide

industrial revolution dbq

here - Northeastern NY PGA

J.P. Uniac mobile!

Greystripe signs ten more channel partners | Mobile Industry

SETUP EXCHANGE ON ANDROID DEVICES

1 Club FM - Get Mobile game

thesis statements! - Warren Wilson College

DK-40 See-through Wearable Display System