TVE 15 049 jun

Examensarbete 15 hpJuni 2015

Indoor Positioning System

Development of serverside functionality,

client communication and a graphics engine

Pontus ArfwedsonJoel Berglund

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Indoor Positioning System

Pontus Arfwedson & Joel Berglund

The projects goal was to make an already existing indoor positioning system useful forthe average smartphone user. This was achieved by creating an Android applicationwhich, along with a running server, continuously presents the user with all the currentneeded information. It uses the graphics engine andEngine to create the graphical userinterface. The application was created in the development environments Eclipse andAndroid Studio.

ISSN: 1401-5757, UPTEC F** ***Examinator: Martin SjödinÄmnesgranskare: Ken WelchHandledare: Henrik Arfwedson

Contents

1 Introduction 51.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Indoor positioning . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Making an indoor positioning system useful for an end-user . . . 6

2 Theory 62.1 Application programming interface (API) . . . . . . . . . . . . . 62.2 Development environment . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Integrated development environment (IDE) . . . . . . . . 72.2.2 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Programming language . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.1 Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.3 Graphical User Interface . . . . . . . . . . . . . . . . . . . 12

2.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.1 SQL Database . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6.1 Apache Maven . . . . . . . . . . . . . . . . . . . . . . . . 132.6.2 andEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7 Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7.1 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Result 143.1 The communication of the entire application . . . . . . . . . . . . 143.2 Communication in the client . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Trigger request from client to server . . . . . . . . . . . . 153.2.2 Handle response on client . . . . . . . . . . . . . . . . . . 17

3.3 The server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1 Handle request . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Accessing the database using Hibernate . . . . . . . . . . 183.3.3 Sending reponse . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 The activity in the client . . . . . . . . . . . . . . . . . . . . . . . 193.4.1 The navigation GUI . . . . . . . . . . . . . . . . . . . . . 19

1

4 Discussion 244.1 Server functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Client functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 The graphical interface of the client . . . . . . . . . . . . . . . . 24

4.3.1 Using andEngine . . . . . . . . . . . . . . . . . . . . . . . 254.4 Testing the application . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Developing for other platforms . . . . . . . . . . . . . . . . . . . 25

5 Conclusions 265.0.1 Improvements of the application . . . . . . . . . . . . . . 265.0.2 Further development of the application . . . . . . . . . . 26

2

Popularvetenskaplig sammanfattning av pro-jektet

Indoor positioning - att guida en anvandareinomhus

Att ta sig fran ett stalle till ett annat har aldrig varit lattare an det ar idag.GPS-teknologin och dess tillhorande appar gor att en bilresa idag nastan heltkan utforas genom att lyssna pa en rost fran mobiltelefonen. Men hur gor manom man befinner sig pa ett stort kopcenter och letar efter den dar butiken manar ute efter? Da GPS endast fungerar utomhus finns idag inget utbrett alter-nativ for den som vill underlatta sin navigering i storre okanda inomhusmiljoer.Markanden for detta torde vara stor, och ett stort antal foretag, sa som Googleoch Apple, arbetar for att forverkliga effektiv positionering inomhus.

Till skillnad fran GPS finns det ett stort antal olika teknologier att rikta in sigpa. En stor del av foretagen anvander sig av WiFi dar signalstyrkor kan avlasasfran olika natverk for att uppskatta anvandarens position. Detta forutsatter attdet finns flera tradlosa natverk tillgangliga for att skapa en palitlig position. Ettannat alternativ ar att lagra stora mangder information om signalstyrkor franWiFi pa sa manga positioner som mojligt och med dessa uppskatta anvandarensmest troliga position, kallat fingerprinting. Vidare innehaller alla moderna tele-foner ett flertal sensorer som kan bidra med information om hur anvandaren rorsig. Accelerometer, gyro och kompass ar exempel pa sensorer som vissa fore-tag forsoker utnyttja for att berakna anvandarens rorelse och position. Dessasensorer genererar dock ett forhallandevis stort fel over tid och det kan darfordiskuteras om de verkligen ar anvandbara. Manga foretag forsoker aven kom-binera flera system, for att eliminera sa manga fel som mojligt, utan de blir fordyra.

