Indoor Positioning System

TVE 15 049 jun Examensarbete 15 hp Juni 2015 Indoor Positioning System Development of serverside functionality, client communication and a graphics ...
Author: Phillip Owen
55 downloads 3 Views 768KB Size
TVE 15 049 jun

Examensarbete 15 hp Juni 2015

Indoor Positioning System Development of serverside functionality, client communication and a graphics engine Pontus Arfwedson Joel Berglund

Abstract Indoor Positioning System Pontus Arfwedson & Joel Berglund

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala

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

Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

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

Contents 1 Introduction 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Indoor positioning . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Making an indoor positioning system useful for an end-user . . . 2 Theory 2.1 Application programming interface (API) . 2.2 Development environment . . . . . . . . . . 2.2.1 Integrated development environment 2.2.2 Android Studio . . . . . . . . . . . . 2.2.3 Eclipse . . . . . . . . . . . . . . . . . 2.3 Programming language . . . . . . . . . . . . 2.3.1 Java . . . . . . . . . . . . . . . . . . 2.3.2 XML . . . . . . . . . . . . . . . . . . 2.3.3 JSON . . . . . . . . . . . . . . . . . 2.4 Android . . . . . . . . . . . . . . . . . . . . 2.4.1 Activity . . . . . . . . . . . . . . . . 2.4.2 Services . . . . . . . . . . . . . . . . 2.4.3 Graphical User Interface . . . . . . . 2.5 Database . . . . . . . . . . . . . . . . . . . 2.5.1 SQL Database . . . . . . . . . . . . 2.5.2 Hibernate . . . . . . . . . . . . . . . 2.6 Tools . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Apache Maven . . . . . . . . . . . . 2.6.2 andEngine . . . . . . . . . . . . . . . 2.7 Servlet . . . . . . . . . . . . . . . . . . . . . 2.7.1 Apache Tomcat . . . . . . . . . . . .

