Minibus-taxi fleet monitoring application for Android...
87
i Minibus-taxi fleet monitoring application for Android OS. Author: Jan Louis Brink 15332896 Study Leader: Thinus Booysen Submission Date: 21 May 2012 Report submitted in partial fulfillment of the requirements of the module Project (E) 448 for the degree Baccalaureus in Engineering in the Department of Electrical and Electronical Engineering at the University of Stellenbosch.
Transcript of Minibus-taxi fleet monitoring application for Android...
i
Minibus-taxi fleet monitoring
application for Android OS.
Author:
Jan Louis Brink
15332896
Study Leader:
Thinus Booysen
Submission Date:
21 May 2012
Report submitted in partial fulfillment of the requirements of the module Project
(E) 448 for the degree Baccalaureus in Engineering in the Department of Electrical
and Electronical Engineering at the University of Stellenbosch.
ii
Declaration I, the undersigned, hereby declare that the work contained in this report is my own original work unless
indicated otherwise.
Signature: ________________
Date: ________________
iii
Acknowledgements To my Mother and Father for their moral and financial support throughout the duration of this project.
To my girlfriend Jana Marnewick for staying by my side through late nights and furious mood swings as
well as help with creating the flow diagrams.
To Thinus Booysen for the advice and help he provided .
To my two flat mates, Waldo Scheepers and Wihan Reynecke for providing daily meals and good
entertainment.
And lastly but not the least, to my friend Zander de Beer for letting me win at Fifa 11 and thus keeping
my spirit and confidence high.
iv
Summary Android is currently one of the largest developed and development communities in the world. Some of
the largest cellphone makers in the world all run Android OS on a wide variety of smart phones.
According to [19] the Android Market has 400 000 available apps at the moment and is likely to surpass
Apple in the near future. Humans have a need for a personal and visible confirmation of a task, progress
or status of any number of things. Tracking and monitoring the progress, position and status of an
owner’s or company’s assets, gives them a sense of security and control over it. Integrating the need for
a visible and up to date system, with an Android application which is easily accessible, makes for a very
sought after product.
The purpose of this project was to design, construct and implement a graphical user interface (GUI) that visually tracks a fleet of minibus taxis in real time, by displaying relative information on a smart phone application. The application or system connects with a server, situated in Durbanville, maintained by Trinity Telecoms. After connecting to the server, various information fields is downloaded onto the chosen platform. The information downloaded is in JSON format. The information that is expected, are the following:
The Name of the driver
Age of the driver
Registration number of the vehicle
Current Speed
Current Speed data recorded for the past 30 data points
Occupant number
Occupants for the past 30 data points
Current Heading
Maximum speed driven in past 30 minutes
Maximum acceleration in past 30 minutes
Longitude coordinates
Latitude coordinates
The application reconnects and updates the information at a specified interval, while the application is
running.
The application was designed from the top down, but each of the individual activities or sub-systems
were designed from the bottom up. There are five activities that run on the system, and each was
designed and constructed separately. The integration of the sub-systems was added after each
component or activity was completed.
v
Opsomming Android is op die oomblik een van die grootste ontwikkeling en ontwikkelde gemeenskappe ter wêreld.
Van die grootste selfoon makers gebruik almal die Android beheer stelsel op n weie verskeidenheid van
selfone. Die mens smag na ‘n persoonlike en visuele bevestiging dat ‘n taak of process suksesvol voltooi
het. Die volg en monitor van die vordering, posisie en status van ‘n eienaar of besigheid se bate, gee
hulle ‘n gevoel van sekuriteit en beheer daar oor. Deur die behoefte vir ‘n visuele en op datum sisteem
te integreer met ‘n android-gebaseerde program wat maklik toeganklik is, sal vir ‘n baie gesogte
program maak.
Die doel van hierdie projek was om grafiese gebruikerskoppelvlak the ontwerp, ontwikkel en
implementer wat ‘n vloot taxi’s visueel en in regte tyd kan volg, deur relevante inligting op ‘n selfoon
program te vertoon. Die program of stelsel verbind met ‘n maatskapy bediener, geleë in Durbanville,
genoemd Trinity Telecoms. Na verbinding met die bediener, sal verskeie inligtings velde afgelaai word
op die gekose platform.
Terwyl die program hardloop, moet die die informasie wat op die sisteem is teen ‘n vasgestelde interval
opdateer word.
Die program is ontwerp vanaf die bo-kant, maar elkeen van die individuele aktiwiteite of sub-stelsels is
ontwerp vanaf die onderkant. Daar is vyf aktititeite wat uitgevoer word op fie stelsel en elkeen is
afsonderlik ontwerp en wontwikkel. Die integrasie van die sub-stelsels is bygevoeg na elke komponent
of aktiwiteit voltooi is.
vi
Table of Contents Declaration .................................................................................................................................................... ii
Acknowledgements ...................................................................................................................................... iii
Summary ...................................................................................................................................................... iv
Table of Symbols ......................................................................................................................................... xii
Table of Words ............................................................................................................................................ xii
1. Introduction .......................................................................................................................................... 1
1.1 Project Background ....................................................................................................................... 1
1.2 Android Background ..................................................................................................................... 1
1.3 Methodology ................................................................................................................................. 2
1.4 Demonstration Video .................................................................................................................... 2
1.5 System Layout ............................................................................................................................... 2
2. System Overview................................................................................................................................... 3
2.1 Activities Overview ....................................................................................................................... 3
2.2 Functional Overview ..................................................................................................................... 4
2.2.1 Authentication Activity ......................................................................................................... 4
2.2.2 Tab Activity ............................................................................................................................ 5
2.2.3 Info tab Activity ..................................................................................................................... 5
2.2.4 Graph tab Activity ................................................................................................................. 5
2.2.5 Maps tab Activity .................................................................................................................. 6
2.3 System Architecture ...................................................................................................................... 6
3. Database Setup ..................................................................................................................................... 7
3.1 Asset Model Setup ........................................................................................................................ 7
3.1.1 Goal ....................................................................................................................................... 7
3.1.2 Design .................................................................................................................................... 7
3.2 Metric Model Setup ...................................................................................................................... 9
3.2.1 Goal ....................................................................................................................................... 9
3.2.2 Design .................................................................................................................................... 9
3.3 Device Simulator ......................................................................................................................... 10
3.3.1 Goal ..................................................................................................................................... 10
3.3.2 Design .................................................................................................................................. 10
vii
3.4 URL Request Resources ............................................................................................................... 11
3.4.1 URL (A): List of all assets ..................................................................................................... 11
3.4.2 URL (B): Metric model information of a single asset .......................................................... 12
3.4.3 URL (B) & (C): Past 30 data points of a specific metric field ............................................... 12
3.5 Asset Descriptor Tool .................................................................................................................. 12
3.5.1 Goal ..................................................................................................................................... 12
3.5.2 Design .................................................................................................................................. 13
4. Authentication Activity ....................................................................................................................... 13
4.1 Goal ............................................................................................................................................. 13
4.2 Research ...................................................................................................................................... 13
4.2.1 SOAP vs REST ....................................................................................................................... 14
4.2.2 Storage areas compared ..................................................................................................... 18
4.2.3 Different thread types compared ....................................................................................... 20
4.3 Design and Overview .................................................................................................................. 22
5. Info tab Activity ................................................................................................................................... 23
5.1 Goal ............................................................................................................................................. 23
5.2 Overview ..................................................................................................................................... 23
5.2.1 Scheduled Timer ................................................................................................................. 23
5.2.2 Connect and update ............................................................................................................ 24
5.2.3 Spinner setup (a.k.a. drop down bar) ................................................................................. 25
5.2.4 Seekbar used to control the update time ........................................................................... 26
5.2.5 Research .............................................................................................................................. 27
6. Graph tab Activity ............................................................................................................................... 27
6.1 Goal ............................................................................................................................................. 27
6.2 Research ...................................................................................................................................... 27
6.2.1 ChartDroid ........................................................................................................................... 28
6.2.2 AChartEngine ...................................................................................................................... 28
6.2.3 Google chart API ................................................................................................................. 29
6.2.4 GraphView........................................................................................................................... 29
6.2.5 Discussion of options left .................................................................................................... 30
6.3 Activity flow and Overview ......................................................................................................... 30
6.3.1 Scheduled Timer ................................................................................................................. 30
viii
6.3.2 Update Graphs .................................................................................................................... 31
6.3.3 Drawing of a graph .............................................................................................................. 32
7. Maps tab Activity ................................................................................................................................ 35
7.1 Goal ............................................................................................................................................. 35
7.2 Research ...................................................................................................................................... 36
7.2.1 ItemizedOverlay .................................................................................................................. 36
7.3 Setting up google maps ............................................................................................................... 36
7.3.1 Acquiring the MD5 Fingerprint ........................................................................................... 36
7.3.2 Registering the MD5 fingerprint with the Google Maps Service ........................................ 38
7.3.3 Adding the key to the application ....................................................................................... 38
7.3.4 Enable internet connection in Android Manifest ............................................................... 39
7.4 Design and Overview .................................................................................................................. 39
7.4.1 ItemizedOverlay .................................................................................................................. 39
7.4.2 onTap .................................................................................................................................. 39
7.4.3 Overview - Starting the activity........................................................................................... 40
8. User Interface ..................................................................................................................................... 44
8.1 Overview ..................................................................................................................................... 44
8.1.1 Graphical User Interface Overview ..................................................................................... 44
8.1.2 Design Overview ................................................................................................................. 45
8.2 Authentication window .............................................................................................................. 46
8.2.1 General ................................................................................................................................ 46
8.2.2 Design Specifications........................................................................................................... 47
8.3 The tabs ....................................................................................................................................... 47
8.3.1 Info Tab UI Window ............................................................................................................ 48
8.3.2 Graph Tab UI Window ......................................................................................................... 49
8.3.3 Maps Tab UI Window .......................................................................................................... 50
9. Testing ................................................................................................................................................. 51
9.1 General ........................................................................................................................................ 51
9.1.1 Testing Methods ................................................................................................................. 52
10. Conclusion and Recommendations................................................................................................. 55
10.1 Conclusion ................................................................................................................................... 55
10.2 Recommendations ...................................................................................................................... 56
ix
References .................................................................................................................................................. 57
Appendix A: Project Plan ............................................................................................................................. 58
Appendix B: Project Specification ............................................................................................................... 59
Appendix C: Outcomes Compliance ............................................................................................................ 60
Appendix D – Flow Diagram ........................................................................................................................ 62
D1 - Application ....................................................................................................................................... 62
D2 - Tab Activity ...................................................................................................................................... 62
D3 - Authentication Activity .................................................................................................................... 63
D4 - Info tab Activity ............................................................................................................................... 64
D5 - Graph tab Activity ............................................................................................................................ 65
D6 - Get Bar Graph View ......................................................................................................................... 66
D7 - Get Line Graph View ........................................................................................................................ 66
D8 - Refresh Trinity Cache ....................................................................................................................... 66
D9 - Set Graph Array ............................................................................................................................... 67
D10 - Set Graph – Object Array ............................................................................................................... 67
D11 - Create coordinate Drawings .......................................................................................................... 67
D12 - Create all coordinate Drawings ..................................................................................................... 67
D13 - Google Maps Activity ..................................................................................................................... 68
D14 - Get all location .............................................................................................................................. 69
D15 - On Location Item Tap .................................................................................................................... 69
D16 - Downloading Information (httpCall) ............................................................................................. 69
D17 - Set metric data of information downloaded ................................................................................. 70
Appendix E- Additional information ........................................................................................................... 71
E1 – Android Manifest ............................................................................................................................ 71
E2 – Asset Descriptor Object ................................................................................................................... 72
E3 – Asset Descriptor Setup in AirVantage ............................................................................................... 2
E4 – Metric Model Maker Setup ............................................................................................................... 2
E5 – Single Asset Information ................................................................................................................... 3
x
Figure 1 - Android OS distribution [13] ......................................................................................................... 3
Figure 2 - Application flow and interaction .................................................................................................. 4
Figure 3 - Tab configuration .......................................................................................................................... 5
Figure 4 - Single asset displayed on map ...................................................................................................... 6
Figure 5 - All assets displayed on map .......................................................................................................... 6
Figure 6 - Full System, from Asset to Platform. ............................................................................................ 6
Figure 7 – All assets setup at server [15] ...................................................................................................... 7
Figure 8 - AirVantage Project setup .............................................................................................................. 7
Figure 9 - Customer model search in AirVantage ......................................................................................... 8
Figure 10 - Asset Model set up in AirVantage ............................................................................................... 8
Figure 11 - AirVantage server connection settings ....................................................................................... 9
Figure 12 - Device simulator message for the movement path ................................................................. 10
Figure 13 - Device Simulator connection settings ...................................................................................... 11
Figure 14 - SOAP request message explained graphically .......................................................................... 14
Figure 15 - SOAP request [17] ..................................................................................................................... 15
Figure 16 - REST http example .................................................................................................................... 17
Figure 17 - Spinner drop down example containing registration numbers ................................................ 25
Figure 18 - Seekbar and controlling checkbox ............................................................................................ 26
Figure 19 - ChartDroid example [9]. ........................................................................................................... 28
Figure 20 - AChartEngine example .............................................................................................................. 28
Figure 21 - Google chart API example [18] ................................................................................................. 29
Figure 22 - GraphView example [12] .......................................................................................................... 29
Figure 23 - Graph tab selected .................................................................................................................... 30
Figure 24 - Graph tab in portrait mode ....................................................................................................... 31
Figure 25 - Graph tab in landscape mode ................................................................................................... 32
Figure 26 - Occupants dataset example ...................................................................................................... 33
Figure 27 - Pin used to display location ...................................................................................................... 36
Figure 28 - Default Debug Keystore location .............................................................................................. 37
Figure 29 - MD5 key in command prompt .................................................................................................. 37
Figure 30 - Location of keytool.exe in command prompt........................................................................... 37
Figure 31 - Registering the MD5 fingerprint ............................................................................................... 38
Figure 32 - Window after Successful registration of MD5 fingerprint ........................................................ 38
Figure 33 - Xml file containing the Google Maps API key ........................................................................... 38
Figure 34 - Google Maps API ley stored in Strings location ........................................................................ 38
Figure 35 - Maps tab selected ..................................................................................................................... 40
Figure 36 - Single Asset’s location displayed in a Map ............................................................................... 41
Figure 37 - Span of a map ........................................................................................................................... 42
Figure 38 - All assets' location displayed on map ....................................................................................... 43
Figure 39 - Different icon sizes. From ldpi to hdpi ...................................................................................... 46
Figure 40 - Authentication UI window ........................................................................................................ 46
Figure 41 - Authentication page with keyboard ......................................................................................... 47
Figure 42 - UI tabs ....................................................................................................................................... 47
xi
Figure 43 - Icons used for the tabs. Selected and idle state ....................................................................... 47
Figure 44 - Info tab UI window ................................................................................................................... 48
Figure 45 - Seekbars disabled ..................................................................................................................... 49
Figure 46 - Graph UI window in portrait orientation .................................................................................. 49
Figure 47 - Graph UI window in landscape orientation .............................................................................. 50
Figure 48 - Pin used to display location of an asset in Google Maps .......................................................... 50
Figure 49 - A Single Asset displayed in Google Maps ................................................................................. 50
Figure 50 - All Assets displayed in google Maps ......................................................................................... 51
Figure 51 - Asset's information displayed when tapped in google maps ................................................... 51
xii
Table of Symbols OS Operating System
3G 3rd generation mobile telecommunications
ADT Android Development Tools
JRE Java Runtime Environment
API Application Programming Interface
JAR Java Archive
XML Extensible Markup Language
JSON Java Script Object Notation
HTTP Hypertext Transfer Protocol
SOAP Simple Object Access Protocol
REST Representational State Transfer
Table of Words
Asset The asset is defined as any import object that is expected to upload information to the server. In this case is a vehicle.
Platform The platform is defined as any tool that is used to display the information obtained from the server on. In this case a smart phone is used
Asset Model The model set up that the asset can send information to, as well as the information expected.
Metric Model The model the platform will be downloading information from. This model uses the Asset Model information, but converts the information into human readable form.
Backwards Compatible
Being backwards compatible enables a system that is more advanced and more up to date to still be able to display or use an older or obsolete system or program
Listener A function used in android application development to enable the processes to recognize when an element in the UI window was selected or changed.
JSON Object
This is an Object Notation that will house a single elements containing various information separated by an identifier. By calling the identifier within the Object enables the retrieval of the value stored there.
JSON Array This is an Object Notation that will house a large number of elements contained within. A JSON Object can be contained within or another JSON Array.
1
1. Introduction
1.1 Project Background The aim of this project was to design and develop a working UI driven application. An application or
system was needed to extract and visualize the information generated and collected from the tracking
of the minibus. A separate project aims to design and develop a hardware-based tracking system, which
uploads various information (such as speed, acceleration and number of occupants) to Trinity Telecoms’
data server via cellular-enabled devices.
The specifications of the project, was to design, implement, and test a working application that can
visually display the requested information in an easy to understand application. During the development
of this project, the vehicles, or assets as it will be called hence forth, that were to be tracked, were not
yet available. Assets were therefor simulated. Trinity Telecoms were contacted and during a contact
session, the metric models were discussed. The metric model fields and their types that were identified
were:
STRING - The Name of the driver
STRING - Age of the driver
STRING - Registration number of the vehicle
STRING - Current Heading
INTEGER - Current Speed
INTEGER - Current Speed for the past 30 data points
INTEGER - Occupant number
INTEGER - Occupants for the past 30 data points
INTEGER - Maximum speed driven in past 30 minutes
INTEGER - Maximum acceleration in past 30 minutes
DOUBLE - Longitude coordinates
DOUBLE - Latitude coordinates
A device simulator will simulate the asset when needed. Using the above model and the device
simulator, a fully functional asset can be simulated. With that information and a viable platform for the
system or application to run on, the system was designed.
1.2 Android Background The newest generation of mobile phones features a brand new operating system that goes by the name
Android. Developed by Android Inc. and Google, the Android operating system is revolutionary in that it
allows open source development. While previous mobile phones had a very rigid development process
for applications, phones built with the Android operating system allow anyone to create applications.
These applications are available through the Android Market and can be downloaded directly from the
handset. Many of these applications, unlike traditional mobile phone apps, are available for free or a
very low price. [1]
2
Millions of mobile phones around the world, all run Android OS. Android was originated by a group of
companies known as the Open Handset Alliance, led by Google. Today, many companies have invested
heavily in Android, typically in the form of allocating significant engineering resources to improve
Android and bring Android devices to Market. [2]
Because there is a larger Android smartphone community and development is open source, Android OS
was chosen to be the platform for the application.
1.3 Methodology This project has been created from the ground up, using the top down or waterfall model. The waterfall
model consists of defining the requirements, designing of the software, implementation thereof and
testing the completed system. The final product specifications were identified and the individual
components specified. The individual components or sub systems were created separately and the
bottom up method was followed. Each of the sub systems are integrated into the full system after each
was completed. The complexity of the system grew as a new sub system was added.
The system as a whole was developed using java, with an Android Development Plugin (ADT) as well as
Java Runtime Environment 1.7 (jre1.7) in Eclipse. All of the development tools were recommended by
the official Android development community [14].
1.4 Demonstration Video A demonstration video demonstrating the functionality of the application is available. The video can be
found online at: http://youtu.be/qEhPW0sUFGA
1.5 System Layout There are eight other main sections that will explain the project elements. Section 2 explains the system
overview. Section 3 explains how the database and its elements are set up. Section 4, 5, 6 and 7 explain
the activities, the research done and functions used to make the application function correctly. Section 8
defines the user interface used and the design choices made. Section 9 explores the final testing of the
application. Finally section 10 contains the conclusion and recommendations for future expansions.
3
2. System Overview
2.1 Activities Overview The application can be divided into five activities. An activity is an application component that provides a
screen with which users can interact in order to do something, such as dial the phone, take a photo,
send an email, or view a map. Each activity is given a window in which to draw its user interface [3]. An
application typically consists of multiple activities. All activities have to be declared in the Android
manifest. Appendix E1 shows the Android Manifest file used in this application.
The minimum software development kit version is set to version 7. This means that the minimum
Android OS version is set to 2.1, which is the API level that was worked on.
An investigation was done to choose the Android OS the application was to be designed on. Consulting
the Android developers’ website, Figure 1 below explains the distribution of all the current Android OS
over all current platforms running their OS.
Consulting Figure 1, we notice that if we choose Android OS 2.1, we get the highest OS level with the
largest amount of platforms supporting it, as all Android OS is backwards compatible. Android 2.1 is
currently supported by 97% of all Android platforms. For those reasons, Android 2.1 was chosen as the
OS to develop the application on.
Inside the manifest, it is common to have the <uses-permission> -tag. This defines the features that the
user grants and the application needs to access. The permissions set in this manifest are permission to
access the internet and also access the network state to gain information about the network.
The <action> - tag defined that Authentication.java was the main activity and needed to be launched
first. This activity is explained in more depth in section 4. The other preferences set are to define the
initial state of the application when launched. The application is set to not retain the state of the
application from the previous run. Each new application starts fresh, with no saved preferences.
Figure 1 - Android OS distribution [13]
4
With each of the other activities, there is a command line:
Android:configChanges="keyboardHidden|orientation"
This sets the application orientation change to manual for each activity that has defined this command.
Each activity that is defined to manually configure the orientation change and further requires a small
method to handle the orientation change in each activity. This enables each activity to change the
orientation of the platform without the need to recreate each window. If each window is recreated the
Boolean flags and all states of the application is reset with it.
As explained, each activity corresponds to a window that the user can interact with. The five activities
are:
Authentication.class - Explained in section 4
Tab_Activity.class - Explained in section 2.2.2.2
info_Main.class - Explained in section 5
Graph_Window_Activity.class - Explained in section 6
Google_Maps_Activity.class - Explained in section 7
2.2 Functional Overview The best way to describe the functional flow of the application is through a flow chart. The flow chart in
Figure 2, describes the flow of the application from start to stop and the interaction between the
activities.
A connection to the internet is required for the application to function correctly.
2.2.1 Authentication Activity
The main and first activity that starts on the application’s first run is the Authentication.java shown in
Figure 2. It is designed to start fresh with every launch. No initial saved state or preferences are to be
held in the background. The main function of the authentication class is to setup and gain the login
credentials from the user. If a connection to the server can be made and the first information about the
assets are gained. This information is called the asset descriptors. The application then proceeds to the
second activity.
Figure 2 - Application flow and interaction
5
The activity is explained in section 4 and the user interface elements of this activity are explained in
section 8.2.
2.2.2 Tab Activity
The second activity class to be called on is Tab_Activity.java. The function of this activity is to activate
the tab host and listener that will control the switch between each of the tabs created. The tabs created
are displayed in Figure 3.
The tab in position 0 will always be the default tab when application is launched. Switching between the
tabs requires the user to move a curser to the selected tab and select it, or simply by tapping on each of
the tabs when using a touch screen.
2.2.3 Info tab Activity
With the default tab, or the “Info” tab according to Figure 3 selected, the application calls on the next
activity called info_Main.class. The function of this activity is to display the asset chosen in text form
only. When the application starts, a scheduled timer also starts. The function of the timer is to initiate a
reset of all update flags and force an update of the current asset’s information displayed.
The info of each asset is stored after it is sent through a method to remove all the unnecessary
information and characters. The information of a single asset is downloaded at a time, to spare data
usage. Only when a new asset is chosen, is its information downloaded and stored. A new asset can be
selected using a dropdown bar or a spinner as it is called. Figure 4 shows the text based information.
The activity is explained in section 5 and the user interface elements of this activity are explained in
section 8.3.1.
2.2.4 Graph tab Activity
By selecting the second tab, or the “Graph” tab according to Figure 3, the application calls on the next
activity called Graph_Window_Activity.class. When this activity starts, a scheduled timer is activated.
Every ten seconds the timer checks if a certain flag set from the timer in the “Info” tab is true. If it is
true, it forces an update of the information used on this activity. This activity uses a dataset of the past
thirty data points of two metric fields, to draw a line and a bar graph. The two metric fields are “current
speed” and “occupants”. “Current speed” is used to draw a line graph and “occupants” is used to draw a
bar graph. In portrait orientation, the line and bar graph are both displayed in a single view. When the
orientation changes to landscape, a new view is loaded that only displays a single graph. A button is
used to change the view from the line to the bar graph.
The activity is explained in section 6 and the user interface elements of this activity are explained in
section 8.3.2.
Figure 3 - Tab configuration
6
2.2.5 Maps tab Activity
By selecting the third tab, or “Maps” tab according to Figure 3, the application calls on the next activity
called Google_Maps_Activity.class. When this activity starts, same as in the previous tab, a scheduled
timer is activated. Every ten seconds the timer checks if a certain flag set from the timer in the “Info” tab
is true. If it is true, it forces an update of the information used in this activity. In this activity, the
longitude and latitude information of each asset is used to display the location of an asset on a google
maps view. There are two modes in which locations are displayed. The first is the default setting and
uses the currently selected asset’s information to display its location. The second mode is activated
when a toggle button is pressed button. The new mode displays all available assets on the map. If one of
the assets isn’t up to date yet, the needed information is downloaded for each asset.
Figure 4 and 5 display the difference between the modes.
2.3 System Architecture The structure of the system was designed to be as noncomplex as possible. Figure 6 will give a layout of
the full system after all elements are completed - hardware and software.
Figure 6 gives a full description of the completed project. This project only handles the task of designing
the software needed to display the completed information. The large red square shows the scope of this
project in relation to the rest of the completed system. The architecture and influence of each activity to
the next, has already been displayed in Figure 2. The application was designed step wise from the top
down. The system as a whole was designed and specified first and then the individual sub system
Scope of this project
Internet
Trinity
Telecommunications
Servers
MTN Servers
Platform
Platform
Platform
3G
3G
3G
Asset
Asset
Asset
Figure 4 - Single asset displayed on map
Figure 5 - All assets displayed on map
Figure 6 - Full System, from Asset to Platform.
7
Figure 7 – All assets setup at server [15]
specifications were laid out. The sub systems or activities were each designed and constructed from the
bottom up.
3. Database Setup
3.1 Asset Model Setup
3.1.1 Goal
During the design and progress of this project, there were no active assets currently available. Thus no
information could be updated to the server for use in the application’s trials and testing.
The goal of setting up the database is to enable certain information to be sent and stored in the server
storage. A metric model is needed to setup the variables and type of each that the server is expecting.
Information can then freely be updated to the Trinity Telecoms’ database and then downloaded to the
platform. This process will help in the simulation of all the assets. There are currently three assets
defined as showed in Figure 7. One metric model will be setup and used for all assets.
3.1.2 Design
A tool called “AirVantage Configuration Tools” was used to start the setup. An operating portal project
was started and three folders were created. Figure 8 shows the project setup.
Figure 8 - AirVantage Project setup
8
The first folder to be created was for Manufacturer. A file called “TRINITY BASE (90 MIN)” was added to
the folder. This is a default file that must be added and nothing can be changed. This file sets that if an
asset communicates with the server, it expects it to communicate within ninety minutes again. If it does
not, the asset’s communication indicator goes offline.
The communication indicator is but an indication if the asset is actively sending and receiving
information. As shown in Figure 8 the “Comms” column shows that none of the assets have reported in
in the past ninety minutes.
The second folder is the Customer. This file was set up by Trinity Telecoms prior to this project for use by
the University of Stellenbosch. This file can be found by using the search criteria as shown in Figure 10.
This also a default file and no changes can be made to its structure. The model should be associated
with the manufacturer file – “TRINITY BASE (90 MIN)”.
The final folder set up was the Asset folder as seen in Figure 8. The model was found the same way as
shown in Figure 9, but substituting the model type from customer to asset. With this done the model
UoSA can be added. This model is fully customizable and will be used to set up the asset model that will
be used.
With all the folders set up the model can now be set. Figure 10 shows the model that was set. The asset
model includes all variables that are expected, their path and type. Setting up this asset model doesn’t
complete the process. The model now needs to be uploaded to the trinity Telecoms’ system.
Figure 10 - Asset Model set up in AirVantage
Figure 9 - Customer model search in AirVantage
9
The connection settings had to be configured before uploading the new asset model. Figure 11 shows
the connection settings and paths needed to send the information to the correct location.
All that remains is to upload the model to the server. On the overview tab of the UoSA model, there is
an option called “Upload model to the OperatingPortal”. Simply by selecting that the model will be
uploaded to the server, but that does not complete the process of setting up the database. The
information can now be sent by an asset (or simulator in our case) and received by the server, but the
information cannot be downloaded to the platform yet. A metric model at [15] has to be set up first.
3.2 Metric Model Setup
3.2.1 Goal
Currently, information is stored in the Trinity servers, but no information will be available to download
to the platform. The goal of the asset model is to bridge the gap between a hardware and software
engineer. A hardware engineer will usually send information through that is unreadable to an untrained
eye. The values that are passed to the server are often voltage values, longitude and latitude or any type
of values that will have to be adjusted before being able to use. The metric model will use the asset
model variables, but send them through a converter or mathematical equation before setting the
information as available to download.
3.2.2 Design
For the purposes of this project, no convertor or mathematical equations were used. With the device
simulator, the information that was sent was already in human readable form. None the less, the metric
model had to be set up. Appendix E4 shows the Metrics Maker used.
Figure 11 - AirVantage server connection settings
10
The Data Sources displayed on the left hand side of the Figure in Appendix E4 are all the variables
available from the asset model defined in section 3.1. On the right hand side are all the metric fields
already set up. A source from the asset model is dragged to the center and connected to a metric field
identifier. A name for the metric field is required. Each variable that we require information on needs its
own separate metric field. The name of each metric will be the name on the information displayed when
the asset’s information is called upon.
3.3 Device Simulator
3.3.1 Goal
The goal of the device simulator is to simulate information being sent from the asset to the server.
3.3.2 Design
A device simulator is required to send information to the asset model defined in section 3.1. There are
three different paths with different variables set up. The “/status/”, “/info/” and “/movement/” paths.
Each has individual variables associated with each path. A different message will need to be sent to the
server via the simulation device, for each of the different paths. Figure 12 shows a single device
simulator data message.
The number of entries can be set for every message. A timestamp has to be included with each message
sent to the server. The timestamp value that is sent is the number of seconds that have passed since
January 1st 1970. With the timestamp entry filled, all the other entries can be added that will be sent to
the specified path. In the case of Figure 12, the message is to be sent to the movement path of the UoSA
asset model.
The variables set to be sent to the movement path are:
The current speed the vehicle is moving at
The maximum acceleration in the past 30 min
The maximum speed the vehicle recorded in the past 30 min
The heading of the vehicle
Figure 12 - Device simulator message for the movement path
11
Figure 13 - Device Simulator connection settings
The other variables will be sent to their respective paths, using a different message. The info path will
only have to be set once as it is information that will probably not change soon. This path will contain
the information about the driver and the vehicle he is driving. The info path variables will also be added
to the asset descriptor explained in section 3.5.
To send the message to an asset, certain connection configurations have to be made. Figure 13 displays
the details.
The “server URL” is the path that Trinity’s servers are expecting information to be passed through.
The “device id”, is the identification number of the asset. The same message or information can be sent
to another asset by simply inserting a different asset’s identification number.
With those settings inserted, simply clicking ok will send the message. Confirmation that the message
was sent can be seen using one of Trinity Telecoms’ tools called Spyglass. Spyglass can be found at their
web portal [16].
3.4 URL Request Resources To request information from the Trinity Telecoms’ server, certain URL’s have to be requested. There are
different URL locations and each serve a different purpose, as the information varies. Within each URL is
contained different resource elements.
The URL’s used in the application will be discussed below.
A. http://smart.trintel.co.za/api/asset_management/assets/
B. http://smart.trintel.co.za/api/core/metric_values/?object_id=" + id_num +"&object_type=asset
C. http://smart.trintel.co.za/api/core/metric_values/?object_id=" +
id_num+"&object_type=asset&metric_id="+speed_id +"&limit=30"
D. http://smart.trintel.co.za/api/core/metric_values/?object_id=" +
id_num+"&object_type=asset&metric_id="+occu_id +"&limit=30"
3.4.1 URL (A): List of all assets
When URL (A) is requested, a detailed list of all the current assets and some information about each is
displayed. The information about each asset is called the asset descriptors. The id number of each asset
will eventually be used to call the next URL that will hold the metric model information that was set up
in section 3.2. A detailed description of the information displayed from requesting this URL can be found
12
in Appendix E2. Currently there are three assets set up for this project, but any number of assets will
yield the same results.
3.4.2 URL (B): Metric model information of a single asset
URL (B) uses a variable called id_num that will hold the specific asset’s id number. This number is
needed to determine which asset’s information is being requested. This URL requests a specific asset’s
metric model information. This is the information we will be using most often as it holds the information
required by the text based activity explained in section 5. A sample of the information from the
requested URL is too long to display here and can be found in Appendix E5. The metric model can be
updated and new fields can be added. In that case an extra field will be added to the information.
3.4.3 URL (B) & (C): Past 30 data points of a specific metric field
URL (B) and (C) are basically the same. There are two parts to both of these URL’s.
To use these URL’s two things are required. The one is the asset id number and the other is which metric
field to request the information from. The two metric fields that will be requested are the “current
speed” and “occupants” metrics. Each metric field has a specific metric id number. A sample of these
numbers can be seen in section 6.3.3.1.1’s Figure 26. They will identify the specific metric to be called
upon.
3.4.3.1 Requesting Information
The first part of using these URL’s will be to request the information from it. This request will return the
past 30 dataset points recorded to a single metric field.
3.4.3.2 Refresh Server Cache
One of the things noticed during the course of the project, was that the server was slow to update the
past 30 dataset points. The information that is slow to update is described in section 3.4.3.1. Thus the
second part is that this same URL will force a refresh of their system cache and possibly add more up to
date information to the dataset than what would have been present without the refresh.
The difference in the uses of the methods in sections 3.4.3.1 and 3.4.3.2 is only a different request that
is sent to the same URL. Section 3.4.3.1 uses a GET request and section 3.4.3.2 uses a PUT request.
These requests will be explained in section 4.2.1.2.
3.5 Asset Descriptor Tool
3.5.1 Goal
The goal of the asset descriptor tool is to add asset model variables to the additional fields on the asset
descriptor. The asset model variables that will be added are the variables from the “/info/” path, and
they don’t change often. This saves data, because it is information that will only have to be downloaded
once. This information that will be added is the way the application will be identifying each asset when
using the UI windows. The reason for this is that a vehicle registration number is more easily
comprehendible and user friendly than a 15 digit device number. A sample of what the descriptor will do
to the external fields is visible in Appendix E3. The metric fields that will binded are:
13
“ext_0” is binded to the name of the driver
“ext_1” is binded to the age of the drier
“ext_2” is binded to the registration number of the vehicle
3.5.2 Design
The reason only variables that don’t change often are added, is because the asset descriptor is slow to
update its information. It has a low priority on Trinity Telecoms’ system. By using the “AirVantage
Configuration Tools” again, and opening the previous project used to setup the asset model in section
3.1, we add an asset descriptor file to the asset folder. The new asset descriptor file can be seen in
Appendix E3. The Figures below shows the extended columns that was binded to certain variables
Appendix E3 shows that the external columns 0, 1 and 2 are each binded to an asset model value.
“ext_0” is binded to the variable at “/info/name/”
“ext_1” is binded to the variable at “/info/age/”
“ext_2” is binded to the variable at “/info/ registration/”
These variables are all set up in the asset model described in section 3.1. After the necessary changes
and bindings are made, the information is saved and uploaded the same way as in section 3.1. The
configuration to the server should already have been set up and is used again. A sample of the external
columns with the updated asset information can be found at Appendix E2.
4. Authentication Activity
4.1 Goal The goal of this activity is to determine the username and password credentials. Trinity Telecoms’
servers require authorization to connect to. The credentials are needed to authorize the header file sent
with every URL request. If no header is added or the wrong credentials are sent with the header, the
response to the request is “Authorization required” and no access is given to the information.
4.2 Research During the design and construction of this activity, various researches had to be made into some of the
components needed for this activity and some of the other activities to function properly. Three areas of
research were required.
i) A Web Service client was required that would enable the application to communicate with the
Trinity Telecoms’ servers. Two possible web service clients were identified. SOAP will be
compared against REST in section 4.2.1.
ii) User preferences and certain other information is needed to be stored in the memory of the
platform. Various storage methods were identified and will be discussed in section 4.2.2.
iii) A thread was needed to handle the lengthy and cumbersome process. Using a thread would
enable the process to run in the background and not obstruct the UI while it is being executed.
Two possible functions were identified and will be discussed in section 4.2.3.
14
4.2.1 SOAP vs REST
Choosing the correct Web interface is probably one of the most important aspects of designing the
application. All of the information is located on an external server and the correct web interface is
required to acquire the information. Two interfaces were identified as possible candidates.
SOAP is an acronym and stands for “Simple Object Access Protocol” and REST stands for
“Representational State Transfer”.
Areas of importance for this application are:
Simplicity.
Faster response time from server – in other words speed.
Low data usage.
Easy access to the response from the web server.
One of the first things to notice, is that REST APIs are very young compared to SOAP.
4.2.1.1 Background on SOAP
SOAP was developed by Microsoft in 1998. The protocols that SOAP uses was standardized in 2005 and
called version 1.2. It is still the current version being used today. SOAP is an xml based protocol and
there are three parts to any SOAP request being sent. Figure 14 displays the three areas.
As shown in Figure 14, there are three parts to any SOAP request. The request being sent as a whole is
called a SOAP envelope. The envelope defines what the message is and how it should be processed. An
optional header can be sent with the envelope. The header contains application-specific information
about the SOAP message. That could be anything from authentication to the object, payment
information, etc. The body contains the main payload of the envelope. The information contained in the
body is the information intended for the final destination.
The request that a typical SOAP interface would use is shown in Figure 15.
The line that is highlighted is the URL where the object information is stored. As can be seen, this is
quite a lengthy procedure to send a request.
Figure 14 - SOAP request message explained graphically
15
4.2.1.2 Background on REST
In 2000, a man named Roy Fielding wrote his doctoral dissertation and in it he introduced the term
REST. He used the term Representational state transfer to explain the architecture style of networked
systems.
Here is Roy Fielding's explanation of the meaning of Representational State Transfer:
"Representational State Transfer is intended to evoke an image of how a well-designed Web application
behaves: a network of web pages (a virtual state-machine), where the user progresses through an
application by selecting links (state transitions), resulting in the next page (representing the next state of
the application) being transferred to the user and rendered for their use." [4].
A small example of how it works would be to use a URL with resource information and execute it. The
URL can be executed from a web browser and if no authorization is required, the information can easily
be shown.
For instance in the case of this project:
URL: http://smart.trintel.co.za/api/asset_management/assets/
Execute that URL in a web browser and the browser will try and take you to the location where the
resources are stored. In this case, authorization is required. Enter the authorization and the following
information will be displayed in Appendix E2.
The information shown in Appendix E2 is in JSON format and only a partial piece of information
contained at that URL. JSON is an acronym and stands for Java Script Object Notation. In short, the
format of this information is the way it will have to be stored. There are built in functions to any java
compiler on how to handle this notation.
Figure 15 - SOAP request [17]
16
HTTP verbs are used to determine the type of request and how to execute the information. There are
four in total, GET, POST, PUT and DELETE. The following information about each verb was extracted
from [5].
GET – GET is one of the simplest HTTP methods. Its main job is to ask the server for a resource. That
resource may be an HTML page, a sound file, a picture file (JPEG) etc. We can say that GET method is for
getting something from the server. In GET method, the data we send is appended to the URL.
POST – The POST method is used to submit data to be processed (e.g., from an HTML form) to the
identified resource. The data is included in the body of the request. This may result in the creation of a
new resource, or the updates of existing resources, or both.
PUT – The PUT method is used to submit data to be updated (e.g., from an HTML form) to the identified
resource. Like the POST method, the data is included in the body of the request.
DELETE - The DELETE method is used to delete a specific resource.
Using REST to request or modify a resource is simply using an HTTP verb to identify the way to handle
the information, and the URL is the indication of where the information or resource is stored
4.2.1.3 Comparing SOAP and REST
There are large debates about the uses of these two web interfaces and pros and cons about each are
easily accessible on the internet. Extensive searching was done and the same strengths and weaknesses
were expressed at every turn. The pros and cons about each of the two web interfaces will be shown
below. The pros and were extracted from [6] and cons from [7].
SOAP pros
Rigid - type checking Development tools are complete and have been standardized. SOAP cons
Conceptually more difficult, more "heavy-weight" than REST
Expressed in more words than needed.
Harder to develop in Android, requires additional tools REST pros
Lightweight – no extra xml markup Human Readable Results Easy to build and incorporate- no additional toolkits required. REST cons
Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop
Tied to the HTTP transport model
17
4.2.1.4 Discussing strengths and weaknesses
All the above information was taken into account. The requirements for the web interface were:
Simplicity.
Faster response time from server – in other words speed.
Low data usage.
Easy access to the response from the web server.
As can be seen from the pros only, REST is a very lightweight option. There is not a lot of information to
be computed when trying to set up a request. SOAP on the other hand will have a more complex
solution.
A pro that SOAP has that could be useful in some systems, is error checking. In this application the
information being sent through is so simple and small that the chances of large errors are small.
A con that SOAP has that is not desirable is the fact that is very hard to develop and fully understand the
system. Some would say it is because of its outdated protocols, but there are large debates about it to
this day.
A con that REST has that is undesirable is that if the information being sent is security sensitive, it
doesn’t really provide safe messaging as there are no security protocols attached.
There are two other pros to using REST over SOAP.
1) Trinity Telecoms have both SOAP and REST interfaces for connecting to their servers, but the
response time for REST is faster as SOAP requires more protocols.
2) Android SDK has a built in REST package called apache that can be used.
If SOAP was to be used, an external package will have to be found for Android and imported
into the project.
4.2.1.5 Conclusion
Although SOAP has some advantages, the strengths of using REST are better suited for the use of this
project. A simple web interface is required as this application is built to be lightweight and data usage
friendly. The fact that REST is simpler, easier to use, has a response time that is shorter and the response
from the server when sent through an input stream reader will be in human readable form. The web
interface that will be used is REST.
Figure 16 - REST http example
18
Android uses a REST library called apache. An example of the library implemented in the application is
shown below in Figure 16.
4.2.2 Storage areas compared
User preferences and certain other information needed to be stored in the memory of the platform.
Various storage methods were identified and will be discussed. Consulting the official Android
developers’ website *8+ all the information below was extracted.
The following storage options were identified and descriptions provided for each option are:
Shared Preferences - Store private primitive data in key-value pairs.
Internal Storage - Store private data on the device memory.
External Storage - Store public data on the shared external storage.
SQLite Databases - Store structured data in a private database.
Network Connection - Store data on the web with your own network server.
Just by reading the descriptions provided, two possible candidates were chosen - Shared Preferences
and Internal Storage. The information that will be saved is private information that is needed to only be
used by the application. Information that will be stored are simple user preference choices and Boolean
flags that indicate what or which asset still needs to update to more up to date information.
4.2.2.1 Deeper Investigation into the two candidates
4.2.2.1.1 Shared Preferences
Shared Preferences are used to store small user preference type files. It is not designed to store large
amount of data and especially no structured data. This data will persist over user sessions with the
application and is very easily accessible. During testing, a problem that was noticed was that when the
platform was shut down it lost all shared preference data. With that being said, the only information
which is suited to be stored in this storage area is data that is only temporary.
The way it works is it uses a simple identifier to locate the specific data required. Each entry into that
identifier has different data. Example of the code used in an application:
//Setup SharedPreferences to save user data 1. SharedPreferences sp =getSharedPreferences("identifier", MODE_WORLD_READABLE); 2. SharedPreferences.Editor sp_Editor = sp.edit(); 3. sp_Editor.putString("Some identifier", enter_info); 4. sp_Editor.commit(); 5. sp.getString("Some identifier", null);
Line 1 defines under what identifier the information is to be stored or is stored and which classes can
read it.
Line 2 sets up an editor that will be able to edit the shared preference location defined in line 1.
Line 3 changes a string with a certain identifier and information in the location of the shared
preferences.
Only in Line 4 is the information changed in line 3 saved.
19
Line 5 will return the information or data stored at a specific identifier. If no information is stored at that
identifier, null will be returned.
4.2.2.1.2 Internal Storage
Files can be stored directly on the platform’s internal storage. These file are private to the application
and cannot be accessed externally, not even by the user. This is the default setting for this storage type.
The information is removed only when the application is uninstalled.
Storing and retrieving information on the internal memory is more complex than shared preference.
Storing information is relatively simple - retrieving the information is the complex part.
//Storing
1. FileOutputStream fos = openFileOutput(FILENAME, Context.MODE_PRIVATE);
2. fos.write(string.getBytes());
3. fos.close();
Line 1 starts the function needed to write the information to. It contains the file name to the location
where the information will be stored as well as what applications will be able to access the information.
Line 2 writes a certain string to the location indicated.
Line 3 simply closes down the file writing.
1. FileInputStream fIn = openFileInput(FILENAME+".txt"); 2. InputStreamReader isr = new InputStreamReader(fIn); 3. char[] inputBuffer = new char[20];
String return_string = ""; int charRead;
4. while((charRead = isr.read(inputBuffer))>0) {
5. String readString = String.copyValueOf(inputBuffer, 0, charRead); 6. return_string+=readString; 7. inputBuffer = new char [20];
}
Line 1 starts the function used to show where the information is to be read from.
Line 2 starts and input stream reader that will pass all information through.
Line 3 declares a simple array with twenty character spaces to hold information.
Line 4 sets up a loop that will continue to run, while the function isr.read(inputBuffer) does not return
the value “-1”. The function will return the value “-1” when the data character has reached the end,
otherwise it will return the value of the position of the character read last. It saves the information
currently being read through to the variable array “inputBuffer”.
In line 5 a string variable is used to temporarily store the information read from the. The copyValueOf
function uses three parameters to define what information is to be returned. The first parameter
(“inputBuffer”) is the string where the information is to be read from. The second parameter (“0”) is the
position at which the function should start copying the information. The last parameter is the variable
20
“charRead”. This is simply the end point where the function should stop copying. With that said, each
time the loop runs again, the function will copy an additional character, as long as there are lines left.
Line 6 uses the variable that will return the information, as the temporary variable in line 5 will be used
again.
Line 7 redefines the character array so it can be used again if needed.
4.2.2.2 Conclusion
It was chosen that the information that had to be saved will be split into two groups and that both
storage techniques will be used.
The information chosen to be saved in shared preference is all the Boolean update flags. It consists of
multiple flags that will be reset at a specified interval. That makes these flags temporary as the
information is never stored for longer than thirty minutes and thus doesn’t need to be held indefinitely.
The username and password will be stored in both storage areas, depending on the user options chosen.
The username and password is required with every REST request made as explained in section 4.2.1.2.
Thus the information will always be saved in the shared preference when the application is started. The
username and password credentials will be stored in the internal storage when the save preference is
chosen in the login screen as shown in the user interface section 8.2. This will enable the information to
be stored indefinitely, even after the platform has been shut down and restarted. The only other data to
be stored in the internal memory is the auto login user preference. This option is chosen when the user
wants the application to log in automatically. When this preference is selected the credentials are saved
in the internal storage as well.
4.2.3 Different thread types compared
If the cumbersome processing of information was done in the same thread as where the UI ran, then
there was a possibility that it could freeze and become unresponsive. Because of that reason research
had to be done into a method that would circumvent that scenario. A possible solution was found. Using
a second thread will enable the activity to do the processing in a completely different thread. With the
second thread in place, the user can simultaneously work with the UI and the chance that the
application could freeze or become unresponsive has been dealt with.
Two possible choices were identified. A basic second thread and the ASyncTask function. There are small
differences between the two. ASyncTask feels a bit more complex even though it helps with the
communication to the UI. Both of the options communicate with the UI using handlers.
According to the official Android development website [9], the definition of a handler is:
A Handler allows you to send and process Messages and Runnable objects associated with a thread's
Message Queue. Each Handler instance is associated with a single thread and that thread's message
queue. When you create a new Handler, it is bound to the thread / message queue of the thread that is
creating it -- from that point on, it will deliver messages and runnables to that message queue and
execute them as they come out of the message queue.
21
4.2.3.1 Using a plain second thread new Thread (new Runnable(){
public void run() { //run the processes needed in the thread here }
}).start();
Defining a new thread is easy enough and the code above showed how simple it is. Now to
communicate to the UI, a handler and a runnable has to be defined. A runnable is basically the new
process of information to run or send to the UI and the handler the method that activates the runnable.
Handler myHandler.post(TalkToUI); //A handler is needed to access the UI
The handler declared above, simply calls the runnable used to access the UI. The handler only sends
messages to and from different threads.
//When using a thread, the only way to get to the UI is by using a handler..Otherwise the UI is inaccesable
final Runnable TalkToUI = new Runnable() { public void run() { //run the method or process that has to communicate with the UI
}};
The code above is an example of a simple runnable used to communicate with the UI. When this
runnable executes its processes, it is already in the UI thread.
4.2.3.2 Using ASyncTask private class SomeTask extends AsyncTask<String, Void, Void> {
private final ProgressDialog dialog = new ProgressDialog(Main.this);
//Can access the UI here protected void onPreExecute() {
//Do a task that requires access to the UI. }
//Automatically done on worker thread (separate from UI thread) protected Void doInBackground(final String... args) {
//Do a task that is needed to run in a separate thread. }
//Can access the UI here protected void onPostExecute(final Void unused) {
//Do a task that requires access to the UI. }
}
As can be seen, ASyncTask handles the communication with the UI in two separate and small methods.
The method onPreExecute has access to the UI just before the thread is started and the method
onPostExecute has access to the thread just after the thread has finished executing.
4.2.3.3 Conclusion
Both are viable options and neither really has a pro or a con that the other doesn’t have. The only
difference and advantage that ASyncTask has is that it handles the communication with the UI thread.
Basically if you don’t want to get your hands dirty and don’t want to track and handle your own access
to the UI, ASyncTask is the option.
22
But by personal preference, it was chosen to use a separate thread and handle the communication with
the UI thread when chosen. There is always the possibility that the UI thread was needed before the
process is finished.
4.3 Design and Overview This activity was designed from the ground up. There are various methods that are used to make the
authorization activity work efficiently. When the application starts, a method called onCreate() is called.
This method starts all the code to run. There are three buttons set up in the UI. The first is a plain button
and used to initialize the authorization process. The other two buttons are check box buttons. They are
used to keep track of certain user set preferences. The first check box and preference is if the user wants
the information saved on internal memory of the platform. The second check box and preference is
used to determine if the user wants to skip the login next time, or better known as auto login. With auto
login checked, the next time the application starts and the credentials pass the authorization request to
the URL, the username and password is saved to the internal storage memory. Both of these
preferences - username and password and auto login- are saved on the internal memory if chosen.
Using this function will enable them to be easily accessed and checked next time the application starts.
Thus, close to the start of this activity, the preferences are checked. There are four scenarios on how the
application could execute:
1) If auto login is saved at application start, then the username and password is retrieved and
automatically sent through to the authorization method. A new thread is created for the
authorization process to run on. The reason for this is not to obstruct the UI if a lengthy process is to
be completed. Before the authentication process, a method locks the screen rotation to stop an
interruption of the process by orientation change. A handler is used to start a progress dialog to
display to the user that the activity is busy with the authentication process. Another method then
checks if the user is online and has access to the internet. If there is an internet connection, the
request is sent to the specified URL and checked if authorization is still required. If the credentials
passed the test, they are stored in two memory type places and they were described in section
4.2.2.1. The response from the URL will be the asset description of all available assets. This is saved
in a separate class that won’t be destroyed until the application closes. The next activity, which is
the activity that sets up the tabs and navigation, is called.
2) If the application starts and auto login is not checked, the activity checks if the save preference was
checked or not. In the case that the save preference was checked, the username and password
credentials are retrieved and added as text to the edit boxes. Edit boxes, are a type of text box that
the user can type information in using the platform. There are two boxes set up, one for the
username and one for the password. Check option (3) for further information.
3) If the save preference was not checked in the previous application run, the edit boxes are left
empty. In both cases, when the login button is pressed, the activity retrieves the current information
in the two edit boxes. That information is used for the username and password credentials. The
same authorization process as option (1) is followed. A new thread is created for the process to run
23
on. The reason for this is not to obstruct the UI if a lengthy process is to be completed. Before the
authentication process, a method locks the screen rotation to stop an interruption of the process by
orientation change. A handler is used to start a progress dialog to display to the user that the activity
is busy with the authentication process. Another method first checks if the user is online and has
access to the internet. If there is an internet connection, the request is sent to the specified URL and
checked if authorization is still required. If the credentials passed the test, they are stored in two
memory type places. Also, the response from the URL will be the asset description of all assets. This
is saved in a separate class that won’t be destroyed until the application closes. The next activity,
which is the activity that sets up the tabs and navigation, is called.
4) The only other time this activity is called is from the “info” activity described in section 5. In this case
the activity must disable the auto login feature if it is selected. After the auto login feature is
disabled via a Boolean flag, the activity can follow option (2) or (3).
5. Info tab Activity
5.1 Goal An activity was required to display the information from the server in a plain text based window. This
activity was created with that idea in mind. The main goal was to display the asset’s information in text
only and use as the smallest amount of data possible to achieve the goal. The main goal of this activity
was to control the selection of the different assets.
5.2 Overview This activity was designed from the bottom up and various methods and functions were used to make
this activity function efficiently. When the activity starts, a method called onCreate() is called. This
method starts the code to run. This activity is controlled by three main elements. All through this
activity, whenever the application is required to download new information, a progress dialog is
displayed.
5.2.1 Scheduled Timer
The first is to start a scheduled timer that will execute its process at a fixed interval. This is almost the
backbone of the application. A method is used to check a flag in shared preference to see if there is a
timer currently active on the activity. If it reads that there is, no timer will be created, but if the flag
suggests that there is no timer currently active, the activity will start a new scheduled timer.
This timer sets the flags that tells the application when the asset’s update flags needs to be reset. This
scheduled timer is almost never cancelled while the application is still running, even when a new activity
is started and this activity is sent to the background. There are two scenarios where the timer will be
cancelled. The first is when the authentication button is pressed. In that case the timer is cancelled and
24
the authentication activity explained in section 4 is called. The other scenario is when a different update
time is selected and is explained in section 5.2.4.
When time has expired on the timer, a method is called that does all the work. The method checks a
Boolean flag that would indicate if the application is doing heavy processing somewhere. If it detects the
flag as true, the method will wait until the flag is false to continue its process. A loop is used to set all the
arrays containing the Boolean update flags.
Following the update flags being set, the method now checks which tab is currently active. If the method
detects that the info tab is currently selected, it will start the update process. A method is called that will
be used to download new information and update the UI. A handler is used to access the UI and create a
progress dialog. The method that is called will be described in section 5.2.2.
5.2.2 Connect and update
This is the second main method or element in this activity and is called multiple times and from different
processes. The function of this method is to handle the process between the download of information
and the UI being updated.
Immediately after this activity is called the screen rotation is locked. Currently, the application is written
to handle the screen rotation manually. The next phase is to initiate the download of information from
the Trinity Telecoms’ server. The information to be downloaded is the metric model information of the
currently selected asset as described in section 3.2.
The download of information is made possible by the REST apache library and explained in section
4.2.1.2. First the identification number is retrieved from the saved JSON Array containing the asset
descriptors. The identification number is required to direct the URL to the correct resource. The Http
client and the GET request is set up using the URL set out in section 3.4.2. Shared preference is used to
retrieve the username and password credentials from the memory. The credentials are required to
enable the resource to be downloaded as the servers have an authorization block. The credentials are
added to a header file and the header file is added the GET request already set up. After executing the
request there is a response received from the server. In this case the application has already tested the
credentials in the authorization tab explained in section 4, thus the credentials are correct. The response
will be sent to an input stream reader and a human readable string is returned containing all the
information contained at the URL. The information in Appendix E5 shows the typical asset information
contained within a URL. The string received from the input stream reader is used to set up a JSON Array.
The newly created JSON Array is sent to another method where all the clutter from the JSON Array is
removed and a new JSON Object is created containing only the information that is required. That newly
created JSON Object is stored in an object array (this object array will be used often and to avoid
confusion it will be given a name), called Metric Model Info. This object array will store this information
for every asset as long as this information remains valid. Specific assets’ information will be used to
update the UI text views with their relevant information.
A handler is used next to access the UI. A handler can only be used to access the UI when threads are
used. The timer explained in section 5.2.1 runs on a separate thread and the only other time this
25
method is called is when the asset is changed using the spinner or better known drop down bar. After
the asset changes a thread is created and used to call this method. This is explained in section 5.2.3. A
handler is required to access the UI as this method is only called from threads running alongside the UI
thread.
The JSON Object is retrieved from a method explained earlier in this section. That method holds the
asset resource information after all the clutter is removed in an object array. The text view boxes are all
updated with new information and are shown in the UI section 8.3.1.
5.2.3 Spinner setup (a.k.a. drop down bar)
The function of the spinner is to facilitate a way to change the asset currently being viewed. At the start
of this method, there is a check to see if it is the first time this activity is starting. In the case that it is the
first time this activity is started up, update flags are all set. There are three assets that are set up. To use
an example, this application has three assets set up. Because there are three assets, each array will be
set up to hold three flags. Each asset will hold its own update flag. The initial states of the flags are also
set.
Update_info [true, true, true] - This will control the info and maps tab update fields.
Update_bar_graph [true, true, true] – This will control the update of the occupants data.
Update_line_graph [true, true, true] – This will control the update of the current speed data.
Next the registration numbers are retrieved from the asset descriptor array set up in the authentication
activity explained in section 4.2.3. The registration numbers are used to define the different assets in the
spinner and is shown is Figure 17 below.
Lastly a listener for the spinner is set up. This enables the activity to sense when the spinner has been
selected and also when a new element is selected. When an item is selected, the listener now checks if
the asset’s selected update information flag is true. There are three scenarios that can play out.
Figure 17 - Spinner drop down example containing registration numbers
26
The first is where the asset requires an update and it is the first time that this activity runs. In this case,
when the activity runs for the first time and the spinner is set up for the first time, it default selects the
asset in the default position. Because it selects and registers that the selected item has changed, the
activity wants to execute the process contained within. For that reason, the activity has a check that
only proceeds if it is the first time it runs. If the check returns that it is true and it is the first time this
activity runs, the Boolean flag that was just checked for is set down and activity continues skipping the
updating process.
The second scenario is when the asset selected requires an update and the process has been running for
a time. In this case when a new item is selected, the process will call the method that will start a new
thread to run the lengthy process of downloading and updating the UI. Within the thread the method
explained in section 5.2.2 (connect and update) will be called to handle download the new information
and update the UI.
The third scenario will be when the check returns that no update of the asset’s information is required.
In this scenario the information has already been downloaded and stored. The Scheduled timer has not
reached zero yet, so the information is still relevant. In this case the UI will just be updated with
information already saved in the object array. The JSON Object is retrieved from the object array called
Metric Model Info described in section 5.2.2. It will contain the information needed to update all the
text views on the UI window.
5.2.4 Seekbar used to control the update time
The seekbar is used to enable functionality of changing the update time. The reason for this addition is
to enable the user to exert a small amount of control over the amount of data used by the application.
When the activity runs for the first time, the time set in the previous run of the application is retrieved
from the internal storage and the timer is set up with this value. A checkbox and listener for that
checkbox is used to control when the seekbars are accessible. Figure 18 shown below is an indication of
the seekbars used as well as the checkbox that controls when they can be handled. The checkbox has to
be deselected to activate the process of saving and changing the update times. Once the check button is
deselected, the seekbars are inaccessible and cannot be changed.
Figure 18 - Seekbar and controlling checkbox
27
There are two seekbars. Currently only one seekbar is working and can set the update time. The server
to platform update time can be set, but not the asset to server time. It is one of the recommendations
for future development on this application.
When the progress of the seekbar is changed, it is sent through a method that will determine the time
and relation to the other seekbar. The seekbar update times are currently set so that the server to
platform update time can never be faster than the asset to server time. If it could be then the platform
will download information from the server that the platform already has, as the asset has not yet
updated its new information. The update times that are currently accessible are: 1 minute, 2 minutes, 5
minutes, 10 minutes, 15 minutes, 20 minutes and 30 minutes. The activity is built to have a default
update time of 1 minute until changed by the user.
When the checkbox is unchecked, the current value of the seekbar is checked against the value stored
when the checkbox was first selected. The function of this to make sure that the progress has changed.
If it hasn’t, no additional processes run. In the case that the value of the seekbar has changed, for
instance from 1 minute to 2 minutes, the timer has to be restarted. A different method is called that
saves the current time set by the user in the internal storage.
Just before saving the newly set value by the user, the current timer is stopped and aw timer is started
with the new value. This will force the activity to immediately update the currently selected asset’s
information.
5.2.5 Research
The research done with for this activity is already described in section 4.2 and the rest was on how to
communicate with the UI elements. That will be explained in more detail in the UI section 8.3.1.
6. Graph tab Activity
6.1 Goal The goal of this activity is to display the status of the asset over the past 30 data points obtained by the
server. There are two metric model fields that will be displayed here, the “occupants” and “current
speed” fields. Both graphs will be displayed when in portrait orientation, but when in landscape
orientation a single graph will be displayed and will fill the whole screen. Using a button the user will be
able to switch between the two graphs.
6.2 Research A library was needed to be able to draw different graphs with data recovered from the Trinity Telecoms’
server, as Android does not have a built in graphing library. Research was done over the internet about
viable options. Four possible options were identified and they are:
Chart Droid
AChartEngine
Google chart API
GraphView
28
Many other options were explored, but a free charting library was needed.
6.2.1 ChartDroid
According to their website [9], ChartDroid is an Intent-based "library application" for static chart and
graph generation on Android. It can graph/plot/display numerical data in many representations. As a
developer, you need only to have your users install the library, then implement a Content Provider. Figure
19 is an example of what the graph could look like.
6.2.1.1 Discussion
A positive point for this charting library is that it has quite a large community following, but the problem
with ChartDroid, is that it is an additional application that the user will have to install on the platform as
the additional application draws the graphs. Another big drawback is that it uses intent to start a new
activity. The problem with that is that when an intent is used, it will take over the whole screen. The
“back” button will have to be pressed to enable the user to return to the application. Because of these
reasons, ChartDroid was removed as a possible candidate.
6.2.2 AChartEngine
According to their website [10], AChartEngine is a charting software library for Android applications.
Mobile phones, tablets and other gadgets running Android will benefit of this charting library. Figure 20
below is an example of a possible AChartEngine chart.
Figure 19 - ChartDroid example [9].
Figure 20 - AChartEngine example
29
This chart engine is a simple jar file to be downloaded and added as an external library to the project in
eclipse. This chart can return an intent or a view of the chart that is to be drawn and is a great positive
point. This will remain one of the possible candidates.
6.2.3 Google chart API
According to Google’s website *11+, the Chart API provides a simple way to create image charts of
various kinds by sending a formatted URL that includes both the data and chart configuration options to
a Google server. Figure 21 below is an example of a Google chart graph.
6.2.3.1 Discussion
This option was immediately removed from viable options. This application already uses a large amount
of data to download every asset’s information to generate locations and areas when using the maps tab.
Thus a charting tool that requires an internet connection was outside the design properties required for
this application.
6.2.4 GraphView
According to their website [12], “GraphView is a custom View which easily creates Graphs. Just supply
an array of values and they will be displayed in the graph. The graph automatically scales the values
between the highest and the lowest in the supplied set”.
This charting engine uses an external library that can be downloaded and added to the project in eclipse.
This charting engine was kept as a viable option. Figure 22 is an example of a GraphView graph.
Figure 21 - Google chart API example [18]
Figure 22 - GraphView example [12]
30
6.2.5 Discussion of options left
The options that are left are, AChartEngine and GraphView. Google Chart API was removed from viable
options because it requires an additional internet connection and will require more data usage from the
user. ChartDroid was removed as an option as it requires the user to download an additional application
to draw the charts while it is running in the background.
Both the options left are viable free charting engines. Upon further research, it was noticed that
AChartEngine has a larger community following and has more tools that would interaction with the
chart. In other words handle the name change, adds grids, grid colors etc. AChartEngine is also more
visually pleasing.
Two weaknesses that GraphView has, is that it can only draw a bar and a line view. AChartEngine can
draw pie, line, bar and scatter charts. The other downside to GraphView is that the developer is required
to make an about page that keeps track of the uses of its engine. Also if the application is eventually
launched at the Android market and charges a fee, a donation has to be made to the author of
GraphView.
For those reasons mentioned, AChartEngine was chosen. At the time that the application was being
designed and constructed the current version available was 0.7 and it was launched 30 July 2011.
Currently there is a newer version, version 1.0 and was released on 30 March 2012. This will be a
recommendation of further work on this application.
6.3 Activity flow and Overview A design decision was made and the types of graphs for the two fields that were to be shown, was
chosen. The “current speed” field was chosen to be displayed in a line graph and the “occupants” field is
displayed in a bar graph. The AChartEngine library was downloaded in jar format and added as an
external library to the application project.
The only way this activity can be accessed is through the selection of the “Graph” tab at the top of the
window. Figure 23 shows the tab being selected.
This activity is a relatively simple one. The xml view explained in the UI section 8.3.2, currently holds two
empty linear layouts, with each taking half the screen. The idea behind this is to display both of the
graphs in one single window.
6.3.1 Scheduled Timer
When the activity starts and onCreate() is called, a scheduled timer method is called. In in shared
preference there is a flag that holds a Boolean flag that defines if there is a timer currently active. If a
timer is active in this activity it returns true and no timer is created. If no timer is active and the method
returns false a timer will be created and the process continues. First the scheduled timer method checks
Figure 23 - Graph tab selected
31
the shared preference flag and if no timer is currently active, a scheduled timer is started with a ten
second delay. This timer will have a ten second schedule and will check if the currently selected asset’s
update graph flags defined in section 5.2.3 are true. If not the activity will continue as normal until
another ten seconds have passed and the timer checks the update flag once again. That process
continues until the activity is sent to the background. When that happens the timer is cancelled.
This is the case when the update flags for both the currently selected asset’s line and bar graph are true.
After check has passed, the process starts to run and first to check is if the activity is currently updating
the UI. In that case it will have to wait until it stops updating the UI. Next a method is called that will do
all the heavy lifting within this activity. The method Update Graphs is explained in section 6.3.2.
6.3.2 Update Graphs
This method detects the screen orientation of the platform and sets the content view accordingly. There
are two separate xml files set up. One is for portrait orientation and the other for landscape orientation.
It uses the window manager to define the width and height of the platform’s window and the tests if the
width is smaller than the height. If it is smaller the platform is in portrait mode. If it is larger, the
platform is currently in landscape orientation. The window is now assigned an xml following the results.
There are now two scenarios that the activity can follow.
6.3.2.1 Portrait Orientation
The first is if the platform is currently in portrait mode. The portrait xml file is used and a method is
called that creates both the graphs. When the new method starts, the screen orientation is locked,
because the application will be downloading from the internet and an interruption would be bad.
Controllers to the two linear layouts are created. All views are removed from the layouts as they will be
used multiple times. Another class was created and will control the drawing of each graph using the
AChartEngine researched in section 6.2.2. That method will be explained in section 6.3.3. Separate
sections will explore the creating of each graph view and they are explained in sections 6.3.3.1 and
6.3.3.2. After the views are returned from the class creating them, they are each added to a separate
linear layout. Both the graphs will now be displayed on the activity window as shown in Figure 24 below.
Screen rotation is unlocked and the activity waits for its next command. A more in depth explanation
about the user interface is available in section 8.3.2.
Figure 24 - Graph tab in portrait mode
32
6.3.2.2 Landscape Orientation
The other scenario is when the platform is in landscape mode. A different xml is loaded and was
specifically created to facilitate the need a single larger graph when in landscape orientation. In this
orientation the activity will only display a single graph, either the line or the bar graph and a button is
used to switch between the two. A single linear layout is used to display the graph. A check is made to
see if the button has been pressed and if the flag is true and the button was pressed, only then is the
view at the first location removed.
The reason for that is that the button is placed over the graph view as shown in Figure 25. If all views are
removed, the button will have to be recreated as it is part of the layout and a view.
Like before, the screen orientation is locked to not disrupt the connection to the internet. A Boolean flag
is used to keep track of which graph to draw first. The view of the graph that is needed to be drawn is
retrieved from the method explained in either section 6.3.3.1 or section 6.3.3.2. When the view is
received it is added to the linear layout. Next the controller for the button is defined and the button is
brought the front. If the button is not brought to the front, the button can’t be seen. Screen rotation is
unlocked and the activity waits for its next command.
6.3.3 Drawing of a graph
A separate class was made to handle the creation of the two types of graphs. A separate method was
created, one for each of the graphs. They are both basically the same except for small differences.
Separate update flags are used for each for each graph. One set is to define when to update the bar
graph and the other is to define when to update the line graph. They are explained in section 4.3. Two
normal arrays are also used to store only the values of the dataset information obtained from the
server’s resource information.
6.3.3.1 Drawing the line graph
The normal integer array is set up to use thirty data points and is reset to zero for all thirty elements.
Next the method checks to see if the current asset selected needs to update its current speed data from
the Trinity Telecoms’ server.
6.3.3.1.1 Update information
In the case that the flag is true and it needs to update, a method is used that forces an update of the
information currently stored in trinity telecoms’ database. The reason for this is that this function on
their server is sometimes slow to update the information that is currently available. The way the method
does this, is by using the REST method explained in section 4.2.1.2 and the PUT request. The request is
Figure 25 - Graph tab in landscape mode
33
sent to the URL (C) explained in section 3.4.3.2. After their cache has been forcibly refreshed, the new
data can now be retrieved once again using the REST method but with a GET request and an
authorization header.
The response is then changed into human readable form and sent through a method to remove all the
unnecessary information. The information we have now is a dataset of the past 30 data points similar to
Figure 26 shown below. The figure shows the “occupants” metric model that contains only a few values,
but in reality it will contain up to thirty elements. The “current speed” dataset will look the same, just
with different values. The information displayed in Figure 26 is also the human readable string we
received after sending the response through an input stream reader. A flag now indicates if the activity
is trying to add data to draw the line or the bar graph. When it has indicated that the line graph is busy
with its process, the data will then be saved in a JSON Array containing JSON Array elements. The JSON
Array elements are every asset’s current speed data as received from the server. The data is stored just
in case that the activity needs the information again.
This information will be scanned and only the values will be extracted from it. Each value will then be
added to an array from the last element, to the first. Thus the last element in the array that will hold the
data is the first element of the information contained in Figure 26. The highlighted data in Figure 26 is
the data that the application needs to extract.
Now that the data needed to draw the graph is in an easy accessible array, we can continue creating the
line graph view. Drawing the line graph is similar to drawing the bar graph, with only the limits that
differ. The rest of the process is explained in section 6.3.3.3.
Figure 26 - Occupants dataset example
34
6.3.3.1.2 Setting the speed data set array
The other scenario is when the activity does not need to update the information. This will happen when
the information has already been downloaded and stored. The main timer from the info tab activity in
section 5 has also not reached zero and reset all the update flags. In this case the speed dataset array
will be recreated using the JSON Array element corresponding to the currently selected asset. Just as
before the “current speed” information similar to the information shown in Figure 26 will be scanned
and only the values will be extracted from it. Each value will then be added to an array from the last
element, to the first. Thus the last element in the array that will hold the data is the first element of the
information contained in Figure 26. The highlighted data in this figure is the data that we want to
extract.
Now that the data needed to draw the graph is in an easy accessible array, we can continue creating the
line graph view. Drawing the line graph is similar to drawing the bar graph, with only the limits that
differ. The rest of the process is explained in section 6.3.3.3.
6.3.3.2 Drawing the Bar Graph View
Drawing this view is almost the same as drawing the line graph view. There are only small differences.
The activity resets a different array. This array will hold the bar graph data set data that will be used to
draw this graph. All thirty elements are reset to zero. Once again a check is made to see if an update flag
is true, but this time it is the update bar graph array that is checked.
6.3.3.2.1 Update information
Same as before, this is the case where the flag is true and it needs to update. A method is used that
forces an update of the information currently stored in trinity telecoms’ database. By using the REST
method explained in section 4.2.1.2 and the PUT request. The request is sent to the URL (C) explained in
3.4.3.2. After their cache has been forcibly refreshed, the new data can now be retrieved once again
using the REST method but with a GET request and an authorization header.
The response is then changed into human readable form and sent through a method to remove all the
unnecessary information. The information we have now is a dataset of the past 30 data points as shown
in Figure 26 above. Figure 26 shows the “occupants” metric model that contains only a few values, but
in reality it will contain up to thirty elements. The information displayed in this figure is also the human
readable string we received after sending the response through an input stream reader. A flag now
indicates if the activity is trying to add data to draw the line or the bar graph. When it has indicated that
the bar graph is busy with its process, the data will then be saved in a JSON Array containing JSON Array
elements. The JSON Array elements are every asset’s occupants data as received from the server. The
data is stored just in case that the activity needs the information again.
This information will be scanned and only the values will be extracted from it. Each value will then be
added to an array from the last element, to the first. Thus the last element in the array that will hold the
data is the first element of the information contained in Figure 26. The highlighted data in this figure is
the data that we want to extract.
35
Now that the data needed to draw the graph is in an easy accessible array, we can continue creating the
bar graph view. Drawing the bar graph is similar to drawing the line graph, with only the limits that
differ. The rest of the process is explained in section 6.3.3.3.
6.3.3.2.2 Setting the occupants data set array
Just as with the line graph view, this is the other scenario and this happens when the activity does not
need to update the information. This will happen when the information has already been downloaded
and stored. The main timer from the info tab activity in section 5 has also not reached zero and reset all
the update flags. In this case the speed dataset array will be created using the JSON Array element
corresponding to the currently selected asset. The information contained in Figure 26 will be scanned
and only the values will be extracted from it. Each value will then be added to an array from the last
element, to the first. Thus the last element in the array that will hold the data is the first element of the
information contained in Figure 26. The highlighted data in this figure is the data that we want to
extract. Drawing the bar graph is similar to drawing the line graph, with only the limits that differ. The
rest of the process is explained in section 6.3.3.3.
6.3.3.3 Creating Graph View
A time series is created and given a name. The thirty elements defined in sections 6.3.3.1 and 6.3.3.2 are
added to the time series. A multiple series dataset controller is created and the time series is added to
it. A series renderer is now created and this controls the UI elements concerning the line or bar that will
be drawn. For instance, the renderer will control the color of the line or bar, the size of the values etc. A
multiple series renderer is also created – this will control the background elements of each graph. For
instance a grid can be added, zoom can be enabled or disabled, the range of the grid can be set etc. To
the multiple series renderer is added the single renderer.
After all those elements are set, the AChartEngine uses a function called ChartFactory to get the relative
view from it.
m_speed_View = ChartFactory.getLineChartView(context, dataset, mRenderer);
m_occu_View = ChartFactory.getBarChartView(context, dataset, mRenderer, null);
The views that are received from the functions above, are returned within their individual methods. The
view for which ever graph was requested will now be added to a linear layout and displayed on the UI
window as shown in Figure 24 and 25. A more in depth explanantion about the user interface elements
are given in section 8.3.2.
7. Maps tab Activity
7.1 Goal The goal of this activity is to display the location of a single asset as well as all the assets on a map. The
longitude and latitude information downloaded from Trinity Telecoms’ server will be used to determine
the location. The drawable icon as shown in Figure 27 will be used to display the location of an asset.
36
7.2 Research A maps engine and view was required to display a location on a map. Google Maps API was identified as
a viable option because of its popularity. It is also recommended by the official Android developers’
website and there is a built in Android library to facilitate the use of the maps API. Another positive
point is that there is an extremely large community of people that have used this API and because of
that help would be easily accessible. Thus the Google Maps API was chosen as the maps engine.
A second area of research was required, as the activity required a method to be able to draw an icon on
the map to display the location of an asset. Itemizedoverlay was identified as a viable option and
researched further in section 7.2.1.
7.2.1 ItemizedOverlay
This was identified as a viable option to use and draw the relative location on the map via an icon.
Itemizedoverlay is a subclass of overlay and the whole idea was to float an icon over the map at a
specified location and the overlay class makes this possible. When using itemizedoverlay all the items
that needs to be drawn is added to a single group. That group is then added as a single overlay over the
map and will indicate the locations of the different assets.
7.3 Setting up google maps To be able to add google maps API and use it in Android requires a few steps to be handled first.
First order of business is that a Maps API key is required. To get a map key, some information about the
developer’s computer is required. The following two steps are needed to complete the registration.
An MD5 fingerprint of the computer that will be using the key is required.
Registering the MD5 fingerprint with the Google Maps Service.
Add the key to the application.
Enable internet connection in Android Manifest.
7.3.1 Acquiring the MD5 Fingerprint
First, the default debug keystore location is required. To see this eclipse must be open. If going to
Window ->Preferences ->Android -> Build. Figure 28 shows the location of the keystore and also where
to find it.
The location shown in Figure 28 will be required to complete the process of obtaining the MD5
certificate fingerprint.
Next command prompt is needed. The location has to be changed to the location where the java
runtime environment is installed. In this case jre6 is installed and located at:
Figure 27 - Pin used to display location
37
Location = C:\Program Files (x86)\Java\jre6\
Changing it to that location = cd C:\Program Files (x86)\Java\jre6\
The acronym “cd” is short for change directory.
Next the location of the executable file keytool.exe needs to be entered. In most cases the executable
file will be found in the bin folder. Figure 29 shows the process in command prompt.
Next the keytool.exe file has to be used alongside a command line. The complete command that must
be entered in command prompt is:
Keytool.exe –list -alias Androiddebugkey -keystore C:\Users\Vlieg\.Android\debug.keystore -storepass
Android -keypass Android
The whole line above must be completed with no spaces between the “-“ and the words following the
dash. The storepass indicates the password needed when asked for the store password and the same for
keypass. “Android” is the password to both those keys when requested. Figure 30 shows the above line
being entered and the response received.
Figure 28 - Default Debug Keystore location
Figure 29 - MD5 key in command prompt
Figure 30 - Location of keytool.exe in command prompt
38
This MD5 fingerprint is different on every computer. When a new windows or operating system is
installed on the computer, a different MD5 fingerprint is generated.
7.3.2 Registering the MD5 fingerprint with the Google Maps Service
To register the MD5 fingerprint, a google account is required. If the developer does not have an account
with Google, one will need to be created.
To register the key, the key will need to be added at the following web address:
https://developers.google.com/Android/maps-api-signup
Figure 31 above is an indication of what it will look like when the key has been entered. After clicking
Generate API Key a window will show the new key that was created and also a sample of how to
implement it in the developing portal – in this case java and eclipse.
Figure 32 below is an indication of what the window will look like after the process is successful.
7.3.3 Adding the key to the application
The way to add the new Android Maps Key to the application is to insert it in the xml view that will be
displaying the map. Figure 33 shows the xml view and Figure 34 shows the location where the key is
stored.
Figure 31 - Registering the MD5 fingerprint
Figure 32 - Window after Successful registration of MD5 fingerprint
Figure 33 - Xml file containing the Google Maps API key Figure 34 - Google Maps API ley stored in Strings location
39
Figure 34 is the location where the key is stored in this application. Android has a directory called
“Strings” that can store a large amount of data. This data can only be changed from the developer’s
portal and can never be changed in any of the activities or processes.
7.3.4 Enable internet connection in Android Manifest
An internet connection is needed to be set up to enable Google Maps to function. In the case of this
application multiple systems require the use of the internet, thus access has already been set up as seen
in the Android Manifest (section 2.1). The Google Maps API is now ready to be used in the application.
7.4 Design and Overview This activity was designed from the bottom up. There are three objectives that were identified and had
to be implemented into this activity.
1) Display a single asset’s location.
2) Display all the asset’s locations.
3) Update the information automatically when the main timer has expired.
7.4.1 ItemizedOverlay
A new class was needed and extended the itemizedoverlay library. There are three small methods that
control the itemizedoverlay class. The three are:
addOverlay – This method adds an overlay item to the overlay arraylist.
Populate now – This forces the activity to add all the items currently in the arraylist to the map. The
map is still needed to be refreshed.
onTap - This method handles the processes after one of the assets were tapped on.
7.4.2 onTap
This is the only method long enough to validate an explanation. This method is called whenever any of
the assets are tapped on. When they are tapped on or selected, the item number of the item selected is
sent to this method. The items are added in the same order as the rest of the application, so no
confusion about which asset is which. The item at position 0 here will be the same asset as in the default
spinner position explained in 5.2.3. This method now checks a flag that will indicate if all the assets are
displayed or only a single one.
In the case that all the assets were selected, it uses the item number just received to retrieve the JSON
Object containing the selected asset’s information. Using that asset’s information, the “Current Speed”,
“Heading” and “location” data is extracted and displayed to the user in a Toast message. A toast
message is a small overlay textbox over the UI window and will temporarily display information.
In the case that only a single item is being displayed and this asset has been displayed before, the
method then retrieves the JSON Object of the asset currently selected in the spinner found in the info
tab activity, section 5.2.3. Once again, using that asset’s information, the “Current Speed”, “Heading”
and “location” data is extracted and displayed to the user in a Toast message. A toast message is a small
overlay textbox over the UI window and will temporarily display information.
40
7.4.3 Overview - Starting the activity
This activity can only be accessed by tapping on the “Maps” tab at the top of the UI window. Figure 35
displays what it looks like.
At the start of the activity onCreate is called once again. The zoom functions are enabled and satellite
and traffic modes are disabled. The toggle button controller is created and a listener is set up. There are
three scenarios of how this activity can execute its processes.
1) Via the first run and creating single asset on the map view.
2) Via the toggle Button to switch views between displaying all the assets or just a single one.
3) Via the timer that will indicate when there is new information to be downloaded. The activity will
update the information and redraw the view automatically.
7.4.3.1 Scenario 1 – The first run of the activity
The first check to be executed is to check if the toggle button flag is currently true. This will define which
view will be drawn. The same method is used to house both the different choices – drawing a single
asset and drawing all the assets. A different Boolean flag is sent to the new method. This method will
create a new thread in which to execute the new processes.
In the case that the check is true, a false flag is sent to the method explained in section 7.4.3.2 and
defines that all the assets must be drawn.
In the case that the check is false, a true flag is sent to the method explained in section 7.4.3.2 and
defines that a single asset must be drawn.
7.4.3.2 Running the Thread
A true or a false Boolean is received whenever this application is called. That Boolean will define if a
single asset must be drawn or if all the assets must be drawn.
After the new thread is started, the screen rotation is locked, because there is a possibility that the
activity will need to connect to the Trinity Telecoms’ server to download more up to date information.
All the current overlays are retrieved and cleared of all old data. Now the Boolean sent to the method is
checked. If the Boolean received is true, section 7.4.3.2.1 is called. If the Boolean is false, section
7.4.3.2.2 is called.
7.4.3.2.1 Draw Single Asset
In the case that it was true, the activity will draw only a single asset on the map view. A new method is
called that will continue with the process of drawing the single asset’s location on the map view. The list
containing all the overlays are retrieved and the drawable to be used to indicate the location of the
asset is set. The drawable that will be used is shown above in Figure 27.
Figure 35 - Maps tab selected
41
The JSON Object containing the asset currently selected in the spinner from the info tab activity is
retrieved. This Object contains all the necessary information to draw the asset’s location. All that is
needed is the longitude and latitude variables and they are extracted from the JSON Object. The
longitude and latitude when extracted is in double format and need to be changed to integer format.
They are multiplied with 1x106, as longitude and latitude coordinates are always an eight digit number.
The new integer longitude and latitude values are used to create a geopoint. A geopoint is basically a
fully georeferenced point that can easily be attached to a map to indicate a location.
The new geopoint is added to an overlay item and then added to the itemizedoverlay and populated.
This means that the activity will now add all the elements that were contained in the itemizedoverlay
and drawn them on the map view.
A map controller is now created and used to animate or move the map to the new location just set by
this method. The zoom level is set to 17, which enables a close view, yet far enough to be able to see
where the asset is in relation to its surroundings. Figure 36 below shows the product of this method.
7.4.3.2.2 Draw All Assets
In the case that the Boolean received when the method was called was false all the assets will need to
be drawn on the map view. This method is very similar to the method described in 7.4.3.2.1. The list
containing the overlays are retrieved and the drawable used to indicate the location of the asset is set.
The drawable that will be used is shown in Figure 36.
Here is the first difference. There is now a check for a Boolean update flag that will determine if all the
assets have been updated to the most up to date information. If they have been and none of the assets
are required to download new information the process continues. In the case that one or more of the
assets are required to download new information, a new method is called that will facilitate that need. A
loop is created that will check if each element’s update info flag explained in section 5.2.3 is true. If it is
not true, the loop will move on and check the next asset’s update info flag. In the case that an asset’s
update info flag is true and it is required to download new information, the REST function with a GET
request is sent to the URL described in section 3.4.2. The response from the server is then sent through
Figure 36 - Single Asset’s location displayed in a Map
42
another method that will remove all the clutter and unnecessary information. What is left is a newly
created JSON Object created with the extracted information. This JSON Object is added to the object
array that stores all the assets’ downloaded information. After an asset is updated the next asset is
checked. This process continues until all assets have been checked and updated as needed. Now that all
the information is up to date for all assets, the process can continue.
All that is needed from each asset are the longitude and latitude variables and they are extracted from
each asset’s JSON Object. The longitude and latitude when extracted is in double format and need to be
changed to integer. So they are multiplied with 1x106, as longitude and latitude coordinates are always
an eight digit number. Temporary arrays are used to hold all the longitude values in the one and all the
latitude values in the other. This just simplifies the process to follow. The new integer longitude and
latitude values stored in the arrays are used to create geopoints for each set.
A loop is now created to determine the span of the map. The idea is to find the span of the map that will
include all the assets’ locations displayed in the map. Figure 37 below shows what the span is that the
application wants to calculate.
The span will be mathematically extracted from the longitude and latitude information. Each asset’
longitude and latitude variables will be compared to a four variables. The four values are the minimum
and maximum longitude and latitude variables and each will store the respective maximum en minimum
values.
The new geopoints are now added to overlay items and then added to the itemizedoverlay. The
itemized overlay is then populated. This means that the activity will now add all the elements that were
contained in the itemizedoverlay and drawn them on the map view.
Once again a map controller is now created and used to animate or move the map. First the map is
zoomed to the level needed to display all the assets’ location. For this we need the four variables just
determined. Also the map is animated to the middle point of the span. The equations below will explain
the math behind these functions.
Figure 37 - Span of a map
43
The span area for latitude is determined using :(maxLatitude - minLatitude)
The span area for longitude is determined using: (maxLongitude - minLongitude)
The average between the max and min longitude and latitude is used to find the point to move the map
to. Figure 38 will show the product of this complete method.
7.4.3.3 Scenario 2 - Toggle Button to switch views
The goal of this method is to facilitate a way to switch between the two views. The default view is to
display the currently selected asset’s location. The other more advanced view is to display all the asset’s
locations. This will require all the assets to download new information if the information currently
stored is not up to date.
The toggle button controller is set up and a listener is created. This method will only execute its process
if the button is pressed. If pressed the process starts by getting the map overlay list that contains all
previous locations that were drawn and clearing it. Now there are two scenarios how this method could
execute its process.
The first is when the toggle button is selected. In this case, a method is called that will handle the new
process and a false Boolean flag will be sent to it. The method that will be called will now update the
asset’s information if needed and draw all the asset’s locations on the map. The method “Threadrun” is
called and explained in section 7.4.3.2.
The other scenario is when the toggle button is not deselected. Just as before, the process will now call
a new method. The method “Threadrun” is called and explained in section 7.2.3.2. A Boolean true flag is
sent to the method and will be used to draw a single asset’s location in the maps.
7.4.3.4 Update the information using scheduled timer
Whenever the activity is started, a timer is always started with it. The function of the timer is to facilitate
an automatic update of the asset’s information. There are two views as explained in this activity. The
first and default is to display a single asset’s location and the second is to display all the asset’s locations.
In either case, the scheduled timer will automatically update the information required to draw the view
and then redraw it as well.
Figure 38 - All assets' location displayed on map
44
This timer checks for the update flags that will be reset using the main timer described in the info tab
activity, section 5.2.1. Only when those flags are true will this activity’s update process execute.
When the timer function is called, a check is made to see if there is a timer already active in this activity.
If there is, no timer will be started as there is one already. If there is no timer active, a scheduled timer is
created with an initial ten second delay. After the initial delay, the timer has a ten second count down.
When the timer’s countdown reached zero, its process can start.
Once the process is started a check is made to see if any processes in the application are busy with a
lengthy process or downloading information. If there is somewhere processes active, this process will
wait until the flag to check if they are busy is set to false. The toggle button is now checked to see if it is
selected or not. The state of the button will facilitate the change in the views.
7.4.3.4.1 Toggle Button Selected
If the toggle button is selected the process will now check to see if the update maps all flag is set to true.
In the case that the flag is true, the updating process will now lock the screen rotation. The reason for
locking the screen rotation is to make sure that the processes to follow will not be interrupted. The map
overlay list is retrieved and cleared of all previous elements. Now the method described in
section7.4.3.2 is called and all the assets’ information will be downloaded and their locations will be
drawn on the map.
If the flag is not true, the timer will restart and wait another ten seconds to do the check for the flag.
7.4.3.4.2 Toggle Button not Selected
In the case that the toggle button is not selected the process will check the currently selected asset’s
update information flag.
In the case that the flag is true, the updating process will now lock the screen rotation. The reason for
locking the screen rotation is to make sure that the processes to follow will not be interrupted. The map
overlay list is retrieved and cleared of all previous elements. Now the method described in section
7.4.3.2is called and currently selected asset’s information will be downloaded and its location will be
drawn on the map.
If the flag is not true, the timer will restart and wait another ten seconds to do the check for the flag.
8. User Interface
8.1 Overview
8.1.1 Graphical User Interface Overview
The application uses four main windows to control the complete system. Each of the four windows is an
activity controlled by processes explained in sections 4, 5, 6 and 7.
45
The four activities and where to find their process flow are:
The Authentication window – Section 4.
The Info tab Activity window – Section 5.
The Graph tab Activity window – Section 6.
The Maps tab Activity window – Section 7.
Each of the activities has different functions and was designed separately and individually. The sections
to follow will describe each activity in more depth.
8.1.2 Design Overview
Each UI window for each of the activities used is an xml file. Eclipse with an Android plugin was used and
with that the xml files was designed. The xml files control the layout of each window as well as the
positioning of each view or element there in. Basic xml design elements will now be explained.
When a specific element is created, for instance a text view, it is opened using its tag
<TextView
And closed using any of 2 methods
/> or </TextView>
Any and all information contained between the start and close of the specific element will be associated
with that element. Depending on the type of layout used, the location of the element must be specified.
There are different layout styles and each has a different way of defining the location of every element
contained within. Some of the important ones are:
Linear Layout - A layout that organizes its children into a single horizontal or vertical row. It
creates a scrollbar if the length of the window exceeds the length of the screen.
Relative Layout - Enables you to specify the location of child objects relative to each other (child
A to the left of child B) or to the parent (aligned to the top of the parent).
Frame Layout - Layout that acts as a view frame to display a single object.
Table Layout - A tabular layout with an arbitrary number of rows and columns, each cell holding
the widget of your choice. The rows resize to fit the largest column. The cell borders are not
visible
This is a tracking application and for that reason the background was created and chosen to be a road
with a yellow line down the side.
This application was designed to be able to function on any platform. The screen sizes are calculated by
the Android OS and different size backgrounds were created to enable the clearest view possible. There
are three main sizes associated with different screen sizes and Android calls them:
Ldpi – Low dots per index
Mdpi – Medium dots per index
Hdpi – High dots per index
46
These different screen classifications require that different size icons and backgrounds be created. If
they aren’t added, the application will function normally but all the icons and backgrounds will be
stretched to fit the screen size and classification.
The sizes of the icons and backgrounds for each screen classification are:
Ldpi: icon = 36 x 36 pixels background = 240 x 320 pixels
Mdpi: icon = 48 x 48 pixels background = 320 x 480 pixels
Hdpi: icon = 72 x 72 pixels background = 480 x 800 pixels
There are three default folders created by the Android project that include these screen classifications.
Each icon and background used was added to the respective folders.
Figure 39 is an indication of the different sizes of the icons.
8.2 Authentication window This window uses two editboxes to enable the user to add the username and password credentials. A
login button is provided to be able to start the process of testing the credentials. Two checkboxes are
used to save user preferences.
8.2.1 General
Figure 40 above shows the authentication UI window with all the elements added and some user
preferences selected. Within the activity described in section 4 there are listeners placed to enable the
application to know when a button is pressed or when a checkbox has been selected. The functionality
of each of the elements in this window is well documented in section 4.
Figure 40 - Authentication UI window
Figure 39 - Different icon sizes. From ldpi to hdpi
47
Figure 41 - Authentication page with keyboard
8.2.2 Design Specifications
8.2.2.1 Login Button
The first thing to notice is the strange location of the login button. The reason for this is that when the
user has to add information in any of the two edit boxes, a keyboard comes up on any touch screen
platform. If the login button is positioned at the bottom, the user will have to press back first before
login can be selected. Now the login button is easily accessible during any process of this activity. Figure
41 below shows this window with the UI keyboard attached.
8.3 The tabs Figure 42 displays all the tabs used in this application. Three tabs were created, one for each of the
three main activities controlled in this application. To change between any of the tabs is possible by
simply selecting or tapping on a different tab.
There are two types of icons used, excluding the different screen classifications. The one will be the icon
used when the tab is currently selected and the other will be used when the tab is not selected. Figure
43 shows the different icons used for both selected and idle states. The icons with color are the icons
used when its tab is selected.
Figure 43 - Icons used for the tabs. Selected and idle state
Figure 42 - UI tabs
48
8.3.1 Info Tab UI Window
8.3.1.1 General
This processes of this window are well documented in section 5. A spinner is used at the top of the
window to facilitate a change in the asset currently chosen. There are two sets of nine textviews created
to display the information downloaded from the server to the user. The one set is used to describe the
information and the other set is used to display the information. Figure 44 below shows the full info tab
UI window.
8.3.1.2 Design Specifications
8.3.1.2.1 General
The reason that the spinner was created at the top and the seekbars at the bottom was to make sure
that there was no accidental movement or selection made by the user on any of the elements. This
would cause a bad experience for the user if it would happen. A button is placed in the bottom corner.
The reason for this is that there won’t be many reasons for returning to the authentication screen, but if
the user does want to return and disable a preference, the option is there.
8.3.1.2.2 Check Button and Seekbars
The check box button as seen in Figure 44 must be selected to enable the use of the two seekbars.
These seekbars control the update times of the asset to server as well as from the server to the
platform. Currently only the update time from the server to the platform is working. The other update
time from asset to server is a recommended point for future development.
If the check box button is deselected the two seekbars are disabled and no interaction with them is
possible as seen in Figure 45.
Figure 44 - Info tab UI window
49
Figure 45 - Seekbars disabled
Figure 46 - Graph UI window in portrait orientation
8.3.1.2.3 Text Views
The text views are designed to push everything below the item further down to accommodate
information that is too long for a single line. A relative view is used to set that an item below another
will move down until there is space for its own information. A sample can be seen in Figure 44. Both
with the driver’s name and location information fields are too long for a single line. The rest of the
information is pressed down and only starts after all the previous information is displayed.
8.3.2 Graph Tab UI Window
8.3.2.1 General
The activity that uses this window is well documented in section 5. This window was designed to use
two different xml files. The one will be used when it is determined that the activity is in portrait
orientation and the other will be used when in landscape orientation. This window only displays the
currently selected asset’s information.
8.3.2.2 Design Specifications
8.3.2.2.1 Portrait Orientation
In this orientation the window was designed to house two views. The way that is made possible was by
using two empty linear layouts, each taking up half of the screen. The views are created during one of
the processes in the activity controlling this window. The Graphs can be moved individually from side to
side, but only thirty elements will be displayed. The value of each data point is shown. Figure 46 below
shows the window in portrait mode.
50
8.3.2.2.2 Landscape Orientation
In this orientation the window was designed to house only a single graph. The reason for this was that if
the user couldn’t properly see the graph, this view was available to facilitate that need. A button is used
to switch between the two graphs. Each graph can be moved from side to side, but only thirty elements
will be displayed. Figure 47 shows a single graph in landscape orientation.
8.3.3 Maps Tab UI Window
8.3.3.1 General
The activity using this window is well documented in section 5. The focus of this window is to use the
google maps API to indicate the location of an asset on the map. There are two modes that this window
will be used for. The first is to draw a single asset’s location and is the default setting for this window.
The second is to display all the asset’s locations. Zoom functions are enabled. Google Maps is an internet
based maps directory and when moving to a new area, the information about that area will be
downloaded. Figure 48 below displays the drawable pin used to display the location
8.3.3.2 Design Specification
8.3.3.2.1 Single Asset
This is the default mode. A drawable is used to display the location of an asset. Figure 49 shows the
window when only a single asset is displayed. The activity sets the initial zoom level and moves the map
to the asset’s location.
Figure 47 - Graph UI window in landscape orientation
Figure 48 - Pin used to display location of an asset in Google Maps
Figure 49 - A Single Asset displayed in Google Maps
51
8.3.3.2.2 All Assets
This mode is activated once the button in the bottom right corner is selected. The activity will then draw
all the assets that are registered and available on the maps. Figure 50 below shows the window when
the button has been selected and all the assets are displayed on the map. The activity zooms to the
middle of the area and sets the zoom level.
8.3.3.2.3 When tapped on an asset
In this UI window, when tapped on the drawable displaying the location of an asset, a message is
displayed that will show relative information. Figure 51 shows typical information displayed when
tapped on an asset’s location.
9. Testing
9.1 General Various elements and functions of the application were tested. The following sections will define the
methods used and the results received. There were two separate testing areas. The first is the
application itself and the other is the ability to automatically update the information in every window.
Figure 50 - All Assets displayed in google Maps
Figure 51 - Asset's information displayed when tapped in google maps
52
9.1.1 Testing Methods
Testing Methods
General
1
Specification The application must be robust enough to be started and restarted without errors.
Test Application was started, logged in, exited and restarted and logged in again.
Results Pass: No application crash
Authentication Window
2
Specification The application will detect the wrong credentials when trying to connect to the server.
Test The wrong username was entered and login pressed
Results Pass: No application crash. Error message displayed.
3
Specification The application will detect the wrong credentials when trying to connect to the server.
Test The wrong password was entered and login pressed.
Results Pass: No application crash. Error message displayed.
4
Specification The application must save the preferences of the user and act accordingly.
Test The save credentials checkbox was checked, logged in. Application was restarted and status was checked.
Results Pass: No application crash. Save check box successfully restored to its saved state and username and password automatically added to edit boxes.
5
Specification When the auto login preference is selected, the application must be able to log in automatically.
Test The auto login checkbox was checked, logged in. Application was restarted and results were checked.
Results Pass: No application crash. Application automatically logs in.
Information tab Window
6
Specification Update processes must not be interrupted even when the orientation is changed.
Test Orientation was changed during an update process.
Results Pass: No application crash. Screen rotation is locked until process is completed.
7
Specification If an asset's information has been downloaded, and the timer hasn't reached zero, the information needs to be saved.
Test An asset was changed to another asset and changed back to original asset.
Results Pass: Information was stored and no internet update was performed.
8
Specification When an asset's information field uses more than one line, the application will push down the elements that follow.
Test Information too long for a single line was added and results checked.
Results Pass: Information was pushed down to make space for the addition data.
9
Specification When the checkbox is selected the seekbars should become available to interact with.
Test Check box in info tab window was pressed and results were checked.
Results Pass: Seekbars became enabled and can be interacted with.
53
10
Specification When the checkbox is deselected and the value on the seekbar has changed, a new timer must be created using the new values.
Test The check box was deselected and results were checked.
Results Pass: Timer is cancelled, new time is stored in memory and new timer is started.
11
Specification When the authentication button is pressed, the authentication activity must be started.
Test The authentication button in this window was pressed and results were checked.
Results Pass: Successfully moved to authentication window.
Graph tab Window
12
Specification When the graph window tab is selected, the application should go to the activity controlling it.
Test Graph tab was pressed and results were checked.
Results Pass: Successfully navigated to the new window.
13
Specification A new window must be shown when the orientation changes.
Test The orientation was changed and results were checked.
Results Pass: New window was loaded.
14
Specification If an asset's information has been downloaded, and the timer hasn't reached zero, the information needs to be saved and redisplayed.
Test An asset was changed to another asset and changed back to original asset. Graph tab window was reopened.
Results Pass: Information successfully stored and retrieved.
15
Specification The graphs have thirty elements in each but not all are displayed immediately. The graphs can be moved to see older values.
Test Each of the graphs was tested to be sure they move from side to side.
Results Pass: Each graph was moved all the way to the limit and back.
16
Specification When a different asset is selected, its specific information needs to be displayed, not the previous asset.
Test Different asset in info tab window was selected and graph tab opened.
Results Pass: New information was about the new asset was displayed.
17
Specification When in landscape orientation, the only way to access the other graph is by pressing the button.
Test In landscape mode the button was pressed and result was checked.
Results Pass: Successfully changed the graph from the line to the bar graph.
Maps tab Window
18
Specification When the map window tab is selected, the application should go to the activity controlling it.
Test Maps tab was pressed and result was checked.
Results Pass: Successfully navigated to the new window.
19
Specification When an asset's location icon is tapped or selected, a message has to display some relevant information.
Test Drawable was tapped on and message was checked.
Results Pass: Message successfully displayed the correct heading, location and speed.
54
20
Specification When a different asset is selected, its specific information needs to be displayed, not the previous asset.
Test Different asset info tab window was selected and maps tab opened.
Results Pass: New information was about the new asset was displayed.
21
Specification When the toggle button is pressed, the activity should switch between the single asset and all the assets being displayed on the map.
Test Toggle button selected and result checked.
Results Pass: Successfully changed the map from a single asset to all the assets and back again.
22
Specification Zoom controls are added and the user must be able to move to another location if so desired.
Test Map was zoomed and moved.
Results Pass: Successfully zoomed closer and further away. Also moved the map to another location.
23
Specification Update processes must not be interrupted even when the orientation is changed.
Test Orientation changed during an update process.
Results Pass: No application crash. Screen rotation is locked until process is completed.
Automatic Updating
Information tab Window
24
Specification Information must be automatically updated if the timer has determined that there should be new information at the server.
Test Information was updated using the device simulator and results were checked.
Results Pass: Information is automatically updated when the timer expires.
Graph tab Window
25
Specification Information must be automatically updated if the timer has determined that there should be new information at the server.
Test Information was updated using the device simulator and results were checked.
Results Fail: see below for a full description.
Maps tab Window
26
Specification Information must be automatically updated if the timer has determined that there should be new information at the server.
Test Information was updated using the device simulator and results were checked.
Results Pass: Location of asset moves when the application updated the information.
Discussion
Almost all the tests went perfectly. The only test not to perform as expected is test 25. The automatic
update of information in the graphs window and activity is a small problem. The application will
currently not always display the most up to date information as explained in sections 6.3.3.1.1 and
6.3.3.2.1. The reason for this is that Trinity Telecoms’ server is slow to update this dataset containing the
past thirty elements. A method was implemented to force a refresh of the cache on their system, but it
is not successful every time. It is a recommended point for further development.
55
10. Conclusion and Recommendations
10.1 Conclusion The aim of this project was to design, construct and implement a tracking type application. An
application using a server was designed, constructed and fully tested. The results were positive and the
specifications set out in the beginning were fulfilled.
By using this application in conjunction with the hardware needed to update the information in Trinity
Telecoms’ server, an affordable and viable alternative to the expensive tracking services currently
available will be realized. Although this application only focused on the software side of this project, the
general mechanics of the hardware had to be understood.
The application as a whole was designed from the top down. Different objectives were identified and
work started on completing each objective separately. Each of the separate objectives were designed
and built from the ground up.
When designing the authentication activity and UI window, the basic elements were constructed first.
The elements needed for the activity to function as designed were for it to be able to connect to the
server hosted by Trinity Telecoms. Thus basic functionality was completed and more advanced elements
were added to make the application more user friendly. As each element was completed the activity
grew in complexity. Testing was performed to check on the robustness and functionality of the activity.
The results were positive and a conclusion can be drawn that the activity performs as designed and as
desired.
When this application was being develop the graphing engine used, AChartEngine, used version 0.7. A
newer has been released, version 1.0 with updated methods. The new engine should be incorporated
into the system.
The info tab activity and UI window, was designed to house an easy to understand and use UI window. It
was designed with the idea that this page has to use as little data as possible so only a text based
window was created. Displaying the information from the server would be the basic functionality. After
that was achieved additional elements were added to make the experience more intricate and
complete. The activity was created from the bottom up, while keeping the end goal in mind. Testing was
performed to define if the activity performed as expected. All the testing procedures passed and it was
deemed that this activity is completed successfully.
The graph and maps tab activities were both created from the bottom up. Basic functionality was
achieved and addition content was added to each activity. Testing was done on both the activities and
all the results except one was as hoped.
The testing result that did not perform as hoped is when information is updated. It was noticed that the
server is slow to update this data set information. A method was implemented to try and manually
correct this shortcoming, but it is not successful every time.
56
Overall the application performs as expected and the goals set out were all achieved.
A demonstration video can be found online at: http://youtu.be/qEhPW0sUFGA
10.2 Recommendations During the development of this application, a few elements were brought to the foreground and are all
good elements in which to upgrade this system in the future.
A notification element can be added. What this will implicate is that the user will then be able to receive
certain notification when events are triggered on the asset and registered. For instance an event is
triggered when the vehicle is started, stops suddenly, drives over the speed limit etc. This can be an
invaluable addition to the application.
Using the second seekbar already incorporated into the application to define the update time from the
asset to the server. This is already possible but unfortunately due to time constraints could not be
completed in time. What this will define, is at what interval all the assets will send their updated
information to the server.
Another option to improve on is the refreshing of Trinity Telecoms’ data set fields. Currently their
system is updating their cache too slow and that is forcing the application to download out of date
information. A method should be researched to enable the download of up to date information.
During the development of a software project, it is important to remove bugs as soon as they are
noticed. The more complex the system becomes, the more intricate the problem. Use the log function
to write to the log catalog and via this method determine where the problem is.
An in depth understanding is required about all elements added to a project. First test the new function
in a separate project until a large enough knowledge base about this new feature is built. This will
reduce the amount of bugs and errors the system will have when implementing new features.
Continuous testing is almost more important than the final testing. When just fiddling and playing with
the application, strange errors or small bugs will arise that was never considered an option when
designing.
Following these recommendations and using help tools readily available, will enable the development of
an efficient and robust system.
57
References [1] – Internet: http://Androidphone.org.uk/guides/what-is-an-Android-phone/ [5 May 2012]
[2] – Internet: http://source.Android.com/about/philosophy.html [5 May 2012]
[3] – Internet: http://developer.Android.com/guide/topics/fundamentals/activities.html
[12 May 2012]
[4] – Internet: http://www.xfront.com/REST-Web-Services.html [15 May 2012]
[5] - Internet: http://www.codeproject.com/Articles/112470/Developing-a-REST-Web-Service-using-C-
A-walkthroug [15 May 2012]
[6] – Internet: http://www.petefreitag.com/item/431.cfm [15 May 2012]
[7] – Internet: http://ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest [15 May 2012]
[8] – Internet: http://developer.Android.com/guide/topics/data/data-storage.html [7 May 2012]
[9] – Internet: http://code.google.com/p/chartdroid/ [16 May 2012]
[10] – Internet: http://www.achartengine.org/index.html [16 May 2012]
[11] – Internet: https://developers.google.com/chart/interactive/faq#whatis [16 May 2012]
[12] – Internet: http://Android.arnodenhond.com/components/graphview [16 May 2012]
[13] – Internet: http://developer.Android.com/resources/dashboard/platform-versions.html
[7 May 2012]
[14] – Internet: http://developer.Android.com/sdk/index.html [10 May 2012]
[15] – Internet: http://smart.trintel.co.za/ [9 May 2012]
[16] – Internet: http://platform.trintel.co.za/ [9 May 2012]
[17] – Internet: http://java.sun.com/developer/technicalArticles/WebServices/WSPack2/techno.html
[15 May 2012]
[18] – Internet: https://developers.google.com/chart/ [16 May 2012]
[19] – Internet: http://Androidandme.com/2012/01/applications/Android-now-has-400000-apps-still-a-
ways-to-go-to-catch-ios/ [20 May 2012]
58
Appendix A: Project Plan
This project map does not display work done over weekends.
Advanced UI design started on Saturday the 7th of April, not Monday the 9th of April.
Advanced debugging ended Sunday the 15th of April, not Friday the 13th of April.
59
Appendix B: Project Specification The specification of this project was to design, develop and test a working UI application that can
visually display information downloaded from an online server.
The basic system specifications require that the system or application as it will be called hence forth,
needs to update the information in real time. Various minibus taxis’ information have to be displayed in
an effective and simple application that will run on a basic Android OS.
In addition to the basic specifications, more advanced features were added. These features were added
not as a requirement to the system, but to enhance the application functionality.
The application was enhanced with five other main features:
A login screen was created to situate a username and password credential check with the
server.
The update time can be set by the user, in an attempt to give the user more control over the
amount of data usage consumed.
A memory storage system was incorporated to save certain information. The information saved
was user preference choices, the update flags and the update time set by the user.
A graphing activity was created to visually display a metric field’s dataset. This dataset contains
the past thirty elements recorded by the server. This information is displayed in a line and a bar
graph.
A location function was added and implemented. Google Maps API was used to display the
location of a single or all assets currently available.
60
Appendix C: Outcomes Compliance Identification of problems, research done and implementation of solutions
Storing downloaded information in object arrays to minimize data use.
Identifying the need for and automatic update system and implementing the scheduled timer
function.
Identified that when the information downloaded takes more than one line in the UI, text views
are then overlapped. Now the UI elements are pushed down until the information is fully
displayed.
Noticed that the Info tab UI window is too long and not all elements can be show. A scroll view
was implemented to enable the window to scroll down until all information is shown.
onResume method in every tab activity checks to see if it should update the data when returned
to a previously selected tab.
Identifying that the long process of downloading the information from the server slows down
the UI and implementing a thread to handle the process.
Identifying that shared preference save method loses its data when platform is shut down and
then implementing the save of long term information on the internal memory.
Identified that processes are cancelled and the window is recreated when the application
changes orientation. Now the application handles the screen orientation change manually and
locks screen orientation in place until process has finished.
Application areas of engineering and science knowledgebase
Using knowledge of object notations to save information in a constructive and easily accessible
way.
Knowledge of under which circumstances threads are used and how to contact the UI.
Knowledge of http communication and base 64 authentication.
Knowledge of the asset and metric model setup and understanding what information will be
received.
Mathematically calculate the span in the map area that will cover all the available assets within
a single view.
Implementation of design through the use of the system and sub-systems
This system or application was created using the top down waterfall method. The application’s
specifications were set out and separate activities were created to facilitate every specification. Section
1.3 explains the process followed in more detail and section 2.2 describes the system and how each
separate sub-system or activity contributes to the completed application.
61
Research done and data analysis thereof
Gathering information about the two web services identified as viable options, analyzing the
strengths and weaknesses and implementing one.
Identifying all the possible storage methods that could be used on an Android platform,
analyzing them and implementing the chosen methods.
Identifying different threading options, analyzing the differences and implementing one.
Identifying possible charting engines, analyzing the strengths and weaknesses and implementing
one.
Researching various UI elements and choosing the correct ones for certain situations.
Engineering methods and tools used
Eclipse SDK, runtime environment and Android Development Tools (ADT) were used to develop
the application. Its debugging software and log catalogues were also used.
Android Virtual Device and an exported .apk file that was uploaded to a smart phone were used
to simulate and test the application.
AChartEngine version 0.7 was used to enable graphs to be drawn.
Google Maps API was used to enable the use of a mobile map interface.
AirVantage Configuration tool was used to set up the Asset Model and Asset Descriptor.
A portal at smart.trintel.co.za was used to monitor the assets and their information. Also used to
set up the metric model.
Communication
This report is written to partially fulfill that requirement. A contact session at a later stage will be the
second part to fulfilling this requirement.
Independent learning
During the course of this project’s development, a constant reminder that I did not have the necessary
knowledge to complete every task was presented to me. This project contains a very large amount of
different functions that I had no knowledge of prior to starting. Researches into the inner working of
these functions were needed if the system was to function as planned. This report does not contain all
the functions and information needed to be learnt as it is already quite long. The information contained
in this report are all listed below:
Software development in java.
How to design, setup and control user interface and its elements.
Using REST to access resources contained in a URL.
Understanding the authentication required to access resources contained in URL’s.
Contact sessions with Trinity Telecoms to better understand their system and server and how to
communicate with it.
Understanding how to store information and which information to store where.
62
How to use a thread to do processes simultaneously and to use a handler to access the UI.
Learning how to use an external graphing library
Learning how to set up Google Maps API and control it.
Drawing elements over a view that currently exists.
Appendix D – Flow Diagram
D1 - Application
D2 - Tab Activity
63
D3 - Authentication Activity
64
D4 - Info tab Activity
65
D5 - Graph tab Activity
66
D6 - Get Bar Graph View
D7 - Get Line Graph View
D8 - Refresh Trinity Cache
67
D9 - Set Graph Array
D10 - Set Graph – Object Array
D11 - Create coordinate Drawings
D12 - Create all coordinate Drawings
68
D13 - Google Maps Activity
69
D14 - Get all location
D15 - On Location Item Tap
D16 - Downloading Information (httpCall)
70
D17 - Set metric data of information downloaded
71
Appendix E- Additional information
E1 – Android Manifest
72
E2 – Asset Descriptor Object [ { "class_name": "Asset", "ext_10": "", "device": "359126030121354", "longitude": "18.65802", "id": "12027", "description": "", "metric_model_id": 200, "ext_11": "", "cached_state_color": "orangered", "latitude": "-34.034558", "folder": "South Africa", "cached_state_label": "Comms Error", "ext_1": "23", "ext_0": "Sipho Malhangu", "ext_3": "", "ext_2": "AGT 390 GP", "ext_5": "", "ext_4": "", "ext_7": "", "ext_6": "", "ext_9": "", "ext_8": "", "device_id": 15856, "is_deleted": "False", "name": "", "created": "2012-04-18 20:00:59", "modified": "2012-05-11 13:08:16", "metric_model": "Metric-test", "external_id": "UoSA", "asset_model": "AssetModel: UoSA", "folder_id": 5560439 },
{ "class_name": "Asset", "ext_10": "", "device": "999999999910003", "longitude": "18.91802", "id": "12029", "description": "", "metric_model_id": 200, "ext_11": "", "cached_state_color": "orangered", "latitude": "-33.954558", "folder": "South Africa", "cached_state_label": "Comms Error", "ext_1": "23", "ext_0": "George Wahington", "ext_3": "", "ext_2": "AGT 390 GP", "ext_5": "", "ext_4": "", "ext_7": "", "ext_6": "", "ext_9": "", "ext_8": "", "device_id": 20909, "is_deleted": "False", "name": "", "created": "2012-04-18 20:00:59", "modified": "2012-05-12 11:50:45", "metric_model": "Metric-test", "external_id": "UoSA", "asset_model": "AssetModel: UoSA", "folder_id": 5560439 },
{ "class_name": "Asset", "ext_10": "", "device": "999999999910002", "longitude": "19.2802", "id": "12028", "description": "", "metric_model_id": 200, "ext_11": "", "cached_state_color": "orangered", "latitude": "-33.654558", "folder": "South Africa", "cached_state_label": "Comms Error", "ext_1": "18", "ext_0": "JL Reinecke", "ext_3": "", "ext_2": "HGY 098 NW", "ext_5": "", "ext_4": "", "ext_7": "", "ext_6": "", "ext_9": "", "ext_8": "", "device_id": 20908, "is_deleted": "False", "name": "", "created": "2012-04-18 20:00:57", "modified": "2012-04-19 19:40:02", "metric_model": "Metric-test", "external_id": "UoSA", "asset_model": "AssetModel: UoSA", "folder_id": 5560439 } ]
2
E3 – Asset Descriptor Setup in AirVantage
E4 – Metric Model Maker Setup
3
E5 – Single Asset Information [
{
"description": "",
"name": "Age",
"created": "2012-04-
19T09:56:00",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:56:00",
"units": "",
"position": "774, 10",
"data": {
"name": "Age",
"timestamp": "2012-05-
11T11:20:44",
"value": "23",
"units": "",
"type": "INT",
"id": 179534
},
"id": 1057,
"size": "171, 342"
},
{
"description": "",
"name": "Current Speed",
"created": "2012-04-
19T09:58:07",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:58:07",
"units": "",
"position": "774, 10",
"data": {
"name": "Current Speed",
"timestamp": "2012-05-
11T11:20:44",
"value": "13",
"units": "",
"type": "INT",
"id": 179529
},
"id": 1073,
"size": "171, 342"
},
{
"description": "",
"name": "Heading",
"created": "2012-04-
19T09:58:18",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:58:18",
"units": "",
"position": "774, 10",
"data": {
"name": "Heading",
"timestamp": "2012-05-
11T11:20:44",
"value": "S/SW",
"units": "",
"type": "STRING",
"id": 179531
},
"id": 1074,
"size": "171, 342"
},
{
"description": "",
"name": "Latitude",
"created": "2012-04-
19T09:59:37",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:59:37",
"units": "",
"position": "774, 10",
"data": {
"name": "Latitude",
"timestamp": "2012-04-
26T14:31:03",
"value": "-
34.0345580000",
"units": "",
"type": "DOUBLE",
"id": 179527
},
"id": 1079,
"size": "171, 342"
},
{
"description": "",
"name": "Longitude",
"created": "2012-04-
19T09:59:51",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:59:51",
"units": "",
"position": "774, 10",
"data": {
"name": "Longitude",
"timestamp": "2012-04-
26T14:31:03",
"value":
"18.6580200000",
"units": "",
"type": "DOUBLE",
"id": 179525
},
"id": 1086,
"size": "171, 342"
},
{
"description": "",
"name": "Max Accel",
"created": "2012-04-
19T09:59:01",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T11:25:27",
"units": "",
"position": "774, 10",
"data": {
"name": "Max Accel",
"timestamp": "2012-05-
11T11:20:44",
"value": "18",
"units": "",
"type": "INT",
"id": 179530
},
"id": 1075,
"size": "173, 342"
},
{
"description": "",
"name": "Max Speed",
"created": "2012-04-
19T09:59:18",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:59:18",
"units": "",
"position": "774, 10",
"data": {
"name": "Max Speed",
"timestamp": "2012-05-
11T11:20:44",
"value": "200",
"units": "",
"type": "INT",
"id": 179528
},
"id": 1076,
"size": "171, 342"
},
{
"description": "",
"name": "Name",
"created": "2012-04-
19T09:56:46",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:56:46",
"units": "",
"position": "774, 10",
"data": {
"name": "Name",
"timestamp": "2012-05-
11T11:20:44",
"value": "Sipho
Malhangu",
"units": "",
2
"type": "STRING",
"id": 179533
},
"id": 1059,
"size": "171, 342"
},
{
"description": "",
"name": "Occupants",
"created": "2012-04-
19T10:00:07",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T10:00:07",
"units": "",
"position": "774, 10",
"data": {
"name": "Occupants",
"timestamp": "2012-04-
26T14:31:03",
"value": "8",
"units": "",
"type": "INT",
"id": 179526
},
"id": 1088,
"size": "171, 342"
},
{
"description": "",
"name": "Registration",
"created": "2012-04-
19T09:57:08",
"class_name": "Metric",
"metric_model_id": 200,
"modified": "2012-04-
19T09:57:08",
"units": "",
"position": "774, 10",
"data": {
"name": "Registration",
"timestamp": "2012-05-
11T11:20:44",
"value": "AGT 390 GP",
"units": "",
"type": "STRING",
"id": 179532
},
"id": 1060,
"size": "171, 342"
}
]