Att mojligheterna pa marknaden for inomhuspositionering ar stora rader detinga tvivel om, enligt Don Dodge, Developer Advocate pa Google, som driversin egna portal dondodge.com. Men system ger ofta sa stora fel att de har svartatt bli anvandbara i praktiken. Sa fragan om nar vi far se ett system som tarover marknaden kvarstar, men att det blir verklighet i framtiden kan bara sessom ett faktum.

3

DISCLAIMER

This report contains only the information that is not classified as a part of theproject. It therefor explains the structures and actions in a non-detailed fashion.It will attempt to explain the logic, and the general ideas, but any informationthat could be used to reproduce the project is not presented.

4

1 Introduction

1.1 Background

For as long as humans has had the urge to discover new places and find theirway, navigation has been a central key to succeeding in those areas. In theearlier days, navigation by the stars slowly developed into using compasses andtoday the Global Position System (GPS) can give us a very precise positionalmost anywhere in the world (1). Using GPS for outdoor location informationhas enabled mobile devices to use its position and current direction for guiding,tracking and recovering stolen devices amongst others (2).

While GPS is widely used and acknowledged there is mainly one area whereit is insufficient. To decide the position of person in an indoor environmentusing a GPS the signal is often too weak to penetrate the walls and roofs ofbuildings. Furthermore, the GPS might be able to approximate the coordinateof that person but will not be able to tell which floor in the building he orshe is currently on. Therefor, GPS serves no real use when navigating withinbuildings and there are yet to come an application which has that ability andthat has been widely spread.

The use of applications for mobile devices has increased drastically during thelast years and will most likely keep on increasing (3). With that increased usethere comes opportunities for developers to create useful applications to servethe needs of users or enhance part of their lives. Since devices are equipped withdifferent sensors, transmitters and receivers these can be used, just like using anapplication which implements the GPS-receiver, to determine different thingsabout the near environment or the state of the device.

1.2 Indoor positioning

The use of an indoor positioning system (IPS) can serve several purposes. Itcould be used to let robots navigate inside buildings, for sensor networks (wherelocation is of value) as well as entertainment (2). For these purposes standalone-devices (meaning: not smartphones) could be produced and implemented andsystems possibly created to determine position and other significant parameters.But another purpose could be to simply guide a person, inside an unfamiliarbuilding, from one place to another. And for this, the smartphones are anobvious choice considering how many people use them on a daily basis. But sincethey are not dedicated to that sole purpose, and may have certain limitations towhat can be modified and accessed, a developer would have to do the best he orshe can from the tools that are available when developing such an application.

5

1.3 Making an indoor positioning system useful for anend-user

This project builds of an already existing IPS, developed by the engineeringcompany Sweden Connectivity. This system can determine the position of anAndroid smartphone in an enclosed space. This space is equipped with devices,which will be referred to as beacons, that along with the application in thesmartphone forms the system.

Just like with a GPS-application, where the receiver along with the smartphonesinterface can give a person his or hers current coordinates, that informationalone is not of much use. If you are not an experienced navigator and have aphysical map of the entire globe in your back-pocket (or your mind), you needmore than only the coordinates to actually use a GPS-signal in a meaningfulway. The same applies to an IPS. Such a system needs to not only supply theuser with his or hers position. It needs to make it mean something, and aroundthat, develop functionality so that the user can, from his or hers position, usethe application in a beneficial way.

So how can the Android application of that existing system be extended andmodified so that it is convenient and can be used efficiently for the averagesmartphone user?

For this project the development will partly be to enhance and modify the An-droid application (the client), but also to develop a server with functionalitythat can provide the client with the necessary information when it needs it.Therefor the goal is to get an understanding of the difficulties that can arisewhen creating a client application alongside a server, and with this understand-ing create a reliable system that makes sure the client application has all thenecessary information when needed. Furthermore, the client needs to have agraphical interface that is easy to handle and creates usefulness from the IPSto the user.

2 Theory

2.1 Application programming interface (API)

An application programming interface (API) is the interface between a libraryand the application where the library contains useful tools such as functionsor classes. The API is visualized as the accessible part of the library that adeveloper can access (see figure 1 on page 7).

6

Figure 1: Visualization of the API

2.2 Development environment

2.2.1 Integrated development environment (IDE)

