Embed Size (px)
Citation preview
Aaron Gleeson
Submitted in partial fulfilment of the
requirements for the degree of
BSc in Business Computing
Dublin Institute of Technology
May 2016
Supervisor: Jenny Munnelly
TraXsi
Declaration
This is an original work. All references and assistance are acknowledged.
Signed: _______________
Date: _________________
TraXsi
Acknowledgements
I’d like to express my sincere thanks to every person who made this
project possible and assisted me at every point during its development.
Without your help and guidance it would not be to the same standard.
First I would like to thank Jenny Munnelly, my project supervisor, who’s
instruction this last year forms the basis of the entire project and without
which it would not have been possible to complete.
Jenny also provided me with information and guidance throughout the
year surrounding the various parts of my project and took an active role
in assisting and advising me, both of which proved invaluable to me over
the course of the year.
I would also like to thank Diana, who acted as second reader to the
project, for suggesting added improvements and functionality.
Next I would like to thank the people at Guidewire who taught me very
valuable, real world techniques and skills during my internship that I was
able to apply to this project and that contributed to its progression.
Finally I would like to thank my family, friends and class mates whose
continued support and help throughout the year and indeed throughout
the last four who have helped make all my achievements during my
academic career possible.
TraXsi
Table of Contents
Chapter 1 – Introduction 1
1.1 Introduction to TraXsi 1
1.2 Objectives of TraXsi 2
1.3 Business Case 3
1.4 Business Rules 4
1.5 Technologies Used 5
Chapter 2 – Requirements Capture and Analysis 9
2.1 – Business Actors and Workers 9
2.1.1 – User 9
2.2 – Requirements Analysis 9
2.2.1 – Functional Requirements 10
2.2.2 – Non Functional Requirements 14
2.2.3 – Use Cases 16
Chapter 3 – System Design 17
3.1 – TraXsi Architecture 17
3.2 – Choice of Technologies 17
3.2.1 – Language Choice 18
3.2.2 – Framework Choice 18
3.2.3 – Webserver Choice 19
3.2.4 – Database Choice 19
3.2.5 – Database Connectivity Choice 20
3.3 – Data Model 20
3.3.1 – Data Model Diagram 20
3.3.2 – Collections Summary 21
TraXsi
3.4 – UX/UI Design 25
3.4.1 – Main Screen 26
3.4.2 – My Account Screen 27
3.4.3 – New Trip Screen 29
3.4.4 – Loaded Route Screen 30
3.4.5 – Metering Screen 31
3.4.6 – Save Route Screen 32
3.4.7 – Traffic and Taxi Information 33
3.5 - Design Issues and Resolutions 34
Chapter 4 – Implementation 35
4.1 – Implementation Overview 35
4.2 – Implementation Issues and Resolutions 37
Chapter 5 – Test Plan 38
5.1 – Test Descriptions 38
5.2 – Test Results Table 41
Chapter 6 – Conclusion 45
Chapter 7 – References 46
TraXsi
1
Chapter 1 – Introduction
1.1 – Introduction to TraXsi
TraXsi is a distributed, mobile based technology platform that allows
users to monitor their taxi journeys in real time and track their actual trip
against a suggested route by the system. It also allows the app to meter
your fare in real time on your phone as well as provide estimates and
save the results.
The idea was completely unique. I wanted to try and develop something
that was not only technically challenging that tested my ability, but was
something useful and interesting that would serve some practical
purpose and I believe I’ve achieved that. I felt that taxi metering, whilst
legally regulated, had an arbitrary feel to it. TraXsi aims to eliminate this
by placing the meter directly in the user’s hand and to give some control
back to the passenger.
I deliberately incorporated technologies into the project I felt would be
useful additions, yet challenging to apply to it. The user end is completely
based on the Android mobile platform and having only used it for the first
time last September it proved to be a very steep learning curve.
The back end is a full stack, deployed, distributable webserver with an API
like interaction that performs distance, fare and traffic calculations. My
aim was to incorporate an entire client server architecture model as close
to industry standard as I could make it.
TraXsi
2
1.2 – Objectives of TraXsi
The primary objective of TraXsi was to build an application wherein the
user could monitor a taxi journey in real time and save it. A number of
smaller objectives had to be completed first.
The ability for the user to view their current location on a map.
The ability for a user to select an origin and destination.
The ability for the system to generate estimates based on that.
The ability for the system to draw the suggested route on a map.
The ability for the user to start / stop the metering function.
The ability for the system to measure distance, time and speed.
The ability for the system to accumulate the fare.
The ability for the system to produce an actual route vs. suggested.
The ability for the user to create an account with TraXsi.
The ability for the user to save their route and the details.
The ability for the user to load previous routes.
TraXsi
3
1.3 – Business Case of TraXsi
The primary business case for TraXsi is to save the user money. Ability to
avoid fraudulent charges, tariffs and unnecessarily longer routes taken by
taxis.
Alerting friends and family to where you are and you expect to arrive via
social media (particularly late at night and/or alone) introduces an
element of safety to the app. If the user does not alert someone as to
their whereabouts when requested something may be wrong.
Coupled with this, TraXsi has a Driver Check function allowing the user to
check the validity of the driver’s car and licence. This is an external,
integrated application.
The Dublin Bus app and National Transport for Ireland site allow for
favourite bus and train route saving (however they lack cost information).
This app now allows for customers to do the same with taxi journeys they
may take regularly and compare the costs of them with the cost of their
current trip.
Also the Hailo API has been directly integrated into TraXsi allowing users
to view the location of nearby Hailo cars on the map and, upon creating a
journey, book a trip with Hailo.
TraXsi
4
1.4 – Business Rules of TraXsi
There are a handful of business rules I implemented throughout TraXsi
and they are listed below:
An account with TraXsi is not necessary to use the service, but it is
necessary to save routes.
A user may not have more than a single route active at a given time
The metering can only take place with an active connection to the
TraXsi server.
TraXsi
5
1.5 – Technologies Used
A wide variety of various technologies was used throughout the
development of TraXsi. The project was split into a client and server
model so I will outline the technologies used in each. The overall
language for both elements was Java, specifically EE7 and Android SDK.
Client - Android SDK and Android Studio
The TraXsi application is itself built entirely using the Android SDK and
was developed using Android Studio, a specific IDE designed to work with
the Android OS and devices. My own mobile phone served as the
development platform without the need for emulators.
External Design Libraries
Various external UX/UI libraries have been incorporated into the project
to improve its design. They have been added to the project build and
used appropriately. This also includes the use of Google’s Material Design
library.
Google Maps API
Due to the nature of how TraXsi works, it makes heavy use of not only the
map’s API but the Distance Matrix API and the Places Autocomplete API
as well. These provide additional ease of use along with necessary data.
TraXsi
6
Google Geocoding API
The ability to convert your current location into a text representation of
the nearest address requires this API. It makes for a smoother UX.
Google Directions API
Allows for the ability to enter an origin, destination and any required
waypoints and produces an encoded set of latitude and longitude points
that can be rendered on a map as a visible line representing the route.
Google Places API
Allows for predictive search when entering the locations to build your taxi
route.
Hailo API
Hailo’s API has been fully integrated into TraXsi allowing users to view all
Hailo cars in their vicinity on the map in real time, with their position
being updated every few seconds, and uses the deep linking feature to
load their chosen route into Hailo and order a taxi.
Version Control
I used both Git and Bitbucket (bitbucket.com/arosta1) in conjunction with
each other to manage the versions of the app. It allowed me to branch
my code for various test functionality and restore it easily if needed.
TraXsi
7
Server – JBoss Container (Wildfly 9)
The TraXsi backend server is a full stack deployment. It is contained
within the Wildfly framework. It uses the RESTEasy library to expose Java
classes via REST and allows for calculations regarding time, distance, and
traffic. It has an underlying database built using MySQL and uses JPA and
Hibernate for data storage and retrieval and uses EJBs for data pre-
population.
EJB (Enterprise Java Beans)
I have made use of EJB to expose certain interfaces to apply my business
logic. They allow me to populate the database with the fare data
pertaining to the relevant locale TraXsi is operating in. In this case the EJB
creates an object that in turn populates the FareInfo table with Irish taxi
fare charges.
REST (Representational State Transfer)
This is the primary protocol I am using to expose the TraXsi server’s
internal services. Using standard HTTP requests I have exposed my core
business logic to TraXsi allowing for it to receive data pertaining to the
current fare cost and current traffic data and save user data.
Google Distance Matrix
This Google API allows the system to incorporate real time traffic data
into the estimate figure. It is called directly from the server and the data
is parsed accordingly and used in estimate calculation.
TraXsi
8
JSON (GSON)
All server requests and responses are using JSON (JavaScript Object
Notation) which is a lightweight state container for data. GSON is an open
source library for use in JSON conversions to and from POJOs (Plain Old
Java Objects).
JPA (Java Persistence API)
This API serves as a specification for data persistence for use with an
ORM (Object Relational Mapping) framework. It allows for the annotation
of Java classes to specify entities, rows, relationships, columns etc. and
access to integrated SQL queries. It also allows for the construction of
DAO’s (Data Access Objects) for use in funnelling data between my
database and REST exposure or EJBs.
Hibernate
Hibernate is the implementation side of the JPA ORM. Once it has the
entity and relationship annotations it can then construct a database
structure using the JPA specification and can be used to persist, delete
and edit data inside the database and allows for comprehensive querying
capabilities.
MySQL
MySQL is the RDBMS (Relational Database Management System) I used to
store the system’s data. The tables, relationships and foreign keys are
created via hibernate. It also allows me to edit data directly within the
database without the need for the TraXsi system to be active.
TraXsi
9
Chapter 2 – Requirements Capture and Analysis
2.1 – Business Actors and Workers
There is only a single end user of TraXsi so there is no clear divide
between them and business specific users. The user of the application is
represented by the User table in the MySQL database and the shared
preference within the phone.
2.1.1 – User
The user of my application has access to all of its presented functionality.
They can create or destroy taxi journeys, and save or load them. They can
start and stop the metering function and they can retrieve estimates for
their created journey.
In addition to this they can also view local Hailo cars in their vicinity and,
if they have an origin and destination selected, can book a Hailo car
directly.
2.2 – Requirements Analysis
In my requirements analysis I spoke a lot to my peers about what they
would expect an application of this nature to be able to perform. The
core idea was widely accepted with major focus on ease-of-use and
fluidity. For example no more than forty five seconds of use required to
launch the core feature and not requiring an account to use the core
service.
I also emailed and spoke to a taxi driver to find out exactly how the
meters function in relation to the vehicle’s speed and distance and how
they calculate the fare based on these figures which I have emulated
within TraXsi.
TraXsi
10
2.2.1 – Functional Requirements
A functional requirement refers to what the application actually does and
what the user expects it to do.
Category Title Requirement Justification
Route Create a Route User should have ability to create a new taxi route.
Core functionality. User will create this route to be tracked in real-time to see the cost.
Route Retrieve Estimates
Users should be able to see a high and low fare estimate for their journey.
TraXsi keeps track of your metered cost. This allows users to compare the figures to actual cost.
Route Get current Location
Users should be able to press the location button and the origin field will autofill their current location.
Better UX experience. Not having to type it in manually every time, even with the predictive search speeds up the UX.
TraXsi
11
Route Add / Remove Waypoint
Users can add or remove waypoints to their routes if they wish to go to specified places en route.
Users are no longer limited to a single A to B route. More flexibility and options.
Route Start Meter Starts the app tracking and fare metering process. Core functionality of system.
This functionality was the inspiration for TraXsi. All support activities are centralised around this requirement.
Route Add Passenger If an additional person enters the taxi en route this functionality supports that. Can also be undone.
After setting up the route an additional person may enter the taxi, this feature supports this.
Route Finish Route Terminates the tracking, timer and metering and ends the route. Allows users to create a new one.
Without this there is no way to properly view a route summary or to save the route.
TraXsi
12
Route Edit Fare User can alter the metered fare figure produced by TraXsi and enter the original from the meter if necessary.
A ‘just in case’ feature to ensure the saved route has accurate cost information.
Login User Login with email and password.
User can log in to their TraXsi account to view their routes. User login is required to save a route.
TraXsi allows users to save routes they may take frequently. Having an account ensures this data relationship.
Logout Logout User can logout of the app on their phone.
This functionality allows users to logout. Protects their cost information which may be confidential.
User Account View saved routes
Allow users to view all the routes they have saved to their TraXsi account.
Users may browse their previously saved routes and view saved fare and time information.
TraXsi
13
User Account Delete / Restore saved routes
Allow the user to remove a saved route from their list and restore it if deleted accidentally.
If a user no longer takes a route anymore then they may remove it. If it is deleted accidentally a small window is presented to restore it.
User Account Load saved route
Allow user to load a previously stored route and meter it again.
If a user wishes to travel a previous route and compare it to the route they last took this functionality will allow that.
User Account Hailo saved route
Allow a user to book a Hailo taxi for a route they have saved.
Better UX. Makes it easier to launch Hailo and book a taxi for a previous route.
User View Hailo cars Allow a user to view all Hailo cars in the immediate area.
A useful feature allowing users to see visible nearby taxis. Makes booking them an option inside TraXsi.
TraXsi
14
User Book Hailo taxi Allow a user to book a Hailo taxi for the desired route they wish to take.
Additional functionality to improve UX and give more flexibility to the user. A taxi can only be booked if a route has been entered.
User View Traffic User should be able to see real time traffic data on the map during the duration of their journey.
If a user wants to see what kind of traffic to expect en route then this feature allows them to do this.
User Driver Check A user should be able to check the validity of their driver.
Integrated external application. A user may enter the driver’s details and confirm their validity.
2.2.2 – Non Functional Requirements
Non-functional requirements act like attributes of the system, explaining
how the application works as opposed to what it actually does.
TraXsi
15
Usability
To ensure TraXsi could be used quickly and efficiently I focused a lot on
the UX. Endless amounts of typing and unclear dialog, particularly within
mobile applications, can make it very undesirable to use. The
requirement was to have a route entered, launched and started in under
a minute. I mapped the core functionality to a separate, non-intrusive
button on the main screen and made use of auto-population and
Google’s latest design libraries to achieve this.
Recoverability
All user data is persisted and accessed remotely. In the event of a user
losing their device all data is stored on the server and will not be lost. To
improve ease of use the user data is stored inside a session within the
device but this does not replace the remote data, it only allows the server
to download the relevant user’s data to the device.
Availability
TraXsi is available to use “out of the box” as soon as it has been correctly
installed. There is no requirement for a user to enter any login data to use
the service, it is presented as an option if the user wishes to save a route.
The requirement to make TraXsi readily available was to achieve superior
UX and to encourage more people to use the service if they do not wish
to have an account.
TraXsi
16
2.2.3 – Use Cases
The above Use Case Diagram demonstrates all the functionality
pertaining to a user of TraXsi.
TraXsi
17
Chapter 3 – Design
3.1 – TraXsi Architecture
3.2 – Choice of Technologies
Deciding which technologies to use was a challenge in itself. I wanted to
make the system complex enough that it would provide a challenge,
allow me to engage in self-learning with a new technology or framework
and present well yet familiar enough that I could actually complete it. The
goal was to strike a balance. With this balance in mind I compiled the
following list.
TraXsi
18
3.2.1 – Language Choice
Throughout this course we covered several different programing
languages. I decided to go with Java, a language that I have a lot of
experience with and that is heavily used in industry. I considered Ruby
but I did not believe the Rails framework to be suitable.
Java
The Java language forms the backbone of both the client and server
aspects of this project. We learned suitable frameworks this year to
couple with it and it has an extensive array of libraries I can use also.
3.2.2 – Framework Choice
The ideation of TraXsi required it to be a mobile platform. Knowing this I
explored both the iOS and Android platform. Android does not have a
cost attached to its development and either one would provide me with a
new learning curve for the project.
Android SDK
I received an introduction to Android this year of the course. Knowing it
to be free, based on the Java language and possessing an Android device
myself for testing made it an ideal option. It also allowed me to try out a
new framework for development.
TraXsi
19
3.2.3 – Webserver Choice
This element was comprised of many options. Apache Tomcat, JBoss,
Jetty to name a few. I wanted something that would suit my application’s
needs and provide stable development platform that I could use to add
my functionality and contribute to the system complexity.
JBoss (Wildfly 9)
This year we also received instruction on the deployment of JBoss. I
decided to use the latest version, renamed Wildfly, as it provided
frameworks for not only REST and EJB services I wished to use, but also
added layers of security and comprehensive configuration options
allowing it to be used with numerous other technologies.
3.2.4 – Database Choice
The database decision was simple enough. Throughout the course I had a
lot of experience with MySQL and was familiar with it. I had also explored
MongoDB but that required a lot of new configuration, Oracle presented
some interesting options and I used them during my internship. However
these were enterprise grade and exceptionally complex and contrary to
this JDBC was too simple.
MySQL
I decided to use MySQL as Wildfly provides set configuration options for it
out of the box so connecting it should, in theory, be relatively easy. It also
was complex enough to add to the system complexity and gave me a
chance to explore a singular software integration layer.
TraXsi
20
3.2.5 – Database Connectivity Choice
For this choice I had two data persistence options I had worked with
during this course. JDBC (Java Database Connectivity) or the use of
Hibernate with JPA.
Hibernate and JPA
I opted for the latter as the former was too simple to meet my data
management requirements and it presented me with an ORM solution to
data persistence which made it easier to understand inside the Java
language.
3.3 – Data Model
3.3.1 – Data Model Diagram
TraXsi
21
3.3.2 – Collections Summary
Fare Info
Field Java Field Description id int Auto incrementing
primary key used to identify the set of charges.
standardInitialCharge double Holds the value of the standard fare charge.
premiumInitialCharge double Holds the value of the premium fare charge.
standardDistanceAllowance double Standard distance allowance amount – in meters.
premiumDistanceAllowance double Premium distance allowance amount - in meters.
standardTimeAllowance double Standard time allowance amount – in seconds.
premiumTimeAllowance double Premium time allowance amount – in seconds.
standardTariffA double Standard tariff A charge – below 15km.
standardTariffB double Standard tariff B charge – above 15km.
premiumTariffA double Premium tariff A charge – below 15km.
TraXsi
22
premiumTariffB double Premium tariff B charge – above 15km.
standardTimeTariffA double Standard time tariff A charge – below 15km.
standardTimeTariffB double Standard time tariff B charge – above 15km.
premiumTimeTariffA double Premium time tariff A charge – below 15km.
premiumTimeTariffB double Premium tariff B charge – above 15km.
bookingFee double Fee stored if a taxi is booked in advance.
additionalPassengerCharge double Fee for each additional passenger.
cardBookingFee double Fee stored if taxi is paid for with card.
locale String Locale that the fares apply to – default to ‘Ireland’ – allows for future expansion.
TraXsi
23
User
Field Java Type Description
id int Auto incrementing primary key used to identify individual users.
name String Name of the user. email String Email of user. password String Account password of
user. favouriteRoutes List Holds a list of the
user’s FavouriteRoutes.
Favourite Route
Field Java Type Description id int Auto incrementing
primary key used to identify individual favourite routes.
favouriteName String Name the user will give to their route.
Route Route This field holds the reference to the route data for the saved favourite.
TraXsi
24
Route
Field Java Type Description id int Auto incrementing
primary key used identify the associated route data.
origin String Start address of the route.
destination String End address of the route.
journeyDuration int How long the journey took – this is rounded to nearest minute.
routeLength double How long the travelled route was in KM – rounded to one decimal place – e.g. 3.4KM.
fareEstimateHigh double High estimate of the fare price.
fareEstimatedLow double Low estimate of the fare price.
actualFare double Recorded fare price peopleInTaxi int Amount of people in
the taxi.
journeyDate Date Date and time the trip took place.
routeCoordinates List List of MapSite objects to store the latitude and longitude of each waypoint.
TraXsi
25
Map Site
Field Java Type Description id int Auto incrementing
primary key to identify each individual waypoint.
latitude double Holds the latitudinal value of the waypoint.
longitude double Holds the longitudinal value of the waypoint.
3.4 – UX/UI Design
TraXsi generates and presents a large amount of data to the User. The
challenge here was to design the software so that data was presented in
a legible manner that made sense to the user whilst keeping a smooth
and easy feel to the overall UX.
Coupled with this, UX and UI are probably one of the most important
aspects of modern day software development. Users expect quick,
obvious, responsive UI’s which are anything but simple to design and
build. This is particularly true for mobile applications.
TraXsi
26
3.4.1 – Main Screen
The main screen is comprised of two UI elements. The main menu which
can be open and dismissed and the ‘New Trip’ button. It is designed in a
minimalist way to keep focus on the actual map so it is not obscured or
blocked to the User. TraXsi keeps this design standard throughout most
other screens.
TraXsi
27
3.4.2 – My Account Screen
If there is no user logged in to TraXsi you will be presented with the login
screen. From there you may navigate to the register screen to register an
account.
TraXsi
28
Once you have logged in, if you have any saved routes on the system they
will be presented as shown on the left. These elements can be expanded
and contracted and swiped to be deleted. If you do not have any routes
you are simply shown an empty list and notification.
You may reload or Hailo any of these routes respectively using the
options on the elements.
TraXsi
29
3.4.3 – New Trip Screen
When constructing a new trip you will be presented with the screen on
the left. You may enter an origin and destination for your trip and once
the system has validated them you will be presented with a distance and
fare estimate.
You may auto populate your current location with the blue location
button and add additional waypoints to the route using the white
waypoint button on the top left.
TraXsi
30
3.4.4 – Loaded Route
Once your route is loaded it will be drawn onto the map (incl. waypoints)
as a blue line from origin to destination. The ‘Start the Meter’ button
appears at the base of the screen to be clicked upon the start of your
journey. Again this button is designed not to obstruct the map.
If you attempt to load a new route whilst one has been rendered you will
be given a prompt upon which, if confirmed, will wipe all of your route
data in place of a new one.
TraXsi
31
3.4.5 – Metering Screen
Upon starting the meter, TraXsi enters tracking mode where it will keep
track of your current location in real time, whilst rendering your actual
route in red as the taxi moves. A route timer, ETA and fare calculator are
all started and presented to the user for the duration of the trip. The fare
will increment exactly as the meter would.
This overlay can be dismissed to the bottom of the screen when the user
wishes to hide it to further avoid obscuring the map.
TraXsi
32
3.4.6 – Save Route Screen
Once the user finishes their route they will be presented with a route
summary of all the details. They may share it via social media on their
device also.
If the user wishes to save the route they will be prompted for a name and
once entered the route will be saved to their account.
A user must be logged in to save a route, otherwise the user will be
prompted with the login screen.
TraXsi
33
3.4.7 – Traffic and Taxi Information
The user may toggle live traffic data if they wish to view it. This feature
works with or without an active route.
The ‘Local Cabs’ feature shows all Hailo cars in the immediate area and
their current location which is tracked by TraXsi. If you have an active
route you may tap the Hailo icons and the Hailo app will launch allowing
the user to Hailo a taxi from their chosen origin to destination.
TraXsi
34
3.5 – Design Issues and Resolutions
All of this UI was designed and built using Google’s Material Design
libraries and standards. It is presented in a minimalistic and simplistic way
to user displaying all necessary data whilst keeping a smooth and
responsive feel to the overall UX.
I spent a lot of time optimizing the UI to improve TraXsi’s user experience.
It appears simple and clear but had a sharp learning curve as it included
multiple external design libraries in conjunction with the Material Design
guidelines.
Getting these to fit well was a challenge as some required various API
levels to function properly. Coupled with this documentation for some
libraries was not very well written and required me to utilise their design
elements but to construct the logic from scratch which was very
challenging.
Lastly, some UI elements I used in TraXsi were not designed to function
the way I wanted or needed them to. I had to borrow functionality from
other elements and merge it into the UI elements. Card expansion and
swiping for example.
TraXsi
35
Chapter 4 – Implementation
4.1 – Implementation Overview
TraXsi is based on a client-server model. It requires both components to
work correctly.
The latest Irish taxi fare charges, as seen in the figure above, are loaded
into the Fare Info table. From there TraXsi makes a series of REST calls to
the server to work out the relevant fare costs and estimates.
The server also makes use of the Google Distance Matrix API to calculate
the average traffic time for the user’s route and takes this into
consideration upon calculating the estimate. The estimates produced are
the minimal cost of the journey, based on distance and the maximum,
taking into consideration live traffic data.
TraXsi
36
Without the TraXsi Android app, the server effectively acts as an API in its
own right. It can take in route data and produce accurate estimates based
on that data.
I used Wildfly as my sever container that contained EJB’s for initial fare
info population, a REST exposed API for clients, business logic
surrounding the Irish taxi fares and JPA, Hibernate and MySQL to persist
all user data.
The TraXsi Android app acts as a client. It makes the appropriate REST
calls and presents the fetched data to the user in a clean and smooth UI
whilst providing core functionality of route tracking in its own right.
It does this by acquiring the user’s current location every time it detects a
change and records the longitude and latitude of that change.
During this process, TraXsi uses the location and time data it gathers in
conjunction with the server to calculate the user’s taxi fare as the user
moves along a particular route and presents the results to the user.
The user may then save this data if they wish or simply dismiss it and start
a new one at their convenience.
An account with the system is not required to access its core functionality
but is required to save recorded routes.
TraXsi
37
4.2 – Implementation Issues and Resolutions
One design decision I made was the separation of the fare functionality
from the Android app. I did this for two reasons:
The separation of the two systems allows for a much easier update
or addition of future fares to the system – e.g. if the Irish taxi fares
change or adding the London locale to the database. Separating the server implementation meant I got to build an entire
external backend system with industry grade components
increasing the system complexity considerably. I was able to learn
more by doing this than a single Android application.
These above issues meant that the learning curve was much steeper.
However through extensive reading of documentation and self-learning I
implemented the system I wanted for TraXsi.
Another implementation issue I faced was the use of EJB’s. I wanted to
add as many components as I could and that I learned throughout
university and merging the use of EJB’s with a REST exposed system
proved challenging. Allowing the business logic to interact with both
interfaces required that they worked together and complied correctly.
I resolved this however and with the current implementation the EJB’s act
as a minor client in the JVM. They are used to enter the fare data into the
database so the clients may use them.
TraXsi
38
Chapter 5 – Test Plan
5.1 – Test Descriptions
Test 1: Click ‘My Account’ while not logged in
Test 2: Click ‘My Account’ while logged in
Test 3: Attempt to login with no server connection
Test 4: Attempt to login with empty fields
Test 5: Attempt to login with incorrect email
Test 6: Attempt to login with incorrect password
Test 7: Attempt to login with valid details without server connection
Test 8: Attempt to login with valid details with server connection
Test 9: Attempt to register with no server connection
Test 10: Attempt to register with empty fields
Test 11: Attempt to register with registered email
Test 12: Attempt to register with valid details without server connection
Test 13: Attempt to register with valid details with server connection
Test 14: Attempt to load routes without server connection
Test 15: Attempt to load routes with server connection
Test 16: Attempt to launch saved route
Test 17: Attempt to Hailo saved route without Hailo installed
Test 18: Attempt to Hailo saved route with Hailo installed
Test 19: Attempt to swipe route to delete it with server connection
Test 20: Attempt to swipe route to delete it without server connection
Test 21: Attempt to restore deleted route without server connection
Test 22: Attempt to restore deleted route with server connection
TraXsi
39
Test 23: Click ‘New Trip’
Test 24: Attempt to load route with empty fields
Test 25: Attempt to load route with empty origin field
Test 26: Attempt to load route with empty destination field
Test 27: Attempt to auto populate origin with no internet connection
Test 28: Attempt to auto populate origin with internet connection
Test 29: Attempt to add empty waypoint
Test 30: Attempt to clear empty waypoint list
Test 31: Attempt to retrieve estimates with server connection
Test 32: Attempt to retrieve estimates without server connection
Test 33: Attempt to estimate route distance with internet connection
Test 34: Attempt to estimate route distance without internet connection
Test 35: Attempt to load route with valid fields
Test 36: Click ‘Start The Meter’
Test 37: Click ‘Start The Meter’ with no server connection
Test 38: Click ‘Add Passenger’ Button
Test 39: Click ‘Route Complete’ Button
Test 40: Click ‘Share Route’ Button
Test 41: Click ‘Save Route’ Button
Test 42: Attempt to save an empty route
Test 43: Attempt to save a route with no name
Test 44: Attempt to save a route while not logged in
Test 45: Attempt to save a route while logged in
Test 46: Attempt to save a route with no server connection
TraXsi
40
Test 47: Click ‘Local Cabs’
Test 48: Click taxi icon with no created route
Test 49: Click taxi icon with created route without Hailo installed
Test 50: Click taxi icon with created route with Hailo installed
Test 51: Click ‘Local Cabs’ with no internet connection
Test 52: Click ‘View Traffic’
Test 53: Click ‘View Traffic’ with no internet connection
Test 54: Click ‘DriverCheck’ with DriverCheck installed
Test 55: Click ‘Driver Check’ without DriverCheck installed
Test 56: Click blue ‘Route’ Button
TraXsi
41
5.2 – Test Results Table
Test Number Expected Actual Test Result 1 User shown the
login screen As expected Pass
2 User is shown the saved routes screen
As expected Pass
3 User is shown an error
As expected Pass
4 User is shown an error
As expected Pass
5 User is shown an error
As expected Pass
6 User is shown an error
As expected Pass
7 User is shown an error
As expected Pass
8 User is logged in As expected Pass 9 User is shown
an error As expected Pass
10 User is shown an error
As expected Pass
11 User is shown an error
As expected Pass
12 User is shown an error
As expected Pass
13 User registered and logged in
As expected Pass
14 User is shown an error
As expected Pass
15 User’s routes are presented in list
As expected Pass
TraXsi
42
16 Route screen is launched populated
As expected Pass
17 User is directed to Hailo install page
As expected Pass
18 User is taken to populated Hailo app
As expected Pass
19 Route is deleted As expected Pass
20 User is shown an error
As expected Pass
21 User is shown an error
As expected Pass
22 Route is restored to list and database
As expected Pass
23 Launches new trip screen
As expected Pass
24 User is shown an error
As expected Pass
25 User is shown an error
As expected Pass
26 User is shown an error
As expected Pass
27 User is shown an error
As expected Pass
28 User is shown an error
As expected Pass
29 User is shown an error
As expected Pass
30 User is shown an error
As expected Pass
31 User is shown an error
As expected Pass
TraXsi
43
32 User is shown an error
As expected Pass
33 User is shown an error
As expected Pass
34 User is shown an error
As expected Pass
35 Route loaded on map. Distance and fare estimates are presented
As expected Pass
36 Timer started, initial fare shown and tracking engaged
As expected Pass
37 User is shown an error
As expected Pass
38 Passenger count increased by one
As expected Pass
39 Tracking and timer stopped. Route completed page shown
As expected Pass
40 User’s share options shown
As expected Pass
41 User asked to name route
As expected Pass
42 User is shown an error
As expected Pass
43 User is shown an error
As expected Pass
44 Login screen presented
As expected Pass
TraXsi
44
45 Route is saved to database
As expected Pass
46 User is shown an error
As expected Pass
47 Hailo taxis shown on map
As expected Pass
48 User alerted to create route
As expected Pass
49 User is directed to Hailo install page
As expected Pass
50 User is taken to populated Hailo app
As expected Pass
51 User is shown an error
As expected Pass
52 Traffic is toggled on the map
As expected Pass
53 No traffic data is shown
As expected Pass
54 DriverCheck is opened
As expected Pass
55 DriverCheck install page launched
As expected Pass
56 Launches new trip screen
As expected Pass
TraXsi
45
Chapter 6 – Conclusion
Throughout this year I felt that designing and developing TraXsi was an
excellent way to not only demonstrate what I learned throughout my
years in university but to also showcase my ability to self-learn.
Until September of 2015 I had never done any Android development so
undertaking an independent app and a backend system was a tall order in
the time I had. I spent a lot of time reviewing documentation surrounding
the Android framework and their best practice design features. The
ability to read, understand and apply these documents inside TraXsi is a
skill I feel will stand to me as a developer. The ability to read about a
framework or application and incorporate it is invaluable in this field.
As I had previous agile experience I tried to work within this
methodology. I’d assign tasks for the given day or week and work towards
completing them, each time looking at what I had finished and what
needed to be done. In the last few weeks of the project I started working
on a daily basis.
Coupled with this I also made use of version control software integrated
directly into the IDE which allowed me to branch my code for test or
additional features I wanted to try out. Working like this allowed me to
manage my time efficiently and to work in a manner used in industry and
retain a very valuable skill I can use in my career.
Overall I enjoyed designing and building TraXsi. It was an incredibly
satisfying undertaking to see a concept move from ideation all the way to
a finished piece of useable technology and it allowed me to be creative
within my chosen field. I feel that the development process has taught
me some very valuable skills and greatly contributed to my experience as
a software developer.
TraXsi
46
Chapter 7 – References developer.hailo.com, (2016). Hailo API Documentation (Beta) [online] Available at:
https://developer.hailoapp.com/docs [Accessed 14th April 2016].
developers.google.com, (2016). Google Directions API Documentation [online] Available at:
https://developers.google.com/maps/documentation/directions/intro [Accessed 14th April 2016].
developers.google.com, (2016). Google Distance Matrix API Documentation [online] Available at:
https://developers.google.com/maps/documentation/distance-matrix/intro
[Accessed 14th April 2016].
developers.google.com, (2016). Google Geocoding API Documentation [online] Available at:
https://developers.google.com/maps/documentation/geocoding/intro [Accessed 14th April 2016].
developers.google.com, (2016). Google Maps for Android [online] Available at:
https://developers.google.com/maps/documentation/android-api/intro [Accessed 14th April 2016].
developers.google.com, (2016). Google Places API Documentation [online] Available at:
https://developers.google.com/places/web-service/intro [Accessed 14th April 2016].
docs.jboss.org, (2013). Developing JSF Project using JBoss AS7, Maven and IntelliJ [online]
Available at:
https://docs.jboss.org/author/display/WFLY8/Developing+JSF+Project+Using+JBoss+AS7,+Maven+a
nd+IntelliJ [Accessed 14th April 2016].
GitHub, (2016) CodePath Android Guides [online]
Available at: https://github.com/codepath/android_guides/wiki [Accessed 14th April 2016].
Griffiths, D. and Griffiths, D. (2015) Head First Android Development, 1st ed, O Reilly Media.
