taxihere a system prototype for taxi servicing for android os · tool to be used in developing web...
TRANSCRIPT
Academic Year 2013/2014 Warsaw University of Technology
Faculty of Electronics and Information Technology
Electrical and Computer Engineering
BACHELOR OF SCIENCE THESIS
Grzegorz Wróbel
TaxiHere – a System Prototype for Taxi Servicing for
Android OS
Supervisor
Robert Bembenik, Ph.D.
Evaluation: ................................................
...................................................................
Signature of the Head of Examination Committee
1
Electrical and Computer Engineering
Date of Birth: 1990.11.06
Starting Date of Studies: 2009.10.01
Curriculum Vitae
I was born on 6th November 1990 in Lublin. After finishing the education in primary school
no. 27 in my hometown, I continued studying in Hetman Jan Zamoyski secondary school in
Lublin. In 2009 I got high-school certificate. In the same year I started full time BSc studies in Electrical and Computer Engineering at The Faculty of Electronics and Information
Technology at Warsaw University of Technology.
..........................................................
Signature of the Student
Bachelor of Science Examination
Examination was held on: ....................................................................................................... 20__
With the result: ..................................................................................................................................
Final Result of the Studies: ..............................................................................................................
Suggestions and Remarks of the B.Sc. Examination Committee: .................................................
.............................................................................................................................................................
.............................................................................................................................................................
2
SUMMARY
The thesis focuses on design and implementation of the system for exchanging information
between android devices. The system consists of two Android applications and server
providing interaction between them. The thesis presents review and analysis of tools available on the market and introduces an approach to implementation of the most important parts of
the system. The topic of the thesis is carried out using taxi service system as an example.
Keywords: Android, RESTful, Web Service, Taxi, mobile device
TaxiHere – Prototyp Systemu Obsługi Taksówek na Platformę Android.
Praca jest wstępem do systemów składających się z aplikacji na platformę Android oraz serwera zapewniającego usługi sieciowe dla urządzeń mobilnych. Celem pracy jest
zaprojektowanie i zaimplementowanie systemu składającego się z serwera i dwóch aplikacji
na Androida. Praca analizuje narzędzia dostępne na rynku oraz przedstawia metody implementacji najważniejszych części systemu. Temat pracy został zrealizowany na
przykładzie systemu obsługi taksówek.
Słowa kluczowe: Android, RESTful, usługa internetowa, system obsługi taksówek, urządzenie mobilne
3
TABLE OF CONTENTS
Dictionary.....................................................................................................................5
1. Introduction ..............................................................................................................6
1.1 Background ........................................................................................................6
1.2 Aim of the project ...............................................................................................6
1.3 Structure Of The Thesis .....................................................................................8
2. Technical Overview .................................................................................................9
2.1 Java ...................................................................................................................9
2.2 Android...............................................................................................................9
2.3 Web service .....................................................................................................12
2.3.1 SOAP ........................................................................................................13
2.3.2 RESTful Web Service ................................................................................14
2.4 Database..........................................................................................................16
2.5 ORM.................................................................................................................17
2.6 Apache Tomcat ................................................................................................18
2.7 Google Cloud Messaging .................................................................................19
2.9 Similar solutions ...............................................................................................20
3. Implementation ......................................................................................................21
3.1 Assumptions ....................................................................................................21
3.2 Requirements ...................................................................................................21
3.3 Configuration ....................................................................................................22
3.3.1 Server-side ................................................................................................22
3.3.2 Client .........................................................................................................25
3.4 Server ..............................................................................................................27
3.5 Android Application ..........................................................................................31
4
3.5.1 Login activity ..............................................................................................32
3.5.2 Customer application .................................................................................33
3.5.4 Common ground ........................................................................................35
3.6 Interaction within the system ............................................................................36
4. Testing ...................................................................................................................37
4.1 Android Client Application Testing ...................................................................37
4.2 Overall System Testing ....................................................................................39
5. Conclusions ...........................................................................................................41
5.1 Further Development .......................................................................................41
5.2 Discussion........................................................................................................41
References ................................................................................................................42
APPENDIX 1 - Content of the CD..............................................................................45
5
Dictionary
available online and not busy
user customer or taxi driver
Web server server providing Web services
system Android and Web server Android client user Android application (a driver or a
customer)
DB Database
ORM Object Relational Mapping
WS Web service
6
1. Introduction
1.1 Background
Rapid development of technology and the continuing miniaturization resulted in smartphones
becoming ubiquitous devices. Miniature devices fit in a pocket and are becoming more and more powerful. New smartphones on the market have hardware specification very close to
that of personal computers a few years ago. Popularization of such devices has entailed the
development of systems for mobile platforms.
In the thesis two issues are addressed. The first is software development for Android
operating system. Released in 2008 system created by Google Inc., almost immediately
became very popular and is now the leading platform (in terms of popularity) for modern
smartphones. Shared set of developer tools and extensive documentation make it easy to create software working on Android for developers not connected with smartphone industries
directly. Thanks to freely available API (Application Programming Interface), developer can
use many of ready features which facilitate, for example, the use of the built-in smartphone
equipment. Miniaturization has also another consequence, namely smartphones are typically equipped with multiple devices to extend their functionality, such as GPS receiver,
accelerometer, light sensor, etc.
The second issue covered in the thesis is the development of a Web service. Web services are self-contained, self-describing modular applications which can be published, located, and
invoked within the network. They provide services for a remote client applications such as
receiving taxi orders. As on the market there are many possible alternatives for developing
Web services, this thesis also concerns comparative analysis of available solutions and a selection of the best options for the system.
1.2 Aim of the project
The aim of this work is to design a system servicing orders for a taxi company with support for mobile devices working on Android OS. The designed system consists of:
a client mobile application for customers;
a mobile application for taxi drivers;
a server with a database.
The system gives a customer an opportunity to order a taxi using an application in his mobile device. The client-side application allows the customer to order a taxi to the specified
location. The customer can use the current GPS position or pinpoint a desired location on a
map.
7
On the other hand, the system also consists of an application which is used by a taxi driver.
This application informs about a new order and provides navigation to the customer .
The brain of the whole system is the last part mentioned at the beginning – the Web server with the database. It is responsible for storing information about orders and taxis as well as
additional information affecting them (availability, positions). This part of the system is also
receiving information about the order from the customer’s application, processing them by
matching attributes of the order to an available taxi car and sending information about a new order to the taxi driver. The system is able to handle unexpected situations as well (i.e. the
situation when there is no available taxi or taxi driver inactivity).
The described system has a lot of advantages. From the customer point of view, ordering a taxi is easier and definitely more practical than doing it in conventional way because all
necessary functions are in one place. Selection between various taxi companies is no longer
important to customers as it gives a wider range of choices to them. From taxi driver’s point
of view, the application gives an opportunity to get more clients, be more flexible (the whole process is automatized) and take orders in a more convenient way.
Figure 1 shows the general idea of the working system.
Client
Database
Web Server
Taxi Driver
sto
re /
qu
ery
for
dat
a
send an orderreceive an order
confirmationconfirmation
Figure 1 General system diagram
8
1.3 Structure Of The Thesis
The project is essentially divided into four parts. This thesis begins with a description of the
technology used in the system development, next it contains implementation of the system,
makes assumptions and states requirements for the system. Finally, it presents system testing and sums up the work that has been done. Below the contents of thesis chapters are
summarized.
Chapter two focuses on technical overview. It analyses technology and software solutions
which exist on the market and compares some of them.
Chapter three concentrates on the implementation of the whole system. It describes assumptions made to evaluate the project, system requirements and introduces interactions
between elements of the system along with their configuration. This chapter also deals with
detailed implementation of some elements within the system and the user interface.
Chapter four presents realized tests of the system and discusses the results.
Chapter five sums up every aspect of the thesis, presents critical evaluation of the outcomes
and provides information about possible future system extensions.
9
2. Technical Overview
This section presents theoretical knowledge about software solutions and technology which
can be used to develop the project. Presented solutions must be integrated and combine
together to create one, working system. Technical overview also analyses the presented
solutions and compares them in several cases. It is based on analysing literature related to the given topic such specialized books but also consultation and analysing similar systems.
2.1 Java
Java is an object-oriented programming language. It is the language used to create programs
that are compiled to the byte code (the code that can be analyzed and executed by the virtual machine). Its basic concepts were taken from Smalltalk programming language (virtual
machine and memory management concept) and C++ (large part of syntax and keywords).
Java code is independent of architecture, operating system and processor and is executed by a
virtual machine (Java Virtual Machine) that translates Java code into the code adapted to the particular operating system and processor infrastructure in a given device.
Java is composed of a series of classes defining objects of various types. All classes are
grouped into packages. Every package groups classes related to certain range of applications,
for example java.io contains input/output classes, java.util.prefs contains classes to handle preferences, etc. The hierarchy of classes reflects package names that are constructed similarly to file paths. Thus such naming system classes names are unique[10].
To sum up Java is widely used programming language in the world providing convenient and
secure developing of even very complicated, enterprise applications. It is the most appropriate tool to be used in developing web service and mobile application due to its machine-
independent property. All android applications are primarily written using Java language, that
is recommended by authors [4]. It is going to be the only one programming language used in
the project.
2.2 Android
Android is an open source operating system (OS) for mobile devices like mobile phones, smartphones, tablets etc. It is based on Linux Kernel. In 2007 there was first Android SDK
(Software Development Kit) released which contained developer tools such as debugger,
libraries, emulator, manual, exemplary projects, tutorials, FAQ etc., which are necessary to
develop applications on the Android platform. Android is the least restrictive OS for mobile devices when we are talking about hardware requirements. By the fact it is based on GNU
license so it can be easily adapted to the particular device.
10
Presented diagram (Figure 2) shows components of the Android OS.
Figure 2 Components of the Android OS [2]
The bottom layer is the Linux Kernel which is a middle layer between the hardware
and the rest of the software stack. It offers a core system services such as low-level
memory management, power management, hardware drivers, process management,
etc.
The next layer is a set of C/C++ libraries from simple ones like libc to libraries which
support usage of services like management of SQLite database, web browsing
(WebKit), creating 3D graphic, screen management, video and audio play back, etc. At the same layer as the libraries is the Android Runtime which mediates between
applications and system kernel and includes:
o Dalvik Virtual Machine (DVM) – this is one of the most crucial part of
Android OS. Instead of using the traditional Java Virtual Machine, Android uses its own virtual machine specially adapted for devices with limited
resources of memory and processor that provides working of many instances
on one device. Dalvik VM uses Linux Kernel to handle low-level
functionalities for example process and memory management. Before installing programs written in Java language are compiled into bytecode and
next transformed from .class format (that is compatible with JVM) into .hex
format being compatible with DVM. Prepared in that way executable files are
adapted to be ran on device with limited resources which means there can be smooth operation provided even for devices with very low hardware
parameters.
11
o Set of core libraries which provide handling most functions available in standard Java libraries and add new ones, specific for Android which is caused
by existence of DVM where most of standard Java libraries are not present.
The third layer is the Application Framework which contains classes used to create applications for Android and provides access to hardware, resources of applications
and management of the view. The programmer can also use many interfaces which
allow preforming typical tasks like access to address book, management of calendar or
synchronizing data over the Internet.
The top layer is an Applications one where all applications included in the system and
these which are installed from external sources using the same API libraries work on.
Applications working in this layer use classes shared by the framework from the lower layer.
It is also worth to mention that in systems with limited resources it is very difficu lt to provide
multitasking that is why Android manages application being ran in different way as it is in typical computer systems. Part of the process like application checking emails or providing
constant synchronization can work in background. However, applications having their own
window (ex. games) when are escaped by the user (ex. the incoming call arrive or another
application is ran) are paused (not closed) and put on a special stack remaining in the memory. If the system “decides” it is necessary to have more space it can close the
application from the memory. So it is important to know in which state the application is.
Android introduced a term “activity”. Application can have zero, one or many activities which
main aim is to interact with the user. An activity can have one out of several specified states at one time. Providing handling the activity through all the states properly is a crucial aspect of
developing a stable application. Figure 3 shows the lifecycle of an activity and stages it goes
through from its start until it ends.
Figure 3 Lifecycle of an activity in Android OS [6]
12
Handling the application in various states is resolved by overriding their call methods and executing the proper code. Presented pseudo code provides stopping GPS receiver when it is
not used (application is paused):
@Override
public void onPause() {
Gps = … ;
…
Gps.stop();
}
The opposite effect can be achieved by starting GPS receiver inside onResume() method.
To sum up Android is an operating system fully designed to create applications handling
interaction with a user and connection with external world (i.e. providing access to various
remote services). Using it and developing for Android OS is free and is based on open source licence. Developing for android gives a developer wide freedom in developing applications
using smartphone built-in hardware.
2.3 Web service
According to World Wide Web Consortium (W3C) - “Web service is software system designed to support interoperable machine-to-machine interaction over a network.” [26]. In
other words it is a software component, independent on hardware platform and
implementation which provides particular functionality (ex. exchange data). Web services (WS) are usually based on HTTP protocol and do not provide any GUI for the user. WS
mainly consists of a server and a client (that in this case is Android client). The server
provides defined services over the Web to clients.
13
Figure 4 shows the basic concept of communication between server and client within a Web Service.
Figure 4 Basic concept of communication between server and client within a Web Service [20]
Applications can coordinate series of message exchanges, using standardized Internet media
types. As the most common formats for sharing data between applications are: Extensible
Markup Language (XML) and JSON (JavaScript Object Notation). Both types characterizes the property that they are human-readable and hence intuitive and easy to use by the
developer. In the project JSON file is used because of and its simple notation and the fact that
it is widely used by range of Internet-related services like Google (that will be mention in
further work). Code 2 shows example of JSON file containing field “data” with two key-values pairs.
{ "data": {
"taxiId": "24",
"status": "online"
},
}
Code 1 Example of JSON file
Two usually used ways of creating Web services can be distinguished:
2.3.1 SOAP
Simple Object Access Protocol is a protocol for exchanging structured information in the
implementation of Web services in computer networks. It mainly uses HTTP protocol, but
there is no restriction about used protocol so other protocols for transferring data can be used as well. SOAP approach uses WSDL (Web Service Description Language) to make the
messages available over the Web. WSDL provides detailed description about available
services (operations, operation parameters and returning types to the client) and the way to
connect to a Web service. WSDL is specified in XML format and it is often hosted on the same machine as the service. However, the WSDL is optional and it is not required if the
14
clients have a knowledge about the way how to connect to the SOAP Web service and its available services.
WSDL files (one for each Web service) are stored in UDDI. UDDI is a standard defining a
scheme to publish and discover information about Web Services. It offers a repository for
service descriptions. Client (assumed to have no knowledge about WS server services and its location at the beginning) access to the UDDI which provides to him the WSDL file for
particular Web Service server. Having that file clients can access services for the server
directly connecting to it [1].
2.3.2 RESTful Web Service
REST (Representational State Transfer) is an architectural style for network based computer
applications. It contains a set of guidelines for exposing resources over the Web. It is just a
basic guideline for building a Web service rather than fixed set of rules. The term “REST” first time was used by Roy Fielding in his PhD dissertation (Roy T. Fielding 2000). The
concept REST came from the idea Fielding proposed:
”A software architecture is defined by a configuration of architectural elements—components, connectors, and data — constrained in their relationships in order to achieve desired set of
architectural properties.”
In other words the architecture style is defined by linking elements to each other according to proposed rules. Connectors are used by devices to access resources and transfer their
representation over the network. Connectors contain server and client’s libraries and cache
memory. Data elements are information transferred between components through the
connectors. Data elements are classified as resources and representations.
One limit existing within REST is a client-server model that forces a specified behaviour in
which the client always initiates a communication. That implies separation parts of the user
interface and data storage. Table 1 represents constraints, rules/features being a base of REST style architecture.
Feature Characteristic
Client-server model
Server is a place where data is stored and is separated from the client that plays the role of user interface. Thus independent development of each
side is possible.
Stateless Every client’s request is independent of all previous so it must contain
all data needed to be understood. Server does not store information about a context and session state is maintained on the client side.
Uniform
Interface
Introduces generalization of the interface between components to
simplify architecture and make interaction more predictable. Uniform
interface is obtained by identify resources, manipulation of resources by representation.
Layered System Between client and server intermediate nodes can be present like proxy
servers, bridges, firewalls. Table 1 Features of REST architecture
15
In REST architecture everything can be treated as a resource identified by Uniform Resource Identifier (URI). URI is a Web address of the resource and makes it available online. Each
resource should have at least one URI to represent it.
Each state of a resource is called representation. The most common format of representation is
XML and HTML. However, there can be many of representation formats used like JPG, PDF, JSON or even plain text.
Operations on resources are performed using HTTP methods for example GET which takes a
representation of the particular resource. There is also no restriction about the communication
protocol being used. Usually in the project representations are in the form of plain text and are requested over HTTP protocol.
The architecture of the server side can be presented in the following way: o URL – field to access Web services running at the server.
And following request methods to indicate the desired action to be performed on the identified resource:
o GET – all the methods of getting data from the server;
o POST – all the methods of adding details to the server;
o PUT – all the methods for updating the data at the server; o DELETE – all the methods for deleting the data from the server [24].
To sum up both solutions (SOAP and RESTful) Web services are suitable for the purpose of
the project and in both cases it would be possible to build fully working server-side of the taxi system.
However, since SOAP is a protocol, whereas REST is architecture it is no appropriate to
compare these two technologies in conventional way. Although there can be compared
performance of each Web service based on given particular solution, difficulty lever of their implementation and application.
In RESTful architecture approach each psychical object or abstract concept at which we can
refer is identified as a unique resource. That means each of them can be quickly accessed just
by a single request. It results in better navigability and less load for the server. Moreover due to stateless principle REST makes the system better scalable than SOAP. It gives the
opportunity that every single machine that is part of the system is able to receive any kind of
request from any of the clients and give a proper response.
SOAP approach is more difficult to implement, less efficient and is starting being replaced by REST, which is later and has a new, fresh approach of creating Web service. SOAP is better
for enterprise solutions, has wide support from applications developers and there are many
extending standards available. For the purpose of this project RESTful Web service will be
used due to the distributed nature of the system and ease of future expansion.
16
Figure 5 compares both web services showing differences in working principles.
Figure 5 .SOAP and RESTful cooperation [25]
2.4 Database
Database (DB) is a set of data recorded according to specified rules. Programs processing,
managing and storing various kind of data are called Database Management System (DBMS).
The thesis focus on its successor – Relational Database Management System (RDBMS), that
allows to specify relationship between tables using primary keys, foreign keys and indexes and hence to avoid redundancy in a database. Such solution provides better performance of
handling the database than in case of DBMS. There are many RDBMS solutions proposed by
developers. In this case I decided to compare three, most popular solutions available on the
market - MySQL, SQLite and Apache Derby relational database management system (RDBMS). Generally SQLite with compare to MySQL can be easily embedded in an
application and is easier to setup. However, it has lower performance and less scalability
features. Moreover SQLite does not officially support Object Relational Mapping (ORM),
that will be presented in further work. For enterprise, complex systems choice of MySQL is reasonable and often the only one. However, for MySQL it is required to purchase a
commercial license if a developer intends to distribute commercial application along with
integrated MySQL database [19]. Apache DB is an open source relational database
implemented entirely in Java, while MySQL is based on C/C++. Solution from Apache links together some features of SQLite (i.e. small size of the engine and ease of setting up) and
supporting of the ORM (by released, official drivers) [3]. Concept of the ORM is in next
topic.
17
In context of this project database will be used to contain information of clients, taxis and orders. Since the access time to the database is not a crucial factor and operation on database
are limited to the simple ones (i.e. store, load, delete of the single record) as well as provided
support in handling ORM , Apache DB will be used in the project.
2.5 ORM
In applications that requires storing a data in a database there are many ways to handle a
database. Handling a database can be implemented manually from the beginning or use
frameworks (ORM managers) that already exist that allow a developer to use a database in object oriented systems very easily. Such frameworks are based on Object-relational mapping
(ORM) technique. ORM allows storing object oriented structures inside relational databases
without low-level handling a database – connecting to DB, operating on relations, tables,
writing SQL inquiries, etc. Developer needs objects to be persistent. If there are changes made they must be preserved. Database automatically adapts to data model – reflection of
classes, objects attributes, relations between entities. Once defined relationships in a code
generates them in a DB [11]. ORM allows to develop the program which uses a database
without worrying about its type and going into the details of communications or references with the application. Whole logic and implemented references / usage of database remains the
same. It is achieved by using JDBC (Java DataBase Connectivity) driver, that is assigned to
the specific database version and allows to handle with [18].
One of such ORM library, well known and free is Hibernate. Hibernate is a framework which
allows to implement a simple and fast way to support storing data in the database, regardless
of the database system. Hibernate is an intermediate layer between the database system and
the application so-called persistence layer. It provides a translation, or the mapping of objects from the world of Java to relational databases. The structure of the mapping can be defined
using XML, in appropriate files or special Hibernate annotations in class file representing
single table in the database (that will be used in project implementation). An important
advantage of the Hibernate project is that it allows to increase the efficiency of data access layer by minimizing the number of queries (by caching). Figure 6 shows the corresponding
application layer - as we can see, Hibernate is an intermediary between the application and the
database.
18
Figure 6 Hibernate application layer [9]
To sum up Hibernate is a commonly used ORM designed for Java language. It has big support
from jBoss (the devision of the organization profits from a service-based business model) and
even amateur developers. It gives opportunity to easily manage taxi service system database by simple operation (reduces the amount of code that needs to be written) and gives intuitive
handling with data by mapping Java objects into database tables. Hibernate also allows for
potential changes of database to another one without losing logic of the whole application.
Hibernate will be part of the project application.
2.6 Apache Tomcat
Apache Tomcat is a web container developed by the Apache project. As container is a server application that enables Web applications in Java technologies. It is one of the most popular
Web containers. Tomcat is released under the Apache License 2.0 that permits the use of the
source code for both free software and proprietary software for commercial use [12].
To sum up, in the context of this project a server which provides Java Taxi Service System’s
Web server is required. Apache Tomcat will be used for this purpose.
19
2.7 Google Cloud Messaging
Solutions and assumptions proposed so far determines one way of server-to-Android
connectivity – the necessity of exchanging JSON files or plain text over HTTP protocol. It
involves the need for storing the IP address in a database for each Android device separately and updating it each time when IP changes. It is time and resource consuming operation.
Therefore, to improve performance and stability of the system concept of Google Cloud
Messaging (GCM) will be introduced and used in the system development.
GCM is a service created by Google Inc. in 2012 which helps developers to send data from
servers to Android devices. The service is free to use for sending lightweight message (up to
4KB) using JSON file or plain text. Google Cloud Messaging service introduces new element
existing between Android and server which provides queuing, storing (up to 100 messages for one receiver / device) and delivery of the message from 3-rd party application server to a
given endpoint when it is online. It does not provide any built-in user interface or other
handling for message data. GCM simply passes raw message data received straight to the
Android application, which has full control of the way of handling it. GCM requires devices running Android 2.2 version and higher (at least 8 API level1) and
installed Google Play Store application which is available on most of Android devices
nowadays. GCM uses an existing connection for Google services, which implies that there is
no longer additional custom Android Service working in the background on the device that influences on extending battery life.
The role of IP addresses is replaced by so called “register IDs” assigned by google when the
device connect to the Google services (usually when the Android OS is started). Concept of “register ID” allows the server to address message to many devices by single HTTP post
request containing JSON file to GCM service where messages are distributed to single target.
Summing up, Google Cloud Messaging is a free service which allows sending messages from server to Android devices without worrying about their connection type, online status etc.
GCM will be used by taxi web service to provide one-way connectivity to Android devices
(ex. notification about new order, confirmations, etc.).
1 API Level is an integer value that uniquely identifies the framework API revision offered by a
version of the Android platform [27]
20
2.9 Similar solutions
At the very beginning I compared two similar systems already existing on the market to catch
ideas of interesting features which could be used in the system, as well as to figure out their
weaknesses to be improved. Because of the fact that it is not possible to delve into internal architecture due to copyrights and “close nature” of presented solutions, all observations are
based on end-product applications available for public in Android Market2.
The first application “Get Taxi” is an international enterprise application for ordering tax using smartphone with Android created in 2010. It has a functionality of finding the nearest,
available taxi in the neighbourhood, tracking it, order a taxi for a place the client currently is,
call a driver, show map and present estimated, remaining time for the arrival of the taxi. The
application also offers possibility to pay for a taxi at the end of the journey using credit card. To use an application every client must have an account in the application service [22].
Slightly different approach is used in Polish application “Złap Taxi”. The application
appeared in 2012. Contrary to present description of the application about ordering taxi using GPS position, an application can present to the client the list of taxi companies in the given
city and provides possibility to make a call to the chosen one. There is also possible to plan a
route and obtain overall cost for each taxi company. [21]
As it is presented similar, already working applications exist on the market. One, presented as
first is a very advanced and complex system offering fast and convenient way to order a taxi.
The second one is a kind of online database for many taxi companies and allows to order a
taxi in conventional way. However, linking together some features from both presented application (i.e. advanced graphical user interface, tracking taxi in real time, ordering a taxi
for given position and non-cash payment from first solution with database of taxi companies
not supporting on-line ordering and proposing conventional voice ordering) may lead to
create new, innovative system needed on the market.
2 Digital distribution platform for applications for the Android operating system and an online
electronics and digital media store, operated by Google.
21
3. Implementation
The following chapter discuss implementation aspect of the taxi servicing system and presents
assumptions and requirements of the system operation. It will focus on important, key issues
for the system operation. As it was mentioned at the beginning the system consists of two
Android applications (making an order and the other one receiving the order) and a server that process the received requests. As the server and mobile applications are separate elements
from the developer point of view, each of them will be discussed in separate sections /
subsections. First section deals with general configuration of each part of the system, while
the next two sections present detailed implementation aspects of each system element.
3.1 Assumptions
To implement Taxi Servicing System it is necessary to make some assumptions on which
running application will be based. The assumptions concerns factors like hardware and
software limitations used to design the system. o Matching a taxi for a customer is performed by finding the nearest, available taxi;
o Both taxis and customers act on the area of a city – it influences a database structure,
which would have to be spatial if the area extends across the whole world. It would
significantly increase complexity of the database; o The environment in which the mobile devices work causes possibility of fast changes
between various network distributors (i.e. WIFIs, cell towers) what influences IP
addresses changing as well, therefore GCM will be used in server-to-client connectivity;
o When driver does not accept proposed order he becomes inactive for some period of time – that resolves problem of finding next available driver;
o To be able to use a system the user must log in to the system using login and password.
Login must be unique for each user (customers and taxi drivers);
o Login and password distinguish between uppercase and lowercase letters; o One application services both a customer and a taxi driver – the application provides
functionalities for each side separately according to used login;
o Driver cannot get more than one order proposition at the same time.
3.2 Requirements
Because of decision of application solutions discussed in the previous chapter we need to reckon with some limitations. Requirements of the client application for Android concerns
minimum Android API level 11 (at least 3.0.X Android version) and Google Play Store
application installed. For Android versions less than 4.0.4 it also require users to set up their
Google account on the device.
22
For server-side there is not strictly defined requirements. The server can work on every machine which has connection to the Internet and Java Runtime Environment installed.
Moreover, for the project development Google Play services library is used in order to use
GCM service.
3.3 Configuration
3.3.1 Server-side
To provide customers instant access to the system and continuous order processing server
must be running. For this purpose Apache Tomcat 7.0 Web server will be used. That gives the
system visibility from outside and the possibility to receive connections from other network
devices. For the purpose of this project there were made changes in URI address to the server containing in server.xml configuration file. Following line sets the root URI server path
address to “RESTfulWS”.
<Context docBase="RESTfulWS" path="/RESTfulWS" reloadable="true"
source="org.eclipse.jst.jee.server:RESTfulWS"/></Host>
Others configuration of the server remains default as it was proposed by creators.
Tomcat is only the base that provides Web service that have whole logic of the server part system. Web service running on the Tomcat in this case is RESTful Web service. It introduces
possibility to communicate a server with a user (i.e. client or taxi driver) application,
exchange data between them and process received data. Web service shares resources, where
each of them is represented by a unique URI. Each activity available to the client mobile application like login in, request for new taxi order etc. is assigned to the one specific
resource. When client application wants to perform an operation on a server it can access to
the given resource by sending GET or POST request with given argument that can be plain
text or any java object (JSON file). If required application also waits for replay from the server with form of any type that client can handle. Next task of the Web service is also
interaction with a remote database (sending queries to it, make changes, delete and save data).
Hibernate tool introduces the ability to easily interact with the Web service database using
object-relational mapping. It means that instead of low-level handling a database, simple operation on Java classes and SQL queries are used. Hibernate implemented on server side
must be properly configured to ensure correct functioning. Configuration of Hibernate is done
by a special configuration XML file (manifest). Code 2 shows a Hibernate configuration file
for the taxi service system.
23
1. <hibernate-configuration> 1 2. <session-factory> 2 3. <!-- Database connection settings --> 3 4. <property name="connection.driver_class">org.apache.derby.jdbc.ClientDriver</property> 4 5. <property 5
name="connection.url">jdbc:derby://localhost:1527/HibernateDB;create=true</property> 6 6. <property name="connection.username">user</property> 7 7. <property name="connection.password">password</property> 8 8. <property name="hibernate.default_schema">TAXISYSTEM</property> 9
10 9. <!-- JDBC connection pool (use the built-in) --> 11 10. <property name="connection.pool_size">1</property> 12
13 11. <!-- SQL dialect --> 14 12. <property name="dialect">org.hibernate.dialect.DerbyDialect</property> 15
16 13. <!-- Enable Hibernate's automatic session context management --> 17 14. <property name="current_session_context_class">thread</property> 18
19 15. <!-- Disable the second-level cache --> 20 16. <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property> 21
22 17. <!-- Echo all executed SQL to stdout --> 23 18. <property name="show_sql">true</property> 24
25 19. <property name="hbm2ddl.auto">update</property> 26
27 20. <mapping class="cov.taxi.system.databasehandle.Order"/> 28 21. <mapping class="cov.taxi.system.databasehandle.Client"/> 29 22. <mapping class="cov.taxi.system.databasehandle.Abandoned"/> 30
31 32
23. </session-factory> 33 24. </hibernate-configuration> 34
Code 2 hibernate.cfg.xml
Hibernate manifest (Code.2) defines following properties: o JDBC driver class (hibernate.cfg.xml: 4) is an official Derby driver included in
derbyclient.jar file delivered with Derby distribution. The JDBC driver allows
Hibernate connect to the database and implements the protocol for transferring the
query and result between client and database [13]; o JDBC URL (hibernate.cfg.xml:5) defines The JDBC URL to the external database
instance. In this case Derby server is available in local host on port 1527;
o The database username and password (hibernate.cfg.xml:6-7) that in this case are set
to “user” and “password” accordingly. It provides authentications and allows Hibernate to gain access to the database;
o default schema (hibernate.cfg.xml:8) that defines default schema for a database.
Having many schemas we can store different databases inside the Derby server.
However, for the taxi system there is only one database required and all its tables are stored in “TAXISYSTEM” schema;
o SQL dialect (hibernate.cfg.xml:12) is a database specific syntax, in this case it is
official Derby database dialect delivered with Derby distribution. Dialect allows to
communicate in a given type of database correctly; o Mapped classes (hibernate.cfg.xml:20-22) that stands for every class that will be used
by Hibernate and mapped into database tables. Database diagram with taking into
account the used classes will be presented in further part of this thesis.
24
Some property defined in configuration file was not discussed here because of their minor importance in understanding the operation of the system.
Except the interaction with the customer system must also possess a part storing information
about customers, taxis and orders. For this purpose independent database is used by the server. Solution for this situation is Apache Derby database standalone server that keeps
database for the whole system. As it has been already mentioned Hibernate is responsible for
the connection to the database. For the project the default configuration of the database server
proposed by Apache was used. Only login credentials have been set to “user” and “password” what prevents access to the database to unauthorized persons. The same login data was setup
for Hibernate configuration file (Code 2). To provide the proper functioning of the system and
the clear structure of the application a database presented in Figure 7 was used.
Order
PK orderId
longitude latitude isHandled taxiDriverId clientId
Client
PK,FK1 cielndId
regId clientType isOnline isBusy login password longitude latitudeFK1 orderId
Abandoned
PK id
orderId driverId
Figure 7 Physical schema of the database
As it is shown in schema (Figure 7) database has following tables:
o Order – contains information about new orders and orders being handled. Table
contains following fields:
o orderId (int) – uniquely identifies the order; o longitude (double) – longitude of place where taxi is ordered;
o latitude (double) – latitude of place where taxi is ordered;
o isHandled – defines if the given order has been handled (used only by web
service logic); o taxiDriverId – identifies particular taxi driver assigned for the given order;
o clientId – identifies particular client who made the order.
o Client –represents user (i.e. Taxi drivers and clients). In case of the Client element
describing the client some fields can be empty (==null). Table that contains following fields:
o clientId (int) – uniquely identifies the client;
o regId (String) – registration id of client device used by GCM;
o clientType (String) – specifies type of person [driver / customer]; o isOnline (Boolean) – determines if driver is online [used only for driver];
25
o isBusy (Boolean) – determines if client is available and can handle new order (used only by web service logic);
o Login (string) – identifies user login using to access to the system;
o Password – identifies user password using to access to the system;
o longitude - longitude of current taxi driver position [used only for driver]; o latitude - latitude of current taxi driver position[used only for driver];
o orderId (int) – identifies order the user is assigned to (used only by web service
logic).
o Abandoned – is a table consisting of registration IDs of drivers who are temporary inactive. It that contains following fields:
o Id – uniquely represents single entry;
o orderId - identifies order (used only by web server logic);
o driverId – identifies driver (used only by web server logic).
3.3.2 Client
The main task of a mobile application for the customer is to provide access to the system and the possibility to order taxi to the specified location. From the technical point of view,
developing mobile application for a client boils down to provide appropriate interface that
gives possibility to interact with application in the desired manner and ability to connect and
communicate with the remote Web service. This section deals with the general aspects of interaction with the Web service. Detailed discussion of the implementation and designing a
GUI will take place in the further section of this chapter.
Since the client mobile application is largely independent from the server, it must be able to
handle data received from the server using GCM and posting data directly to the server itself. Moreover the application needs to handle the GPS receiver in order to get position of the user.
First of all, due to Android security architecture an Android application by default can only
access a limited range of system resources. To provide Android application with the access to
protected parts of API (connection to the remote server and GPS module) appropriate permissions should be granted for it. All permissions granted to Android application are
defined in AndroidManifest.xml file which is placed in the root directory of the application
project [5].The manifest referring to permissions of client application is presented in Code 3.
26
<?xml version="1.0" encoding="utf-8"?> 1 <manifest xmlns:android="http://schemas.android.com/apk/res/android" 2 package="cov.android.client.conn" 3 android:versionCode="1" 4 android:versionName="1.0" > 5 6 <uses-sdk 7 android:minSdkVersion="11" 8 android:targetSdkVersion="17" /> 9 10 <uses-permission android:name="android.permission.INTERNET" /> 11 <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/> 12 <uses-permission android:name="android.permission.GET_ACCOUNTS" /> 13 <uses-permission android:name="android.permission.WAKE_LOCK" /> 14 <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" /> 15 16 <permission 17 android:name="com.example.gcm.permission.C2D_MESSAGE" 18 android:protectionLevel="signature" /> 19 20 <uses-permission android:name="com.example.gcm.permission.C2D_MESSAGE" /> 21 22 23 <application 24 android:icon="@drawable/ic_launcher" 25 android:label="@string/app_name" > 26 <activity 27 android:name="com.android.client.conn.LoginIn" 28 android:label="@string/title_activity_login_in" > 29 <intent-filter> 30 <action android:name="android.intent.action.MAIN" /> 31 <category android:name="android.intent.category.LAUNCHER" /> 32 </intent-filter> 33 </activity> 34 </application> 35 36 <receiver 37 android:name="cov.android.client.conn.GcmBroadcastReceiver" 38 android:exported="true" 39 android:permission="com.google.android.c2dm.permission.SEND" > 40 <intent-filter> 41 <!-- Receives the actual messages. --> 42 <action android:name="com.google.android.c2dm.intent.RECEIVE" /> 43 <category android:name="cov.android.client.conn" /> 44 </intent-filter> 45 </receiver> 46 47 <service android:name="cov.android.client.conn.GcmIntentService" /> 48 49 </manifest> 50
Code 3 AndroidManifest.xml
27
Three lines beginning with “<uses-permission” give the application permission to open
network sockets. In the context of the program it means that the taxi client application can
establish connection to the external Web service – taxi RESTful Web service.
Two next lines give the applications permissions to access precise location from location
sources such as GPS, cell towers, and Wi-Fi (ACCESS_FINE_LOCATION). Permission GET_ACCOUNTS uses an existing connection for Google services and is
required for Android devices uses version 3.0 and lower. Parameter WAKE_LOCK allows
application to keep processor from sleeping when it is necessary (i.e. processing received
notification). Finally, c2dm.permission.RECEIVE allows the application to register in GCM
service and receive notification from it. Presented AndroidManifest.xml file also
contains example LoginIn activity which in addition is a launcher seen by the user in his
mobile device. Every application activity, as well as, every receiver and background service
must be declared in the application manifest file. In the project the receiver ensures that
incoming GCM message will be received and passed to the service which handles it.
3.4 Server
Server-side implementation refers to the creation (implementation) of structures responsible for interacting with connected devices (taxi clients) i.e. receiving, processing and sending
information to the client, and the creation of structures (classes) reflecting server database
architecture used by Hibernate. With the latter, classes describing the database are normal Java classes having the name refer to a particular table in the database. Each table has private
attributes referring to the particular entries in the given database table and implemented both
getters and setters method for each attribute. As an example of such “database table class”
Abandoned.java class is presented in Code 4. @Entity public class Abandoned { private int Id; private int orderId; private int driverId; @Id @GeneratedValue public int getId() { return Id; } public void setId(int testId) { Id = testId; } public int getOrderId() { return orderId; } public void setOrderId(int orderId) { this.orderId = orderId; } public int getDriverId() { return driverId; } public void setDriverId(int driverId) { this.driverId = driverId; }
Code 4 Abandoned class
This class refers to the Abandoned table presented on the physical schema (figure 8). from
Chapter 3. An important part of the presented class is Hibernate annotations. Annotation is a
28
metadata governing transformation of data between the object-oriented model and the relational database model.
@Entity
The annotation tells the Hibernate that the following class is identified as a database table and
has to be mapped. Moreover, annotations to the column can be used by adding desired
annotation just before the declaration of attribute or before getter method of this attribute. This is an example of three annotations that defines clientID in Client table as an auto-
generated public key with specified column name. @Id
@GeneratedValue @Column(name="client_PK")
Annotations are also used to define relation between tables. In Client table there is one, one-to-one relationship with Order table. The annotation set for orderId variable is as follows: @OneToOne(cascade=CascadeType.ALL, fetch=FetchType.EAGER) @JoinColumn(name="preference_FK")
The first parameter (cascade type) defines types of operations which should be cascaded to all
associated entity. CascadeType.ALL requires all operations to be cascaded to dependent entity (i.e. update, insert, select and delete). The second parameter defines fetch type to eager
that means linked table fetches immediately when new Client is created. The second
annotation defines the name of the entry being a foreign key for Order inside Client table.
To provide services for Android application the Web service implements number of resources
each representing a service available from outside under one unique URI. Resources are
grouped into three Java class files:
o LoginResource.java – responsible for handling “log in” operation for android client.
Available under URI: “…/RESTfulWS/login”
o GPSOrderResource.java –consisting of two resources – the first one responsible for
making GPS order and the second one used to confirm or reject assigned order by the
driver. o DriverResource.java – responsible for handling driver state. It consists of three
separate resources.
Each resource is represented by one function and is annotated using special JAX-RS 3annotations. For example resource responsible for log in has following annotations placed just before the function implementing login resource:
1. @Path("/login") 2. @POST 3. @Consumes(MediaType.APPLICATION_FORM_URLENCODED) 4. @Produces(MediaType.TEXT_PLAIN)
3 Java API for RESTful Web Services
29
The annotation 1 specifies the URI address of given resource. Second line specifies the type of the resource (POST, PUT, GET, DELETE are possible). Line 3 and 4 specifies the type in
the input (received data from the Web service) and output type of the sent back data.
Presented above code annotates resource available under “…/login” URI that receive JSON
file and receive plain text.
To interact with the database it is necessary to open a session that is used to create new database entities, read in objects from the database, update and delete objects from the
database. It is accomplished by getting session from SessionFactory object:
Session session = HibernateUtil.getSessionFactory().openSession();
Having collected login data and opened session we can simply make a query to a database to obtain desired object. When the session is no longer needed it is closed. Code 5 shows the
way of obtaining list of available taxi drivers.
Criteria cr = session.createCriteria(Client.class) .add(Restrictions.eq("clientType","driver")) .add(Restrictions.eq("online", true)) .add(Restrictions.eq("busy", false)); List results = cr.list();
session.close();
Code 5 Hibernate query procedure
30
Figure 8 shows the procedure of handling new order within Web service.
Figure 8 Activity diagram representing handling a new order
31
3.5 Android Application
Android application structure consists of three main components: the descriptor, application
code and resources. This division provides a separate resource from application logic, which
significantly facilitates software creation and development. The most important components of the Android project are the following:
o AndroidManifest.xml - application descriptor file. It defines all intentions and
activities, determines requirements and application privileges, as well as the ability to
access other applications using the program. The file is required for proper operation of the application [14].
o src - the folder where the application code is stored. It contains all classes from which
the application is composed.
o res - the folder that contains the application resources. Includes sub-directories: o drawable - the folder containing the program graphics. It comes in three
versions, suitable for different sizes of screen on which the application runs.
o layout - the folder that stores the application view files saved using XML
(Extensible Markup Language) o values - stored here are other application resources, such as strings, colours.
They are written using XML files [15].
From technical point of view, customer application and application for taxi driver are basically the same program while user sees it as two independent ones.
32
3.5.1 Login activity
The common denominator of both “applications” is a login activity. In the activity user can log in into the system using login and password that, after positive validation by the Web
service results in running of the appropriate activity (for a customer or a taxi driver). Type of
activity the user is moved after log in is determined by response message from the Web
service which queries a database for user-type associated with the login. Describing activity is also responsible for getting GCM registration ID of the device on which the application is
running and send it to the Web service when logging in order to save it in a server database.
Activity consists of two text fields to enter login and password of a customer and login button
that confirms logging operation. Interface of the activity is shown on Figure 9.
Figure 9 LoginIn activity
33
3.5.2 Customer application
The application for a customer consists of a single activity which allows the customer to order a taxi. The activity consists of a button and a fragment of a map. The map fragment shows the
user his current position using a marker. Marker can be changed by the user and indicates
desired taxi order position. The button is used to make an order using a position of the marker.
Behind the UI (in a background), the activity handles GPS receiver when the activity is started and provides connectivity to the Web service when order is made. Figure 10 shows the
user interface of the application for the customer.
Figure 10 Customer’s Android client
34
3.5.3 Driver application
Before we describe driver-side of the application it is necessary to mention about driver statuses being crucial for the process of ordering a taxi in the system:
o online – when the driver is online it means he is logged into the system so he is able to
receive messages from a server. Otherwise he is offline;
o busy – indicates if the driver is currently handling any order. If the state of busy-state is false it means the driver is available and can handle a new order.
Activity UI for a driver contains status determining whether the driver is online or not and
information about busy-status. There are also three buttons used for: o setting the driver online status;
o setting driver busy-status as “free” when the taxi course ends;
o navigate to the client using Google Maps application.
Moreover, every time when the activity is resumed (onResume() method is called) the
activity sends update request of the Web service which responses driver status and updates user UI. Such solution is needed in case when the driver closes the application(i.e. receive
call, close application manually, etc.). It protects the application against losing the order
progress and non-deterministic application behaviour. Figure 10 shows the user interface of
the application for the taxi driver.
Figure 11 Driver’s Android client
35
3.5.4 Common ground
1. As well as login activity, receiver and service mentioned in Chapter 3 are also common for both “applications”. For instance they provide the taxi driver with information about
new order made by the customer. With the latter, receiver and service provides
information if the order that has or has not been made. GCM Receiver receives any
message sent by GCM service and passes it to the newly created service processing it and performing an appropriate action.
2. For every activity one-way communication to a Web service is implemented by using
extended Android AsyncTask class. It enables proper use of the UI thread while some work is executing. This class allows to perform background operations without using
threads or handlers. The communication process consists of three stages:
o onPreExecute method called when the connection is started. In this case it creates
and displays progress dialog on the screen. o doInBackground method creating new connection to the Web service, sending
information to it and getting response information.
o onPostExecute method called when transaction of information between Android
and Web service is finished. In this case the method process response information in appropriate way and closes progress dialog.
3 Every activity using GPS receiver, every time when it is resumed (see Chapter 2. Android
section) search for the position, then disable the GPS. It is conditioned by energy saving
issues.
36
3.6 Interaction within the system
This section presents the interaction between Android client and taxi Web service. The
interaction diagram (Figure 12) shows how the elements interact with each other in the
scenario when the new order has been made and accepted by first proposed taxi driver.
Figure 12 Interaction diagram
37
4. Testing
Application testing is a very important part of all implementation projects’ evaluation. Before
sharing an application and making it available for wide audience it is necessary to test it in
case for errors, unusual situations and different users’ behaviours.
The way of testing can be classified in two ways – due to its characteristics and approach
describing the tester point of view.
Assuming first classification testing can be static (referees to reviews, walkthroughs or
inspections methods) or dynamic (executing programmed code with a given set of test cases). Second classification mentioned above classifies testing approach to:
o White-box testing which tests internal structures or workings of a program, as
opposed to the functionality exposed to the end-user. In this case test scenarios are
designed from an internal perspective of the system. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs;
o Black-box testing which treats the software as a "black box" and does not require the
knowledge of internal implementation. The tester is only aware of the goal of the
software, not how it is accomplished. An example of such testing is usage case testing or specification-based testing;
o Specification-based testing scenarios Test cases are built around specifications
and requirements. The tester can simply verify that for a given input, the output
value (or behaviour), if "is" or "is not" the same as the expected value specified in the test case. Test cases are built around specifications and
requirements;
o Grey-box testing which combines both approaches from above. In this case designing
tests requires having knowledge of internal data structures and algorithms while tests are executed at the user or black-box level. However the tester can observe the state of
the product being tested after performing certain actions (i.e. query database)[28].
As there is no point in testing the Web service as a separate part testing was divided into two parts: mobile application for Android testing and the whole system cooperation testing.
4.1 Android Client Application Testing
Testing applications for Android is designed to validate the user interface creation and
lifecycle of every application activity. Tests have a dynamic character and were conducted
using white-box approach. Tests checking proper operation of the GPS receiver, interaction with external Web service and logic of the implementation are conducted manually according
to fixed scenarios presented in “Overall System Testing” section in this chapter.
38
Validation of proper interface creation was performed using Java-based JUnit4 test. The
example of Android JUnit class testing GPS receiver and a button which handles taxi order is
presented in Code 6.
public class ClientGPSTest extends ActivityInstrumentationTestCase2<TabActivity> { private TabActivity gpsActivity; private Button OrderGPSButton; public ClientGPSTest(){ super("cov.android.client.conn", TabActivity.class); } @Override protected void setUp() throws Exception { super.setUp(); setActivityInitialTouchMode(false); gpsActivity = getActivity(); OrderGPSButton = (Button) gpsActivity.findViewById(cov.android.client.conn.R.id.sendPosBn); } public void testGPSStatus(){ assertTrue(FragMent1.mlocListener!=null); } public void testGPSbutton(){ assertTrue(OrderGPSButton != null); } }
Code 6 JUnit test class
Presented tests led to following results:
Figure 13 Sample testing results
Result: During Android UI and GPS tests no errors were found. Test passed correctly for
every application that means every user interface element is created correctly.
4 Unit testing framework for a Java language.
39
4.2 Overall System Testing
Testing of the system has static character and is conducted according to grey-box approach.
Testing scenarios presented below were set up by changing the content of a database
manually according to the given scenario. The test was performed using one or two Android mobile devices (depends on scenario) from a customer’s point of view. During the test I was
observing responses showing on testing Android device, as well as a content of the database
for every step of testing scenario.
Scenario 1 (checking: login into the system; working of finding algorithm; reject and accept
the order by the driver; working of abandoned list, navigation for driver).
Table Client consists of:
o 2 online, not busy taxi drivers; o 1 online and busy taxi driver closer than above;
o 1 offline and not busy taxi driver closer than above;
o 2 clients.
Action Check if
Client1 log in into the system with wrong password
Rejected by the server
Client 1 log into the system using valid
login and password
Moved to a client activity
1st driver log into the system using valid login and password
Moved to a driver activity
Client1 making an order for a given
position
-
1st driver does not accept the order 1st driver added to abandoned table and delete after 3min
2nd driver receive and accept the order New order added into Order table
2nd driver navigates to the client Driver destination corresponds to client1
location
Client1 receives confirmation -
Client2 make an order within 3min after
client1
Client2 receives “no taxi available”
message
Result: The test was passed successfully. In each step of the testing scenario the outcome (for both Android devices and the database) was as expected. This leads to the conclusion that
system works properly, gives an opportunity to service taxi ordering and handles unusual
situations.
40
Scenario 2 (testing in case of “overload” situation) – this scenario is about testing the system behaviour in the situation when more than one client orders the same taxi in given time.
Table Client consists of:
o One not busy and online taxi driver; o Two clients with similar position ordering a taxi in the same time.
Result: Because of the fact that in such cases one message from a client gets to the server
earlier than the other (the difference can be even measured in milliseconds) , the driver assigned to the first client is automatically setting driver status to “busy” (according to the
database entry and behaviour of taxi driver application) for the time of taxi driver decision. In
this situation the second client is rejected and “no taxi” message appears on his device screen.
To illustrate the idea how tests were conducted Figure 14 and Figure 15 present an example
fragments of the database Client and Order table respectively.
Figure 14 Fragment of the Client table in database
Figure 15 Fragment of the Order table in database
41
5. Conclusions
The main objective of the thesis was to develop a system for handling the process of ordering taxis using mobile devices. To achieve this goal appropriate research as well as a series of
preparations and analysis has been carried out. Information presented in this thesis shows the
specifications of the systems consisting of several elements which communicate with each
other to exchange data. The information presented herein and the conducted research for the purpose of this thesis lead not only to a system that supports taxi servicing but also can be
used to create a similar system, which is based on a client-server architecture and uses mobile
applications working on Android OS.
Personally, I am proud of my work. During development of this thesis I learned the basics of the Android platform architecture and implementation, acquainted myself with Web services
architecture and generally with the basics of Java programming. All these three elements were
unknown to me before beginning of the final project.
5.1 Further Development
Due to its universal architecture the system presented in the thesis can be further developed
and extended with a number of functionalities. It is possible to introduce ordering the taxi according to customer’s preferences (i.e. price range, whether or not the car can be used by
people with disabilities, taxi car brand, required number of seats, etc.) and estimate time of
taxi arrival. The system can also be extended to support non-cash payments, give the
possibility to order a taxi for an address specified by the customer in terms of street number instead of relying solely on customer’s GPS device (which can be difficult to use in closed
areas, e.g. inside buildings) and let customer call an assigned driver.
5.2 Discussion
As mentioned in the previous section, the system can be extended with further functionalities.
The prototype of the system does not provide a full and comprehensive taxi service for a taxi
company. However the intention of the thesis was not building a system fully supporting a taxi company which could be suitable for release to the market but to evaluate if such a
system can be easily developed and work in everyday life. Missing functionalities were not
evaluated within the system because of the large amount of time needed to develop each of
them. However, mentioned functionalities do not constitute challenges in terms of implementation logic, therefore they did not constitute a critical element in the project
evaluation.
42
References
1. Chappell, D. A., & Jewell, T, “Java Web services”, Sebastopol, CA, O'Reilly, 2002.
2. CNET, “Google carves an Android path through open-source world.”, 2008 [online]
Available at: http://news.cnet.com/8301-13580_3-9949793-39.html [Accessed: 7 Apr
2013].
3. Db.apache.org ,“Apache Derby”, 2013 [online] Available at:
http://db.apache.org/derby/ [Accessed: 7 Apr 2013].
4. Google Inc., “Android SDK | Android Developers”, 2012 [online] Available at:
http://developer.android.com/sdk/index.html [Accessed: 1 Apr 2013].
5. Google Inc., “Permissions | Android Developers” [online] Available at:
http://developer.android.com/guide/topics/security/permissions.html [Accessed: 11
Apr 2013].
6. Google Inc., “Starting an Activity | Android Developers” [online] Available at:
http://developer.android.com/training/basics/activity-lifecycle/starting.html [Accessed:
8 Apr 2013].
7. Google Inc., “Introduction to the Google Maps Android API v2 - Google Maps
Android API v2 — Google Developers”, 2013 [online] Available at:
https://developers.google.com/maps/documentation/android/intro [Accessed: 7 Apr
2013].
8. Google Inc., “Google Maps API licensing - Google Maps API — Google
Developers”, 2012 [online] Available at:
https://developers.google.com/maps/licensing [Accessed: 7 Apr 2013].
9. jboss.org , “Hibernate Getting Started Guide”, 2014 [online] Available at:
http://docs.jboss.org/hibernate/orm/4.1/quickstart/en-US/html_single/ [Accessed: 7
Apr 2013].
10. wikipedia.org, “Java programming language”, 2005 [online] Available at:
http://en.wikipedia.org/wiki/Java_(programming_language) [Accessed: 1 Apr 2013].
11. wikipedia.org, “Object-relational mapping “, 2011 [online] Available at:
http://en.wikipedia.org/wiki/Object-relational_mapping [Accessed: 7 Apr 2013].
12. wikipedia.org , “Apache Tomcat”, 2013[online] Available at:
http://en.wikipedia.org/wiki/Apache_Tomcat [Accessed: 20 Apr 2013].
43
13. wikipedia.org , “JDBC driver”, 2011[online] Available at:
http://en.wikipedia.org/wiki/JDBC_driver [Accessed: 8 Apr 2013].
14. Haseman, C., “Android essentials”, 2008, Berkeley, CA: Apress.
15. Hashimi, S. and Komatineni, S., et al., ”Pro Android 2”, 2010, New York: Apress.
16. jboss.org , “Hibernate”, 2013. [image online] Available at:
http://docs.jboss.org/hibernate/core/3.2/reference/en/shared/images/overview.gif
[Accessed: 7.04.2013].
17. LEE, W.-M., & Krause, C.,.” Beginning Android 4 application development.”, 2012,
Indianapolis, Ind, Wrox/John Wiley & Sons. [online] Available at:
http://www.books24x7.com/marc.asp?bookid=45955 [[Accessed: 4 Jan 2014].
18. Minter, D., & Linwood, J., “Beginning Hibernate: from novice to professional.”, 2006,
Berkeley, CA, Apress.
19. Mysql.com, “ MySQL :: Why MySQL?”, 2008 [online] Available at:
http://www.mysql.com/why-mysql/ [Accessed: 7 Apr 2013].
20. Pdn.pelco.com, Untitled [online] Available at:
http://pdn.pelco.com/sites/default/files/original/4274web_service_diag.jpg [Accessed:
19 Apr 2013].
21. Play.google.com, “ Złap Taxi”, 2013 [online] Available at:
https://play.google.com/store/apps/details?id=pl.zlaptaxi.android.ui&feature=search_r
esult [Accessed: 1 Apr 2013].
22. Play.google.com, “ GetTaxi – Taxi Cab App”, 2013 [online] Available at:
https://play.google.com/store/apps/details?id=com.gettaxi.android [Accessed: 1 Apr
2013].
23. Roy T. Fielding, “Architectural Styles and the Design of Network-based Software
Architectures dissertation”, 2000, University of California
24. Sandoval, J., Roussev, A., & Wallace, R., “Restful Java web services master core Rest
concepts and create Restful web services in Java.”, 2009, UK, Packt Pub.,
Birmingham
25. Tryckydroid.blogspot.co.uk , “Android Dev & Splinters: SOAP vs REST. Web
service architectures milestones.”, 2012 [online] Available at:
http://tryckydroid.blogspot.co.uk/2012/03/soap-vs-rest-web-service-architectures.html
[Accessed: 20 Apr 2013].
44
26. W3.org, “Web Services Glossary”, 2004 [online] Available at:
http://www.w3.org/TR/ws-gloss/ [Accessed: 7 Apr 2013].
27. Google Inc., “<uses-sdk> | Android Developers”, 2014 [online] Available at:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels.
[Accessed 01 February 2014].
28. Ron Patton, “Software Testing”, 2005
45
APPENDIX 1 - Content of the CD
Attached CD has following structure:
The thesis in pdf file;
TaxiHere:
o Derby server– contains standalone database server;
o Taxi Servicing System:
AndroidRESTClient– contains Android client application;
google-play-services_lib – contains external google play service library;
RESTfulWS– contains Web service;
Servers– contains server for the system.
Source codes are available in “../src” subdirectory in each folder (excluding
Servers directory). The exception is AndroidManifest.xml file which is located
in directly in AndroidRESTClient directory.