An IDE is a program that serves as a tool when developing applications in acertain language. It does this by supporting the user with a wide array of toolssuch as a debugger, compiler and a text editor. This way a developer can editthe code, see all the different available methods and compile the code into theapplication, all in one place. Two of the most known examples of IDE’s areAndroid Studio and Eclipse.

2.2.2 Android Studio

Android Studio is the official IDE when developing applications for Android.This means that all the development of Android applications on other programsno longer receives any official support from Google. To program in AndroidStudio efficiently a Software Development Kit, SDK, is downloaded and usedwhich enables the user to access built in features such as a complete API to allthe methods Android has to offer. Android Studio does in turn have a easy to

7

understand layout for programming the languages Java and XML. The layoutconsists of easy to access menus for the code and also a clear overview whencreating the actual layout of the application with drag-and-drop functionality.Out of the two languages, Java is the language that the Android developmentbuilds on, whereas XML is solely used for defining layouts of an application.

Figure 2: Image of Android Studios layout. To the left the menus and to theright the easy to modify GUI

2.2.3 Eclipse

Eclipse is a flexible and multipurpose IDE, where multiple programming lan-guages can be developed (4). The reason Eclipse is so flexible is because itprovides a vast amount of support for plug-ins when it comes to customisableenvironments, thereby allowing the multiple programing languages to be uti-lized. For example, Eclipse, accompanied by the plug-in Android DevelopmentTools, used to be the official IDE for development in Google:s Android. In amore general sense this means that Eclipse uses the Java Development Toolskit (JDT) which ”provides the tool plug-ins that implement a Java IDE sup-porting the development of any Java application, including Eclipse plug-ins”.This can just be summarized as to say that the JDT allows the developmentof JAVA in Eclipce. Thereby the JDT provides the base for programming anyJava application in Eclipse (5).

2.3 Programming language

2.3.1 Java

Java is an object-oriented and class-based programming language. This meansthat it contains classes, which in turn consists of attributes and methods. An

8

attribute is a trait for an object in the form of variables or constants, where theobject is an instance of a class. Java is, as said, an object-oriented languagewhich means that different objects, who can contain any kind of information,interact with each other. A method, in this sense, is a function which can changeor return the attributes of an object. An example of this are the methods seenin the code below which are the ”get” and ”set” methods. These setters andgetters are, in this case, simple methods that either set a variable, or return avariable. To illustrate an object being an instance of a class, imagine creatinga Person-object by using the class below. Having created this person, lets callit ”person1”, this does not limit the user for creating more persons e.g. ”per-son2”,”person3” etc. where all these different persons have different attributes(ages, names and addresses).

//Person.java

public class Person {

private int age;

private String address;

private String name;

public void setAge(int age){

this.age = age;

}

public void setAddress(String address){

this.address = address;

}

public void setName(String name){

this.name = name;

}

public int getAge(){

return age;

}

public String getAddress(){

return address;

}

public String getName(){

return name;

}

}

9

2.3.2 XML

XML is a markup language which means that it is a language that consists oftext-code, known as tags, that is only visible when coding and not when thedocument is shown in its final form. This means that XML is useful whendealing with layouts, text and pictures etc. As seen below, an example can beseen when creating a button in Android which will, in this case, display a buttoncontaining the text ”Hello”.

//XML button

<Button android : id="@+id/btnID "

android : layout_width="wrap_content"

android : layout_height="wrap_content "

android : text="Hello"/>

2.3.3 JSON

JSON which stands for JavaScript Object Notation is a text based format fortransferring and storing data. The advantages for using JSON is due to the factthat it works when sending data between different kinds of applications whocan have entirely different setups. As seen below in the ”JSON person object”code a typical JSON object is shown, which in this case, contains the following:age, name and address of the person.

//JSON person object

{

"age": 15,

"name": "Pontus",

"address": "Uppsala university"

}

Therefor it can be said that the main upside to JSON is that it is transferablefrom almost any programming language to another, using built in JSON parsers.

2.4 Android

2.4.1 Activity

An android activity can be described as the graphical view a user can interactwith on their device. To visualize this, every time the window of an androidapplication switches to another one, an activity is created whilst the previousone is paused. This means that each activity has its own layout which is shownwhen it is displayed for the user. In actual development an activity can simplybe stated as being a Java-class that has extended a predefined Activity class.Extending a class means the integration of the extended classes methods intothe class, in other words, it inherits its parents methods.

10