. . . . . . . . (IDE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Result 3.1 The communication of the entire application . . 3.2 Communication in the client . . . . . . . . . . . 3.2.1 Trigger request from client to server . . 3.2.2 Handle response on client . . . . . . . . 3.3 The server . . . . . . . . . . . . . . . . . . . . . 3.3.1 Handle request . . . . . . . . . . . . . . 3.3.2 Accessing the database using Hibernate 3.3.3 Sending reponse . . . . . . . . . . . . . 3.4 The activity in the client . . . . . . . . . . . . . 3.4.1 The navigation GUI . . . . . . . . . . .

1

. . . . . . . . . .

. . . . . . . . . .

5 5 5 6

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

6 6 7 7 7 8 8 8 10 10 10 10 11 12 12 12 13 13 13 13 14 14

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

14 14 14 15 17 17 18 18 18 19 19

4 Discussion 4.1 Server functionality . . . . . . . . . . 4.2 Client functionality . . . . . . . . . . 4.3 The graphical interface of the client 4.3.1 Using andEngine . . . . . . . 4.4 Testing the application . . . . . . . . 4.5 Developing for other platforms . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

24 24 24 24 25 25 25

5 Conclusions 26 5.0.1 Improvements of the application . . . . . . . . . . . . . . 26 5.0.2 Further development of the application . . . . . . . . . . 26

2

Popul¨arvetenskaplig sammanfattning av projektet Indoor positioning - att guida en anv¨ andare inomhus Att ta sig fr˚ an ett st¨ alle till ett annat har aldrig varit l¨attare ¨an det ¨ar idag. GPS-teknologin och dess tillh¨orande appar g¨or att en bilresa idag n¨astan helt kan utf¨ oras genom att lyssna p˚ a en r¨ost fr˚ an mobiltelefonen. Men hur g¨or man om man befinner sig p˚ a ett stort k¨opcenter och letar efter den d¨ar butiken man ar ute efter? D˚ ¨ a GPS endast fungerar utomhus finns idag inget utbrett alternativ f¨ or den som vill underl¨atta sin navigering i st¨orre ok¨anda inomhusmilj¨oer. Markanden f¨ or detta torde vara stor, och ett stort antal f¨oretag, s˚ a som Google och Apple, arbetar f¨ or att f¨ orverkliga effektiv positionering inomhus. Till skillnad fr˚ an GPS finns det ett stort antal olika teknologier att rikta in sig p˚ a. En stor del av f¨ oretagen anv¨ander sig av WiFi d¨ar signalstyrkor kan avl¨asas fr˚ an olika n¨ atverk f¨ or att uppskatta anv¨andarens position. Detta f¨oruts¨atter att det finns flera tr˚ adl¨ osa n¨ atverk tillg¨angliga f¨or att skapa en p˚ alitlig position. Ett annat alternativ ¨ ar att lagra stora m¨angder information om signalstyrkor fr˚ an WiFi p˚ a s˚ a m˚ anga positioner som m¨ojligt och med dessa uppskatta anv¨andarens mest troliga position, kallat fingerprinting. Vidare inneh˚ aller alla moderna telefoner ett flertal sensorer som kan bidra med information om hur anv¨andaren r¨or sig. Accelerometer, gyro och kompass ¨ar exempel p˚ a sensorer som vissa f¨oretag f¨ ors¨ oker utnyttja f¨ or att ber¨akna anv¨andarens r¨orelse och position. Dessa sensorer genererar dock ett f¨orh˚ allandevis stort fel ¨over tid och det kan d¨arf¨or diskuteras om de verkligen a¨r anv¨andbara. M˚ anga f¨oretag f¨ors¨oker ¨aven kombinera flera system, f¨ or att eliminera s˚ a m˚ anga fel som m¨ojligt, utan de blir f¨or dyra. Att m¨ ojligheterna p˚ a marknaden f¨or inomhuspositionering ¨ar stora r˚ ader det inga tvivel om, enligt Don Dodge, Developer Advocate p˚ a Google, som driver sin egna portal dondodge.com. Men system ger ofta s˚ a stora fel att de har sv˚ art att bli anv¨ andbara i praktiken. S˚ a fr˚ agan om n¨ar vi f˚ ar se ett system som tar over marknaden kvarst˚ ¨ ar, men att det blir verklighet i framtiden kan bara ses som ett faktum.

3

DISCLAIMER This report contains only the information that is not classified as a part of the project. 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 information that could be used to reproduce the project is not presented.

4

1 1.1

Introduction Background

For as long as humans has had the urge to discover new places and find their way, navigation has been a central key to succeeding in those areas. In the earlier days, navigation by the stars slowly developed into using compasses and today the Global Position System (GPS) can give us a very precise position almost anywhere in the world (1). Using GPS for outdoor location information has 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 where it is insufficient. To decide the position of person in an indoor environment using a GPS the signal is often too weak to penetrate the walls and roofs of buildings. Furthermore, the GPS might be able to approximate the coordinate of that person but will not be able to tell which floor in the building he or she is currently on. Therefor, GPS serves no real use when navigating within buildings and there are yet to come an application which has that ability and that has been widely spread. The use of applications for mobile devices has increased drastically during the last years and will most likely keep on increasing (3). With that increased use there comes opportunities for developers to create useful applications to serve the needs of users or enhance part of their lives. Since devices are equipped with different sensors, transmitters and receivers these can be used, just like using an application which implements the GPS-receiver, to determine different things about 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. It could be used to let robots navigate inside buildings, for sensor networks (where location is of value) as well as entertainment (2). For these purposes standalonedevices (meaning: not smartphones) could be produced and implemented and systems possibly created to determine position and other significant parameters. But another purpose could be to simply guide a person, inside an unfamiliar building, from one place to another. And for this, the smartphones are an obvious choice considering how many people use them on a daily basis. But since they are not dedicated to that sole purpose, and may have certain limitations to what can be modified and accessed, a developer would have to do the best he or she can from the tools that are available when developing such an application.

5

1.3

Making an indoor positioning system useful for an end-user

This project builds of an already existing IPS, developed by the engineering company Sweden Connectivity. This system can determine the position of an Android smartphone in an enclosed space. This space is equipped with devices, which will be referred to as beacons, that along with the application in the smartphone forms the system. Just like with a GPS-application, where the receiver along with the smartphones interface can give a person his or hers current coordinates, that information alone is not of much use. If you are not an experienced navigator and have a physical map of the entire globe in your back-pocket (or your mind), you need more than only the coordinates to actually use a GPS-signal in a meaningful way. The same applies to an IPS. Such a system needs to not only supply the user with his or hers position. It needs to make it mean something, and around that, develop functionality so that the user can, from his or hers position, use the application in a beneficial way. So how can the Android application of that existing system be extended and modified so that it is convenient and can be used efficiently for the average smartphone user? For this project the development will partly be to enhance and modify the Android application (the client), but also to develop a server with functionality that 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 arise when creating a client application alongside a server, and with this understanding create a reliable system that makes sure the client application has all the necessary information when needed. Furthermore, the client needs to have a graphical interface that is easy to handle and creates usefulness from the IPS to the user.

2 2.1

Theory Application programming interface (API)

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

6

Figure 1: Visualization of the API

2.2 2.2.1

Development environment Integrated development environment (IDE)

An IDE is a program that serves as a tool when developing applications in a certain language. It does this by supporting the user with a wide array of tools such as a debugger, compiler and a text editor. This way a developer can edit the code, see all the different available methods and compile the code into the application, all in one place. Two of the most known examples of IDE’s are Android 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 programs no longer receives any official support from Google. To program in Android Studio efficiently a Software Development Kit, SDK, is downloaded and used which enables the user to access built in features such as a complete API to all the 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 layout consists of easy to access menus for the code and also a clear overview when creating the actual layout of the application with drag-and-drop functionality. Out of the two languages, Java is the language that the Android development builds 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 the right the easy to modify GUI

2.2.3

Eclipse

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

2.3 2.3.1

Programming language Java

Java is an object-oriented and class-based programming language. This means that 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 the object is an instance of a class. Java is, as said, an object-oriented language which 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 change or return the attributes of an object. An example of this are the methods seen in the code below which are the ”get” and ”set” methods. These setters and getters are, in this case, simple methods that either set a variable, or return a variable. To illustrate an object being an instance of a class, imagine creating a Person-object by using the class below. Having created this person, lets call it ”person1”, this does not limit the user for creating more persons e.g. ”person2”,”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 of text-code, known as tags, that is only visible when coding and not when the document is shown in its final form. This means that XML is useful when dealing with layouts, text and pictures etc. As seen below, an example can be seen when creating a button in Android which will, in this case, display a button containing the text ”Hello”. //XML button

2.3.3

JSON

JSON which stands for JavaScript Object Notation is a text based format for transferring and storing data. The advantages for using JSON is due to the fact that it works when sending data between different kinds of applications who can 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 transferable from almost any programming language to another, using built in JSON parsers.

2.4 2.4.1

Android Activity

An android activity can be described as the graphical view a user can interact with on their device. To visualize this, every time the window of an android application switches to another one, an activity is created whilst the previous one is paused. This means that each activity has its own layout which is shown when it is displayed for the user. In actual development an activity can simply be stated as being a Java-class that has extended a predefined Activity class. Extending a class means the integration of the extended classes methods into the 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 through the onCreate stage which is followed by the onStart stage where the activity will start running. After this stage, actions in the application could start new activities that will go through the same onCreate and onStart stage and, when switching 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 either be restarted or if that is not the case, terminated. The way the other activities learn of the change of states for the other activities is through the callback methods. These callback methods control the flow of data so that when some activities are stopped (maybe a telephone call interrupts the application) they can later be resumed with required necessary data (6). With all these different states that an activity can be in one of the activities must be the first, and that’s were the launcher activity comes into play. The launcher activity is the first thing a user will see when starting an application and is often referred to as 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 throughout the applications lifetime. This means that a service is very helpful when the application continuously needs to ”listen” for some kind of information. A service can also, importantly enough, run when the application who started it is in pause mode, e.g. the application is put into pause mode when a telephone call is received (7). For example, a notification in any kind of Android application is 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 somewhat loose term that defines all that is visible to the user. The mission of the GUI is to graphically show the user information, and/or to provide the user with the ability to input information. Every application has a GUI, either only to show certain information, but generally consisting of buttons etc. on which the user can perform actions.

2.5 2.5.1

Database SQL Database

SQL stands for Structured Query Language and is a set-oriented programming language used for updating or query tables of information(9). The primary use of SQL 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 or columns which contains all the information. Them being dynamic is due to the fact that the number of rows can easily be changed and the information that they contain is also easily modified (see figure 4 on page 12). SQL is also what is known as a client-server database meaning that the client system communicates with a server system. In a server, the program MYSQL is generally used to implement 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 Javaclass and obtain the database tables represented as Java-objects. Suppose you have a table in an SQL database called Person. This table contains the columns age, address and name. In other words, every person has the attributes: age, address and name. What then needs to be created, and what Hibernate will use, is a Java-class called Person.java. Just like the table in the database we want this object to have the same attributes. Therefor the class has to have the class variables age, address and name as well as setters and getters for these variables . This class has to be formatted exactly as the code written in section 2.3.1 for Hibernate to be able to identify it. Further on, Hibernate needs one last file to start functioning. An XML-file, mapping the class to the table, called Person.hbm.xml, formatted as defined by the documentation of Hibernate. What the XML-file does is that it tells Hibernate how to connect the table to the class. When all that is done, Hibernate can read information from a database and by using its methods objects can instantly be obtained. So if the table called Person contains two different persons, Lisa and Anna, then reading that table would return a list of two Person.java-objects where the variables correspond with the ones in the database.

2.6 2.6.1

Tools Apache Maven

Maven is tool used, primarily, for creating Java based applications and is therefore used in programs such as Eclipse. The way Maven functions is to automatically package the desired code into file types such as jar or war files. This means that the code is easily stored and used by other projects who can simply unpack 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 makes Maven an excellent tool for when creating large projects in which a multitude of people may need to change the code. 2.6.2

andEngine

AndEngine is a graphics engine developed for Android as an open-source project by the developer Nicholas Gramlich (11). It contains multiple examples and several extensions that can be used when developing a graphical application, for example a game. The graphical activity will extend an andEngine activity and automatically implement certain methods. With these methods the developer can set up the graphics for its game. More methods can be added to control the update of the graphics and to trigger events from the user input. The engine will 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 to create multiplayer functionality, run graphical testing among others.

2.7 2.7.1

Servlet 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 to an applet, which can be sent from a webpage and run on a client to perform certain 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 Java servlet, 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: the client, which is the Android application sending requests to the server, and the server, which is the Java servlet running on a Linux computer, extracting data (if needed) from the database and returning response to the client. Both of these implement a pre-existing communication layer developed by Sweden Connectivity. This communication layer, seen in figure 5 on page 14, will enable both the client and server to send and receive data. It does nothing to interpret the 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 all this 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 how to interpret the response and execute the things needed for every response. The client application consists of multiple pre-existing classes used for the calculation of the position and within the framework of this project the addition of one activity and one service has been added, along with several other classes and a local database. The application has been developed using Googles Android Studio for Ubuntu. The service, called BeaconService, uses pre-existing code to sense beacons continuously in the near area and broadcast this within the application. The activity, called GUIActivity, is this applications only activity and handles all the graphics as well as the processing of a newly sensed beacon. This activity can be in two different states, either with a simple view when the application is launched (see figure 6 on page 16) or with the GUI initialized when navigating. The local database, meaning an SQLite database, is created by the application and stores all the downloaded information locally on the device. In this part of the report we will not focus on the GUI but on the processes happening in the background when it comes to server communication and 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. The beacons will serve a vital role in the calculation of the position, but they are also needed to trigger a request from the client to the server. If we make the parallel to Google Maps navigation outdoors using GPS, the map will render when the users position approaches the edge of the currently rendered map. The map of the entire world will not be loaded as soon as the application is started, instead it 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 local memory space. So when designing the triggers for the communication in this project the approach was very similar. The client will only send a request to the server if it arrives at a new equipped building 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 is equipped with beacons, and that the user just entered. When the application starts, the GUIActivity is loaded, which starts the service BeaconService and a simple graphical view (See figure 6 on page 16).The service will start listening for beacons and to achieve when to make the request the client will initially take three things into consideration. • Firstly, it will check if a request has already been sent without having gotten a response back yet. This is to prevent the client from sending multiple requests without having handled the response from the previous request. At the start of the application there will be no previously sent requests 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. This can be achieved in different ways depending on the way the beacons are made. In this case we use the pre-existing functionality for the determination. • Finally, it will check if the beacon is on a floor that the application is already presenting. This way, when walking around on a floor containing multiple beacons, the application wont contact the server for every beacon it 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 information about that current beacon it sensed to determine whether communication with the server is needed. At this stage there could be three different cases. In the first two, the time frame is an arbitrary set time after which the local information is assumed being too old. • Information about the beacon is already existing in the local database and was last updated within the predefined time frame. 16

• Information about the beacon is already existing in the local database but was 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 communication and start listening for new beacons. For the second case, the client will send a request to the server checking the current version of the beacon, referred to as CHECK VERSION. The last case will trigger a request to download all necessary 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 addressed in section 3.3. The response will be a JSON object which the client can retrieve and get all the information from. It will mainly vary depending on the two types of requests sent. Firstly, if the request is CHECK VERSION the response will contain the necessary information along with a message saying what 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, do nothing. • 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 local information 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, and initialize the GUI and positioning. Secondly, if the request is GET ALL, the server will respond with all the information regarding the sensed beacon and the information 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, running on a Tomcat7 servlet engine, referred to as tomcat, where tomcat is configured to run both over HTTP and HTTPS (secure). It is configured and compiled using Maven. What this means is that the entire project is compiled and then runs on tomcat which creates a web server that can execute the function layer when a client connects to the server. Using the pre-existing communication layer the function layer can handle a request from a client which triggers an access of the servers SQL database and the process and sending of the response to that client.

17

3.3.1

Handle request

The response sent from the server to the client will vary depending on the state of information on the client, and on the server, as well as the kind of request sent from the client. As mentioned in section 3.2.1 the client can send two requests to the server: GET ALL and CHECK VERSION. For the first one, the function layer in the server will use the sent information about the beacon to extract all the necessary data from the SQL database and respond with that. It can also notify the client if the beacon does not exist on the server anymore, or if it is not located on the same floor. In those cases, it will still send the current data for the desired floor making sure that the information on the client is up to date. In case of the second request, the function layer will have to determine how up to date the information on the client is. The request includes the clients current version of its information and by comparing it to the servers version the function layer can determine what to respond to the client. The versioning is set up in a way so the server only responds with the information that is not up to date so the client can update its local database. A trivial example to paint the picture would be if the client has three apples but the server has two apples and an orange. The request CHECK VERSION would then respond with an orange, but not with its two apples, and tell the client to replace the apple that is 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 information from the SQL database. To make this transfer easily into the Java based function layer the open-source library Hibernate has been used. What makes this so convenient to use is the fact that every table in the database has corresponding Java-objects so when accessing and retrieving data from the database the response will be a list of those objects (see section 2.5.2). By having the same object classes, referred to as entities, on the client, these entities can be sent in the response and then recreated in the client. This way, if we add an attribute to an entity on the server we can, along with modifying a few methods, add the same attribute to the corresponding entity in the client and the 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 access to the database to acquire information, the response is ready to be sent. This response will consist all the necessary information and will be parsed into a JSON object, containing other JSON objects and JSON arrays. As mentioned in section 2.3.3 the advantage of using JSON is the fact that it can be sent from one 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 can then be retreived in the client. And by using the same JSON library in the client 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 only shows a logo and some information (see figure figure 6 on page 16). When the process of identifying a new beacon, checking with the server (if needed) and processing the response is done the activity will be notified and the graphical user interface, GUI, will be initialized. 3.4.1

The navigation GUI

The GUI has been created using the graphics engine andEngine. Initially, when the GUI has been loaded, the map will be presented alongside the position and all the pre-defined places of that location (see figure 7 on page 20). The position of the user is represented as the circle with the embedded arrow which presents the current direction the user is facing. At this point the user can scroll across the map in all directions, as well as using multitouch (two fingers) to zoom in and out. The user can choose to lock the camera to the position by clicking the arrow button next to Navigate, meaning that the view will follow the position as it moves, referred to as navigation mode (see figure 8 on page 21). In this state scrolling and zooming is not possible but can easily be re-enabled by once again clicking the arrow button. When, and if, a user chooses to navigate to a certain position the Navigate button is clicked. The user is then presented with all the current possible destinations (see figure 9 on page 22). By clicking any of these destinations the activity 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 the user approaches the navigation and therefor always present the user with the navigation to its chosen destination. If the user then reaches a different floor where new information is needed this will 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 the user 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 has begun.

23

4 4.1

Discussion Server functionality

The server fulfills the set specifications and in a reliable way provides the client with the necessary information and at given time. It runs over secure HTTPS protocol which further perpetuates the integrity and security of the application and 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, work as desired.

4.2

Client functionality

The client functionality refers to everything on the client that does not involve the GUI. These functions handle the sensed beacons, stored data and determines the action taken by the client. This functionality successfully lets a user maneuver through different parts of a building with the correct information shown to 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 being intuitive and easy to use, with several features that should be easy to get a grip of. As with many other applications, the user can swipe and pinch to scroll and zoom. This improves the ability to get an overview of the map and is, because of the similarities to other applications, intuitively easy to learn. Furthermore, it mimics certain other applications with a single button to enable navigation mode, meaning that the GUI will follow the users position as it moves throughout the map. This is also believed to be easy to comprehend and useful when the user simply follows the guiding to a desired destination. Finally, it displays the navigation as a light blue thick line with an arrow at the end, pointing the user to 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 be experienced as smooth. This is though somewhat inhibited when the application is navigating. The algorithms used to calculate the current navigation are demanding to the device, creating a lag in the graphics. Since smoothness always is important when creating graphical applications this could very well be an issue. The graphics for this application, such as the positioning circle, the buttons and the navigation, is created using basic image editors. A lot more time could have been invested in creating these images. Even though something works, the look and feel of it is always important for an applications appeal. In a market with millions of apps, the need to stand out is vital (13). Because of this, companies invest 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 (see section 2.6.2 on page 13). Just like when making a video game, the development of 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 behave the 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 have it all available and prepared when turning on the stove. This way, the cook can just grab whatever he needs and put it into the pan. It creates some work beforehand, 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 the graphics would by dynamic. Since the position most likely will change at a certain point, the graphics would have to update with a certain frame rate and modify the graphical information shown to the user. This could be done using 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 be modified. Instead of telling an Android view to redraw certain pixels within an image at a certain rate, we simply tell andEngine where to present the desired sprite and it does this for us.

4.4

Testing the application

Testing of an application is always important and has been done throughout the entire process. The application has been tested programatically using JUNIT, which runs methods with the assertion of a certain outcome, and notifies when any of these tests fail. This ensures the functionality of the written code. Further on, the application has been tested by actual users to test the intuitiveness of the GUI. This process ensured that users could in fact grasp how to use the application. 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 operating system Android. If looking at the last quarterly sales, this would cover 78% of the current market (14). Of course, exporting the application to other operating systems, like Apples iOS, would be important to attract as many users as possible. So if this would be done, iOS would be the main focus for further development.

25

5

Conclusions

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

Improvements of the application

The application has certain aspects that work but could be improved. The graphical interface tend to lag when navigating towards a destination. The solution to this issue would be to optimize the algorithms so that it limits the amount of needed calculations. The graphics could also be improved by creating 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 users experience. It could implement voice control, letting the user choose a destination by voice commands. Also, it could use audio feedback, telling the user where it is heading, what the next move is and when it has reached its destination. Furthermore, a useful property would be some sort of settings where the user can set different options to his or hers liking. These options could for example determine whether the user want audio feedback, if he or she only wants to use WiFi to download data or if the map should rotate when the user does. Lastly, the application should show information of where this application could currently be used. This way the user will know in which buildings using this 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 Institute of Technology; 2005. [3] Nielsen. Smartphones: So many apps, so much time; 2014. Available from: http://www.nielsen.com/us/en/insights/news/2014/smartphonesso-many-apps–so-much-time.html. [4] Eclipse. What is Eclipse?; 2015. http://help.eclipse.org/luna/index.jsp?topic=

Available

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

from:

Available from:

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

from:

[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://www01.ibm.com/support/knowledgecenter/SSPK3V6 .3.0/com.ibm.swg.im.soliddb.sql.doc/doc/tables.rows.an [10] Sonatype. Comparing Maven with Ant; 2015. Available from: http://books.sonatype.com/mvnref-book/reference/installation-sectcompare-ant-maven.html. [11] Gramlich N. Andengine official homepage; http://www.andengine.org/.

2015.

Available from:

[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-mobileapp-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

Suggest Documents