There are many states that an activity can go through in its so called life cycle(see figure 3 on page 11). When the activity is first created it goes throughthe onCreate stage which is followed by the onStart stage where the activitywill start running. After this stage, actions in the application could start newactivities that will go through the same onCreate and onStart stage and, whenswitching activities, will put the original activity in pause mode (onPause).The original activity will wait in this paused state until it is activated again,onRestart, or stopped, onStop. If the activity is in this stopped state it can eitherbe restarted or if that is not the case, terminated. The way the other activitieslearn of the change of states for the other activities is through the callbackmethods. These callback methods control the flow of data so that when someactivities are stopped (maybe a telephone call interrupts the application) theycan later be resumed with required necessary data (6). With all these differentstates that an activity can be in one of the activities must be the first, andthat’s were the launcher activity comes into play. The launcher activity is thefirst thing a user will see when starting an application and is often referred toas the main activity.

Figure 3: Visual interpretation of and Android activity lifecycle.

2.4.2 Services

A service is a component that can, regardless of activity switches, run through-out the applications lifetime. This means that a service is very helpful whenthe application continuously needs to ”listen” for some kind of information. Aservice can also, importantly enough, run when the application who started it isin pause mode, e.g. the application is put into pause mode when a telephone callis received (7). For example, a notification in any kind of Android applicationis highly likely to there as a result of a service running in the background (8).

11

2.4.3 Graphical User Interface

An applications Graphical User Interface, referred to as GUI, is a somewhatloose term that defines all that is visible to the user. The mission of the GUI isto graphically show the user information, and/or to provide the user with theability to input information. Every application has a GUI, either only to showcertain information, but generally consisting of buttons etc. on which the usercan perform actions.

2.5 Database

2.5.1 SQL Database

SQL stands for Structured Query Language and is a set-oriented programminglanguage used for updating or query tables of information(9). The primary use ofSQL is to handle the data on a database by making it easy to modify (inserting,deleting, updating and querying) using tables consisting of dynamic rows orcolumns which contains all the information. Them being dynamic is due to thefact that the number of rows can easily be changed and the information thatthey contain is also easily modified (see figure 4 on page 12). SQL is also what isknown as a client-server database meaning that the client system communicateswith a server system. In a server, the program MYSQL is generally used toimplement SQL, whereas an Android application most often use SQLite.

Figure 4: Illustration of how the format of a typical SQL database might look.Source:http://www.thedecentralforest.com/?tag=database

12

2.5.2 Hibernate

Hibernate is an open-source library used to access an SQL database from a Java-class and obtain the database tables represented as Java-objects. Suppose youhave a table in an SQL database called Person. This table contains the columnsage, address and name. In other words, every person has the attributes: age,address and name. What then needs to be created, and what Hibernate willuse, is a Java-class called Person.java. Just like the table in the database wewant this object to have the same attributes. Therefor the class has to have theclass variables age, address and name as well as setters and getters for thesevariables .This class has to be formatted exactly as the code written in section 2.3.1 forHibernate to be able to identify it. Further on, Hibernate needs one last fileto start functioning. An XML-file, mapping the class to the table, called Per-son.hbm.xml, formatted as defined by the documentation of Hibernate. Whatthe XML-file does is that it tells Hibernate how to connect the table to theclass. When all that is done, Hibernate can read information from a databaseand by using its methods objects can instantly be obtained. So if the table calledPerson contains two different persons, Lisa and Anna, then reading that tablewould return a list of two Person.java-objects where the variables correspondwith the ones in the database.

2.6 Tools

2.6.1 Apache Maven

Maven is tool used, primarily, for creating Java based applications and is there-fore used in programs such as Eclipse. The way Maven functions is to auto-matically package the desired code into file types such as jar or war files. Thismeans that the code is easily stored and used by other projects who can simplyunpack the compiled code and run it(10). To make this process even easier,Maven also downloads the library, the library being the container of the API,you use and the library of the user which will utilize your project. This makesMaven an excellent tool for when creating large projects in which a multitudeof people may need to change the code.

2.6.2 andEngine

AndEngine is a graphics engine developed for Android as an open-source projectby the developer Nicholas Gramlich (11). It contains multiple examples andseveral extensions that can be used when developing a graphical application, forexample a game. The graphical activity will extend an andEngine activity andautomatically implement certain methods. With these methods the developercan set up the graphics for its game. More methods can be added to control theupdate of the graphics and to trigger events from the user input. The enginewill let you load images into sprites, as well as create own built in graphics,

13

which can be presented and modified at any time. Extensions can be used tocreate multiplayer functionality, run graphical testing among others.

2.7 Servlet

2.7.1 Apache Tomcat

Apache Tomcat is ”an open source software implementation of the Java Servlet”(12)where a servlet is a small program that runs on a server. This in contrast toan applet, which can be sent from a webpage and run on a client to performcertain actions. When a servlet is running on the server, it allows the server to”listen” and will then indicate to the webserver when the servlet was requested.This way, an Android application, for example, could send a request to a Javaservlet, which will process the request, and send a response.

3 Result

3.1 The communication of the entire application

The communication part of the application will be divided into two parts: theclient, which is the Android application sending requests to the server, andthe server, which is the Java servlet running on a Linux computer, extractingdata (if needed) from the database and returning response to the client. Bothof these implement a pre-existing communication layer developed by SwedenConnectivity. This communication layer, seen in figure 5 on page 14, will enableboth the client and server to send and receive data. It does nothing to interpretthe data but simply delivers the information.

Figure 5: Flow chart of the application in terms of the communication.

3.2 Communication in the client

The client will have the task of presenting the GUI for the user but behind allthis it needs to be able to communicate with the server and handle the response.

14

It needs to know when to send a request, what type of request to send and howto interpret the response and execute the things needed for every response.

The client application consists of multiple pre-existing classes used for the cal-culation of the position and within the framework of this project the additionof one activity and one service has been added, along with several other classesand a local database. The application has been developed using Googles An-droid Studio for Ubuntu. The service, called BeaconService, uses pre-existingcode to sense beacons continuously in the near area and broadcast this withinthe application. The activity, called GUIActivity, is this applications only ac-tivity and handles all the graphics as well as the processing of a newly sensedbeacon. This activity can be in two different states, either with a simple viewwhen the application is launched (see figure 6 on page 16) or with the GUIinitialized when navigating. The local database, meaning an SQLite database,is created by the application and stores all the downloaded information locallyon the device. In this part of the report we will not focus on the GUI but on theprocesses happening in the background when it comes to server communicationand response handling.

3.2.1 Trigger request from client to server

As mentioned in the introduction, the client will, together with the beacons,form the part of the application that the user will experience first hand. Thebeacons will serve a vital role in the calculation of the position, but they are alsoneeded to trigger a request from the client to the server. If we make the parallelto Google Maps navigation outdoors using GPS, the map will render when theusers position approaches the edge of the currently rendered map. The map ofthe entire world will not be loaded as soon as the application is started, insteadit will download the part of the map that is currently needed. This, of course,is to limit the data traffic needed to use the application as well as save localmemory space. So when designing the triggers for the communication in thisproject the approach was very similar.

The client will only send a request to the server if it arrives at a new equippedbuilding floor and if the time since the last visit has passed a certain time limit.A new equipped building floor is referring to a floor in a building, which isequipped with beacons, and that the user just entered. When the applicationstarts, the GUIActivity is loaded, which starts the service BeaconService and asimple graphical view (See figure 6 on page 16).The service will start listeningfor beacons and to achieve when to make the request the client will initially takethree things into consideration.

• Firstly, it will check if a request has already been sent without havinggotten a response back yet. This is to prevent the client from sendingmultiple requests without having handled the response from the previousrequest. At the start of the application there will be no previously sentrequests so this will always pass the first time.

15

Figure 6: Image of the simple view launched when the application starts.

• It will then make sure that the signal it receives indeed is a beacon. Thiscan be achieved in different ways depending on the way the beacons aremade. In this case we use the pre-existing functionality for the determi-nation.

• Finally, it will check if the beacon is on a floor that the application isalready presenting. This way, when walking around on a floor containingmultiple beacons, the application wont contact the server for every beaconit senses but only when it senses the first one on a new floor.

If all of these terms are true, the application will start processing the informationabout that current beacon it sensed to determine whether communication withthe server is needed. At this stage there could be three different cases. In thefirst two, the time frame is an arbitrary set time after which the local informationis assumed being too old.

• Information about the beacon is already existing in the local database andwas last updated within the predefined time frame.

16

• Information about the beacon is already existing in the local database butwas last updated outside the predefined time frame.

• Information about the beacon is not in the local database.

These three cases will result in different actions from the client. In the first,the activity will initialize the navigation GUI without server communicationand start listening for new beacons. For the second case, the client will senda request to the server checking the current version of the beacon, referredto as CHECK VERSION. The last case will trigger a request to download allnecessary information from that beacon, referred to as GET ALL.

3.2.2 Handle response on client

How the server handles the request and determines the response will be ad-dressed in section 3.3. The response will be a JSON object which the clientcan retrieve and get all the information from. It will mainly vary dependingon the two types of requests sent. Firstly, if the request is CHECK VERSIONthe response will contain the necessary information along with a message sayingwhat data was sent. The different responses in this case will be alterations of

• The local version of the information was the same as on the server, donothing.

• The local version of the information was not the same as on the server,store the attached information.

where the attached information will differ depending on how much of the localinformation that was different from the information on the server. At this stage,the client will store the information in its local database, if there was any, andinitialize the GUI and positioning. Secondly, if the request is GET ALL, theserver will respond with all the information regarding the sensed beacon and theinformation will be stored locally before initializing the GUI and positioning.

3.3 The server

The server contains a set of Java-files, referred to as the function layer, runningon a Tomcat7 servlet engine, referred to as tomcat, where tomcat is configuredto run both over HTTP and HTTPS (secure). It is configured and compiledusing Maven. What this means is that the entire project is compiled and thenruns on tomcat which creates a web server that can execute the function layerwhen a client connects to the server. Using the pre-existing communicationlayer the function layer can handle a request from a client which triggers anaccess of the servers SQL database and the process and sending of the responseto that client.

17

3.3.1 Handle request

The response sent from the server to the client will vary depending on the stateof information on the client, and on the server, as well as the kind of request sentfrom the client. As mentioned in section 3.2.1 the client can send two requeststo the server: GET ALL and CHECK VERSION. For the first one, the functionlayer in the server will use the sent information about the beacon to extract allthe necessary data from the SQL database and respond with that. It can alsonotify the client if the beacon does not exist on the server anymore, or if it isnot located on the same floor. In those cases, it will still send the current datafor the desired floor making sure that the information on the client is up todate. In case of the second request, the function layer will have to determinehow up to date the information on the client is. The request includes the clientscurrent version of its information and by comparing it to the servers version thefunction layer can determine what to respond to the client. The versioning isset up in a way so the server only responds with the information that is not upto date so the client can update its local database. A trivial example to paintthe picture would be if the client has three apples but the server has two applesand an orange. The request CHECK VERSION would then respond with anorange, but not with its two apples, and tell the client to replace the apple thatis not up to date with the sent orange.

3.3.2 Accessing the database using Hibernate

When handling every request the function layer needs to access and read in-formation from the SQL database. To make this transfer easily into the Javabased function layer the open-source library Hibernate has been used. Whatmakes this so convenient to use is the fact that every table in the databasehas corresponding Java-objects so when accessing and retrieving data from thedatabase the response will be a list of those objects (see section 2.5.2). By hav-ing the same object classes, referred to as entities, on the client, these entitiescan be sent in the response and then recreated in the client. This way, if weadd an attribute to an entity on the server we can, along with modifying a fewmethods, add the same attribute to the corresponding entity in the client andthe functionality will be kept without much work done.

3.3.3 Sending reponse

When the request has been processed in the function layer, using the accessto the database to acquire information, the response is ready to be sent. Thisresponse will consist all the necessary information and will be parsed into aJSON object, containing other JSON objects and JSON arrays. As mentionedin section 2.3.3 the advantage of using JSON is the fact that it can be sent fromone system to another and still be interpreted in the same way. In this case,we will simply use the built in toString()-method of the JSON object which canthen be retreived in the client. And by using the same JSON library in theclient the identical JSON object can finally be obtained from the sent string.

18

3.4 The activity in the client

The activity is always running, but before any positioning is to be done, it onlyshows a logo and some information (see figure figure 6 on page 16). When theprocess of identifying a new beacon, checking with the server (if needed) andprocessing the response is done the activity will be notified and the graphicaluser interface, GUI, will be initialized.

3.4.1 The navigation GUI

The GUI has been created using the graphics engine andEngine. Initially, whenthe GUI has been loaded, the map will be presented alongside the position andall the pre-defined places of that location (see figure 7 on page 20). The positionof the user is represented as the circle with the embedded arrow which presentsthe current direction the user is facing. At this point the user can scroll acrossthe map in all directions, as well as using multitouch (two fingers) to zoom inand out. The user can choose to lock the camera to the position by clicking thearrow button next to Navigate, meaning that the view will follow the positionas it moves, referred to as navigation mode (see figure 8 on page 21). In thisstate scrolling and zooming is not possible but can easily be re-enabled by onceagain clicking the arrow button.

When, and if, a user chooses to navigate to a certain position the Navigatebutton is clicked. The user is then presented with all the current possible des-tinations (see figure 9 on page 22). By clicking any of these destinations theactivity will calculate a route to that destination and present this to the user(see figure 10 on page 23). The navigation will continuously update as theuser approaches the navigation and therefor always present the user with thenavigation to its chosen destination.

If the user then reaches a different floor where new information is needed thiswill be processed just like in the case where the GUI had not yet been loaded,and the GUI will be re-initialized with the new information.

19

Figure 7: When GUI first has been loaded. Shows all the information and theuser is free to scroll across the map and zoom in and out.

20

Figure 8: View of when the user has chosen to lock the view to the position,navigation mode. It will now follow the position as it moves.

21

Figure 9: View of when the user chooses a destination to navigate to.

22

Figure 10: View of when a destination has been chosen and the navigation hasbegun.

23

4 Discussion

4.1 Server functionality

The server fulfills the set specifications and in a reliable way provides the clientwith the necessary information and at given time. It runs over secure HTTPSprotocol which further perpetuates the integrity and security of the applicationand the user. There are many different ways to develop a server of this form,but the one chosen has proven to be stable and to, in all tested conditions, workas desired.

4.2 Client functionality

The client functionality refers to everything on the client that does not involvethe GUI. These functions handle the sensed beacons, stored data and determinesthe action taken by the client. This functionality successfully lets a user ma-neuver through different parts of a building with the correct information shownto the user at any point. This could falter if the user looses internet connection,which could be an issue when navigating within buildings.

4.3 The graphical interface of the client

The GUI of the client has a very simple layout with the intention of beingintuitive and easy to use, with several features that should be easy to get a gripof. As with many other applications, the user can swipe and pinch to scroll andzoom. This improves the ability to get an overview of the map and is, becauseof the similarities to other applications, intuitively easy to learn. Furthermore,it mimics certain other applications with a single button to enable navigationmode, meaning that the GUI will follow the users position as it moves throughoutthe map. This is also believed to be easy to comprehend and useful when theuser simply follows the guiding to a desired destination. Finally, it displays thenavigation as a light blue thick line with an arrow at the end, pointing the userto its destination. This also should be convenient to understand and use.

The graphics engine will update the GUI at such a frame rate that it will beexperienced as smooth. This is though somewhat inhibited when the applica-tion is navigating. The algorithms used to calculate the current navigation aredemanding to the device, creating a lag in the graphics. Since smoothness al-ways is important when creating graphical applications this could very well bean issue.

The graphics for this application, such as the positioning circle, the buttons andthe navigation, is created using basic image editors. A lot more time could havebeen invested in creating these images. Even though something works, the lookand feel of it is always important for an applications appeal. In a market withmillions of apps, the need to stand out is vital (13). Because of this, companiesinvest heavily on applications designs to attract as many users as possible.

24

4.3.1 Using andEngine

The use of andEngine gives great tools to generate graphics to an application (seesection 2.6.2 on page 13). Just like when making a video game, the developmentof the graphical engine plays a huge role. It sets up all the rules for the graphics,and creates all the functionality to let the developer make the graphics behavethe way he or she wants to. To make yet another day to day comparison,when making a wok the cook could cut all the vegetables and protein and haveit all available and prepared when turning on the stove. This way, the cookcan just grab whatever he needs and put it into the pan. It creates some workbeforehand, but ultimately makes it a lot easier when producing the final result.

In this project the main motivation to use andEngine was the fact that thegraphics would by dynamic. Since the position most likely will change at acertain point, the graphics would have to update with a certain frame rateand modify the graphical information shown to the user. This could be doneusing built-in Android features but a graphics engine is so much more versatile,making it easier to develop in a more general fashion where things can easily bemodified. Instead of telling an Android view to redraw certain pixels within animage at a certain rate, we simply tell andEngine where to present the desiredsprite and it does this for us.

4.4 Testing the application

Testing of an application is always important and has been done throughout theentire process. The application has been tested programatically using JUNIT,which runs methods with the assertion of a certain outcome, and notifies whenany of these tests fail. This ensures the functionality of the written code. Furtheron, the application has been tested by actual users to test the intuitiveness ofthe GUI. This process ensured that users could in fact grasp how to use theapplication. Testing could have been done more extensively by, for example,letting users of different demographics test it.

4.5 Developing for other platforms

Currently the application solely support smartphones running the operatingsystem Android. If looking at the last quarterly sales, this would cover 78%of the current market (14). Of course, exporting the application to other op-erating systems, like Apples iOS, would be important to attract as many usersas possible. So if this would be done, iOS would be the main focus for furtherdevelopment.

25

5 Conclusions

The goal of this project was to make an indoor positioning system useful foran average smartphone user. By understanding the issues of the developmentand analyzing how such an application should function this goal has been met.The application successfully lets a user guide within a building equipped withthe system, from his or hers position to the desired destination. It continuouslyprovides the user with all the necessary information and therefor fulfills itstask. When tested, the application has seemed easy to use and has met therequirements of users.

5.0.1 Improvements of the application

The application has certain aspects that work but could be improved. Thegraphical interface tend to lag when navigating towards a destination. Thesolution to this issue would be to optimize the algorithms so that it limitsthe amount of needed calculations. The graphics could also be improved bycreating images in a professional application, such as Photoshop. This way,creating graphics that look more appealing to the user.

5.0.2 Further development of the application

The application could be extended in several ways to further improve the usersexperience. It could implement voice control, letting the user choose a desti-nation by voice commands. Also, it could use audio feedback, telling the userwhere it is heading, what the next move is and when it has reached its desti-nation. Furthermore, a useful property would be some sort of settings wherethe user can set different options to his or hers liking. These options couldfor example determine whether the user want audio feedback, if he or she onlywants to use WiFi to download data or if the map should rotate when the userdoes. Lastly, the application should show information of where this applicationcould currently be used. This way the user will know in which buildings usingthis application is currently available.

26

References

[1] Jones SHS. The development of navigation. Popular Astronomy, Vol 56,p263. 1948;56:263–267.

[2] Priyantha NB. The cricket indoor location system. Massachusetts Instituteof Technology; 2005.

[3] Nielsen. Smartphones: So many apps, so much time; 2014. Availablefrom: http://www.nielsen.com/us/en/insights/news/2014/smartphones-so-many-apps–so-much-time.html.

[4] Eclipse. What is Eclipse?; 2015. Available from:http://help.eclipse.org/luna/index.jsp?topic=

[5] Eclipse. Eclipse Java development tools (JDT); 2015. Available from:https://eclipse.org/jdt/.

[6] Google. Activities; 2015. Available from:http://developer.android.com/guide/components/activities.htmlCreating.

[7] Google. Services; 2015. Available from:http://developer.android.com/guide/components/services.html.

[8] Google. Notifications; 2015. Available from:http://developer.android.com/guide/topics/ui/notifiers/notifications.html.

[9] IBM. Tables, rows, and columns; 2015. Available from: http://www-01.ibm.com/support/knowledgecenter/SSPK3V6.3.0/com.ibm.swg.im.soliddb.sql.doc/doc/tables.rows.and.columns.html.

[10] Sonatype. Comparing Maven with Ant; 2015. Available from:http://books.sonatype.com/mvnref-book/reference/installation-sect-compare-ant-maven.html.

[11] Gramlich N. Andengine official homepage; 2015. Available from:http://www.andengine.org/.

[12] Apache. Apache Tomcat; 2015. Available from: http://tomcat.apache.org/.

[13] Manning Q. Noupe; 2012. Available from:http://www.noupe.com/imho/the-importance-creative-design-for-mobile-app-user-experience.html.

[14] IDC. Smartphone OS Market Share, Q1 2015; 2015. Available from:http://www.idc.com/prodserv/smartphone-os-market-share.jsp.

27