• No results found

A Mobile Assistant for Location-Based Services and Indoor Navigation

N/A
N/A
Protected

Academic year: 2021

Share "A Mobile Assistant for Location-Based Services and Indoor Navigation "

Copied!
78
0
0

Loading.... (view fulltext now)

Full text

(1)

IT 16 072

Examensarbete 45 hp September 2016

ExpoMate

A Mobile Assistant for Location-Based Services and Indoor Navigation

Christian Zentner

Institutionen för informationsteknologi

(2)
(3)

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

ExpoMate

Christian Zentner

Companies, that aim to expand their customer base, will find it important to advertise new products at exhibitions. However, the huge, international exhibitions that are common nowadays, are a hassle for visitors, vendors and organisers likewise. Due to the size, a lot of information needs to be published for the visitors, so that they can find their way across the exhibition area, locate the stands they are interested in and exchange their business information. In a digital age, where almost every person owns at least one mobile device, all this information is still distributed as printed handouts and business cards, which wastes a lot of paper and produces unnecessary trash.

This thesis report describes the development of a mobile application, that replaces the handouts in a digital, non-polluting way, and also succeeds the usefulness of its paper counterpart. This application allows its users to browse through general exhibition information and categorised lists of all the stands on the area. The use of iBeacons enables location-based features that help to locate the user, as well as stands of interest, and can provide an overview of the current surroundings at any time.

Additionally, navigational features assist the visitors in finding their way to stands they want to visit.

By using an application like this, a lot of work and money can be saved for organising such an event. The design and priting of exhibition information, including the list of all companies and their stands, and the obligatory exhibition map, would not be necessary any more. Also, the mobile application offers some features to the visitors that allows them to save time, which also increases the throughput of the exhibition.

Examinator: Mats Daniels Ämnesgranskare: Justin Pearson Handledare: Yan Liu

(4)
(5)

Contents

1 Introduction 7

1.1 Background . . . 7

1.2 Motivation . . . 8

1.3 Related Research . . . 9

1.4 Goals . . . 10

2 Foundations 11 2.1 iOS Platform . . . 11

2.1.1 Objective-C . . . 12

2.1.2 UIKit . . . 14

2.1.3 Quartz 2D . . . 15

2.2 iBeacon Technology . . . 17

2.2.1 iBeacon Protocol . . . 18

2.2.2 Estimote . . . 19

2.3 JSON Format . . . 20

2.3.1 GeoJSON . . . 20

2.4 REST Architecture . . . 21

3 Features 23 3.1 Information Overview . . . 23

3.2 Location-Based Services . . . 23

3.2.1 Nearby Stands . . . 24

3.2.2 Quick Exchange and Bookmarks . . . 24

3.2.3 Notifications . . . 24

3.3 Navigation . . . 24

3.3.1 Map View . . . 24

3.4 Use Cases . . . 25

3.4.1 Browse Information . . . 25

3.4.2 View Nearby Stands . . . 26

3.4.3 Manage Bookmarks . . . 26

3.4.4 Get Directions . . . 26

(6)

Contents

4 Design 29

4.1 Project Organisation . . . 29

4.1.1 Development Process . . . 29

4.1.2 System Distribution . . . 30

4.1.3 Design Patterns . . . 32

4.2 User Interface . . . 37

4.2.1 Presentation . . . 37

4.2.2 Quick Exchange . . . 41

4.2.3 Notifications . . . 42

4.3 Navigational Features . . . 42

5 Implementation 45 5.1 Hardware and Software . . . 45

5.2 Data Model Management . . . 45

5.2.1 Server Interaction . . . 47

5.3 iBeacon Integration . . . 49

5.3.1 Monitoring . . . 49

5.3.2 Ranging . . . 52

5.4 Map View . . . 55

6 Evaluation 59 6.1 Test Conditions . . . 59

6.2 Information Overview . . . 60

6.3 Location-Based Services . . . 62

6.4 Navigation . . . 63

7 Conclusion 67 7.1 Summary . . . 67

7.2 Assessment . . . 68

7.3 Current Issues . . . 69

8 Future Work 71 8.1 Suggested Improvements . . . 71

8.1.1 Exhibition Setup . . . 71

8.1.2 Duplicated Notifications . . . 72

8.1.3 More Specific Notifications . . . 72

8.2 Further Projects . . . 73

8.2.1 Map Editor . . . 73

8.2.2 Web Interface . . . 73

(7)

Chapter 1 Introduction

This chapter gives an overview of the context of the thesis and describes the background for the project. Here, the general processes of visiting a trade fair are described and problems with the current situation are highlighted. Possible improvements brought by this thesis project are explained and similar projects are introduced. Eventually, the main goals of the thesis are summed up.

1.1 Background

Trade fairs have always been an important opportunity for companies to intro- duce their latest developments and give an overview of their product catalogue.

Recent fairs have grown dramatically in size and often feature exhibitors from all around the world, like for example the Auto China international automo- tive exhibition with around 2000 exhibitors from 14 countries [4]. The total exhibition area often covers several hundred thousand square meters and is usually divided into different sectors. The largest fairs, often for the automo- bile industry, have more than one million visitors within only a few days.

At the entrance of a trade fair, large maps of the area give new visitors an overview of the different sectors. There are usually printed versions of the map that also include a list of companies or categories and where to find these on the map. Often, each sector is assigned a different category, so that visitors, who are only interested in a certain category, can limit their search on the respective sector. Once they reached the given sector, they have to locate their stands of interest by themselves. Larger companies also often have a large range of products and thus might be present in more than one sector.

If visitors want to get information about products of such a company that do not belong to the sector’s category, they will have to search for that company’s stand in the according sector.

On the exhibition area, there is one stand next to the other and every company is trying to attract as many visitors as possible. The representatives

(8)

Chapter 1. Introduction

hand out booklets with brief information about interesting products to every- one who is passing by their stand. More detailed information can then be obtained at the stand itself in case a visitor is interested in a shop’s products.

For this purpose, there are usually printed catalogues and further booklets.

1.2 Motivation

Although trade fair organisers spend great efforts on providing visitors a smooth experience during their stay at an exhibition, there are some shortcomings in the described process. One point that needs improvement is the huge amount of printed booklets distributed during such an event. Every visitor gets an information brochure containing the list of companies, a map of the exhibition area and possibly general information about the fair. Next, at every stand they pass by, they get another booklet with general information about the company represented by that stand, even if they are not particularly interested in this company. At the end of the day, most of these booklets end up in the trash or even on the floor.

A further problem is posed by the navigation within the exhibition area.

Given the huge dimensions of many trade fairs, finding stands for companies or products a visitor is interested in can take a long time. Organisers have to fit all stands of a certain category into a given section and make sure visitors can find them easily enough by providing maps and signs. If visitors are interested in products by a certain company that belong to different categories, they have to find the company’s stand in each of the section the company has stands in.

By improving these aspects, an exhibition could become much more attrac- tive for visitors, exhibitors, organisers and the environment. Visitors should be able to search through the information of all participating companies, se- lect stands they are interested in and get notifications when they are close to one of them and be able to locate any stand on the exhibition area with ease. Exhibitors could save a lot of money by reducing the amount of printed information and increase their sales by targeting visitors that are actually in- terested in their products. Organisers would not have to be that concerned about a perfect division of stands into sectors and the throughput of the trade fair might be increased if the visitors find their stands faster. Finally, a lot of paper could be saved if the information would be distributed digitally.

This thesis project intends to tackle the problems mentioned above by in- troducing a mobile application that assists visitors during their stay at an exhibition. The app should provide the visitor with all the information that so far is available in printed form. Apart from just showing a long list of items, a more user friendly presentation should improve the visitors experience and make it easy to find objects of interest. Location-based services should be intro- duced, that highlight possibly interesting stands within the visitors proximity.

(9)

1.3. Related Research

This can be achieved using the fairly new iBeacon technology introduced in the next chapter. Additionally, the app should support the visitor’s navigation, showing a map of the area and highlighting the position of selected stands. An approximate position of the visitor could also be displayed, depending on the density of the beacon distribution.

1.3 Related Research

Though the iBeacon technology is relatively new, there are already some large scale projects that make use of the transmitters to provide indoor location- based services. Most of these projects aim at simplifying shopping in large stores and supporting customers in finding products within the store and pro- viding detailed information about goods. Other projects are targeted towards museums, replacing the simple audio guides with apps that interact with iBea- cons. In such an environment, the app could automatically detect what object the visitor is looking at and provide interactive, audio-visual information.

Probably the largest and earliest application of the iBeacon technology was within the Apple Stores in the United States. By the end of 2013, Apple had equipped all of its shops with beacons [14]. Customers, who use the official Apple Store app, can get notifications related to the store they are visiting.

At first, the provided functionality was quite limited. Upon entering a shop, the customer would get a notification that encourages to view product reviews or purchase items using EasyPay [21].

Another large project that makes use of beacons for indoor location-based services was started by Philips [19] as a demonstration and study of possible new customer services. For this project, Philips developed their own beacon system, similar to Apple’s iBeacon, that is integrated into intelligent lighting units. A shop using these to light their interior also covers the whole area with a grid of beacons. Using the companion app, customers can view a map of the shop and their position. Furthermore, they can search for products and get directions through the app. In the future, applications like these might allow customers to create a shopping list based on recipes that are provided by the app. The app then creates a shortest route through the shop that passes all ingredients on the list and guides the shopper through the aisles.

Apart from these specific projects, there are also more general products, like Beepsquare [6], that are not tailored towards a certain event. Beepsquare provides a whole generic content management system and mobile marketing platform for stores and events. It allows unskilled personnel to design and create a website using a drag-and-drop application. The website will also include a management platform for beacons to simplify setup and maintenance.

Furthermore, it provides detailed statistics about the beacons, that can be used by the shop keeper or organiser to evaluate visitor behaviour and find potential

(10)

Chapter 1. Introduction

weak spots in the layout of their area.

1.4 Goals

The main objective of this thesis project is to enhance the experience of exhibi- tion visitors and reducing the amount of wasted paper during exhibitions. To achieve these objectives, the mobile application, developed during the project, should offer a convenient and unobtrusive way of digital information exchange as well as features that help visitors to navigate across the exhibition area.

Such an application could improve the efficiency of the visitors so they can find interesting products in a short amount of time, which might also raise the amount of visitors that can be handled per day. Furthermore, it reduces the amount of paper that is wasted during the exhibition, which reduces the cost for the companies and also increases the environmental quality. The mo- bile application developed during this thesis project should mainly be capable of providing the following functions to visitors, which should be achieved in cooperation with the server, developed in parallel as another thesis project:

• Display product information and highlight location-based information.

• Support a quick an easy to use information exchange function.

• Offer a fast and convenient way to save interesting information.

• Guide the visitor across the exhibition area.

The application should show brief information about the stands and their products in the close proximity of the visitor. It should also provide more detailed information on demand, trying not to overwhelm the user with a huge load of data, accumulated by all the stands around the user. Important information needs to be highlighted or trigger a notification to gain the user’s attention. Data should be categorised to provide a better user experience.

A map, showing the position of the beacons, representing the stands, should help to navigate through the exhibition. The position of the visitor should be estimated and shown on the map. Stands with products, that are determined as interesting for the user, should be highlighted to guide the user during his visit.

As a result, the developed application should be able to replace the infor- mation that has previously been distributed in paper form and provide these in a more clear and categorised way. Additionally, navigational features should support the visitors in finding their way through the exhibition area and locate the products of their interest.

(11)

Chapter 2 Foundations

The following sections will introduce the technologies used for this thesis project. Since the main focus of the thesis is the development of a mobile application for Apple’s mobile devices, an important part of these technolo- gies is the iOS platform, including its main programming language and the most important libraries. Apart from these, the iBeacon technology will be explained as well as formats and protocols used for the communication with the server.

2.1 iOS Platform

Apple’s iOS platform is the foundation for all of Apple’s mobile devices. This operating system is a version of the Mac OS X operating system used for Apple’s desktop computers, stripped down and optimised for the use on mobile devices [35]. By using the established Mac OS X as a base system for iOS, Apple could easily reuse of a lot of features needed for a sophisticated mobile operating system. These features include multitasking, networking, power management, security, audio, video and many others [7].

Developers can create their own iOS applications using the development tools provided by Apple [36]. The IDE (Integrated Development Environ- ment) Xcode provides an interface to all these tools. The main features are typical development functions like a fully featured code editor with semantic code completion, a debugger and profiler for analysing the program to locate errors and performance issues, a visual user interface designer including the Storyboard, a way to graphically define the flow within the user interface and a convenient menu for accessing project settings like linked libraries or compiler options. Furthermore, it provides a function to deploy the mobile application for testing, either on the integrated iOS emulator, or directly on a phone con- nected via USB. This allows for a fast turnaround cycle and encourages to test even the smallest changes on the device.

(12)

Chapter 2. Foundations

Apart from the powerful IDE, Apple’s development environment also pro- vides a variety of useful libraries [18]. Since the main programming language, Objective-C (described in the following section), does not provide a large stan- dard library, the features provided by Apple speed up the development process a lot. There are libraries for basic data types and algorithms, as well as frame- works for all the advanced features the iOS platform has to offer. Two of the most important frameworks used for this thesis project will be described in more detail in this chapter.

2.1.1 Objective-C

Except for the newly introduced language Swift, which was unveiled at the WWDC (Apple Worldwide Developer Conference) in 2014 as a new program- ming language for the OS X and iOS operating systems, Objective-C is the main programming language for developing applications on these platforms [2]. The main APIs (Application Programming Interfaces), namely Cocoa and Cocoa Touch, as well as large parts of the operating systems themselves, are implemented in Objective-C.

The reason for Objective-C being used as the main programming language instead of C++, which is used by most of the other popular operating systems nowadays, can be found in the history of the OS X system [26]. When it was first mentioned at the WWDC 1998, Apple announced that it would inherit from the older Apple systems Mac OS and Rhapsody, the latter being based on NeXT, a system developed by the NeXT Computer startup of Steve Jobs in the mid 80s. Since this system was completely written in Objective-C, OS X adopted to the language and continued using it as its main language.

Since the introduction of Apple’s mobile devices, the programming language gained popularity at a very high rate and quickly became one of the most used programming languages [15].

Object-Oriented Programming

The language itself is similar to C++ in that it builds on top of C and en- hances it with object-oriented programming features [28]. Objective-C is also a strict superset of C, which means it is allowed to include pure C code within an Objective-C program. The syntax for operations on objects, however, was bor- rowed from Smalltalk [9], an early object oriented language that uses message passing, as shown in listing 2.1, to perform operations on objects instead of calling methods on the object directly, like in C++ (listing 2.2). This is a fun- damentally different concept, which also allows the designer to leave messages unimplemented, whereas in C++ all non-abstract methods need to provide an implementation.

(13)

2.1. iOS Platform

1 [o b j e c t m e s s a g e:a r g u m e n t];

Listing 2.1: Message passing in Objective-C

1 o b j e c t.m e t h o d(a r g u m e n t) ;

2 o b j e c t P o i n t e r- >m e t h o d(a r g u m e n t) ;

Listing 2.2: Method invocation in C++

Following the C convention for separating interface declarations form their actual implementations, Objective-C code is usually divided into two files: A .h file, the so-called header, which includes the definition of the interface, and a .m file for the implementation code. Though it is possible to combine both into one file, the interface still has to be declared in a separate code block from the implementation.

An example class interface is displayed in listing 2.3. The interface contains declarations of instance variables, instance methods (starting with a minus sign), and class methods (starting with a plus sign). Class methods can be called on the class directly, without a reference to an instanced object, similar to the static methods in C++. Also, class methods can not access instance variables, as there might not even be an instance of the class.

1 @ i n t e r f a c e P o i n t 2 D {

2 int x;

3 int y;

4 }

5 - (f l o a t)d i s t a n c e T o P o i n t:(P o i n t 2 D)p o i n t;

6 + (P o i n t 2 D)c r e a t e P o i n t A t X:(int)x a n d Y:(int)y;

7 @ e n d

Listing 2.3: Example of a class interface declaration

In the example declaration of the createPointAtX:andY: method can be seen, that two parameters are passed to the method. In front of the second parameter, the y coordinate, there is a part of the function name, separated by a colon. This part is called a label for the parameter. Labels are another subtle difference introduced by Smalltalk’s message passing style. They offer the additional benefit that they can be used to name parameters using self- explaining labels. This makes method calls in Objective-C much more readable and reduces the risk of passing wrong parameters to a method.

Another language feature offered by Objective-C addresses the boilerplate code, that needs to be written in other object-oriented in order to define acces- sor methods to encapsulated instance variables. In order to allow a fine-grained access mechanism for these variables, special methods used to set and retrieve the value of the variable need to be implemented [10]. Objective-C offers

(14)

Chapter 2. Foundations

the @property directive, shown in listing 2.4, which is used to define object properties with certain options that can for example regulate the access. The compiler then generates accessor methods automatically based on the prop- erty definition. This again simplifies the implementation and makes it easy to define access rights to properties without changing the implementation code at all.

1 @ p r o p e r t y (r e a d o n l y) int x;

Listing 2.4: Defining an object property

Memory Management

Given its close relation to C, memory, used in an Objective-C program, needs to be allocated and freed explicitly by the programmer [1]. This manual mem- ory management is known to allow for a very fine-grained definition of memory allocation and can improve the memory usage compared to automatically man- aged memory. However, manual memory management is also a source of many memory leaks. For every block of memory allocated by a program, the pro- gram also needs to give the region free if it is no longer used. This often leads to problems because in some circumstances, it is hard to define which part of the program should free the memory, and sometimes a programmer might forget to free it at all. In case memory gets freed to early and is still used by other parts of a program, the effort to access the freed region will result in a memory access violation and the whole application will crash.

To overcome these difficulties, Apple announced a revised version of the Objective-C language in 2006, which also includes a garbage collector — an automatic memory management system that checks for unused memory at runtime [17]. In modern versions, it has been replaced with an automatic reference counting (ARC) mechanism, which is performed during compile-time, and thus does not have a direct impact on the performance of the code [32].

Programs that make use of ARC do not have to worry about when and where to release the allocated memory. Instead, the compiler will detect unused memory and insert operations that free these regions automatically. This is another huge benefit compared to languages with manual memory management, as it removes the risk of memory leaks and memory access violations and also frees the programmer from paying attention to these details.

2.1.2 UIKit

Graphical User Interfaces (GUI) in general provide a visually more pleasing, and potentially easier to use, interface for human interaction. While the use of GUIs is not necessary on traditional computers, that provide hardware to

(15)

2.1. iOS Platform

input commands efficiently, it is a central point for mobile devices that usually only offer a touch display for input. The quality of a mobile app GUI is an important factor for its usability and needs to provide a clear structure and easy navigation.

The iOS Platform provides the UIKit framework for creating GUIs for mo- bile applications [33]. Through the UIKit, it is possible to create and interact with a wide variety of visual elements optimised for the mobile devices. In combination with Apple’s default development environment, the Xcode IDE, UIKit GUIs can be designed and connected using the graphical editor called Storyboard [27]. In this editor, a mobile application’s GUI can be assembled by connecting multiple view that show one page of information. Each of these views can be built by dropping the desired components into the view. The arrangement of the components is handled by a dynamic layout engine that ensures correct positioning for different screen sizes.

A large selection of components for creating sophisticated interfaces are provided by the framework. They cover standard input and output elements like buttons, text fields, labels, but also provide more complex types like search- able lists with configurable row elements. These components allow for a faster development of the user interface and also give the app a consistent look and feel.

2.1.3 Quartz 2D

Drawing in OS X and iOS is supported via the native two-dimensional draw- ing engine Quartz 2D [24]. The purpose of a drawing engine is to display geometrical shapes and other graphical elements, like text or images, on a vir- tual canvas. Since the engine is part of the system libraries, it also integrates seamlessly with other parts, like the UIKit, which provides for a frictionless user experience.

Quartz 2D employs the widespread painter’s algorithm to organise the structure of the canvas [22]. As shown in figure 2.1, a request to draw an object will show the object on top of the previously painted objects — just like a painter draws new shapes on top of a partly finished painting. Once an object is drawn, it can not be modified anymore. It is, however, possible, to clear the whole canvas by drawing a rectangle with the size of the whole canvas using the desired background colour.

All drawing commands are issued on a graphics context, an object that rep- resents the destination of the virtual canvas [22]. Since Quartz 2D integrates well will other libraries, a graphics context can draw on certain UIKit com- ponents to display the canvas directly in a mobile application. The context also supports drawing on other destinations, like PDF files or printers. All parameters and device-specific information needed to perform issued drawing

(16)

Chapter 2. Foundations

Figure 2.1: Drawing order in the painter’s algorithm (Apple Inc.)

Figure 2.2: Paths consisting of different basic shapes (Apple Inc.)

commands are also maintained by the graphics context.

Paths

In order to use the graphics engine to draw a geometrical shape, the shape first needs to be defined, to give precise instructions about how to draw it. These instructions are encoded in a special path object, which holds the coordinates and other information about the shape. A path in a Quartz 2D environment represents a single or multiple shapes [23]. These shapes can be simple points or lines, or complex polygons constructed by combining many simpler shapes into one, as shown in figure 2.2.

A path can be constructed in different ways. The Quartz 2D programming

(17)

2.2. iBeacon Technology

interface provides functions to directly create a path by defining basic geo- metric shapes like lines or rectangles. Furthermore, paths can be extended by appending additional shapes to the path object. The resulting path objects can either be displayed and discarded immediately, or stored as a reference for further drawing operations.

The visual appearance of a path can be manipulated using the options provided by the engine. Typical changes include the width of the strokes or their colour and visibility. For closed paths, a filling colour can be applied, which fills the enclosed area with the given colour. More detailed options include line dashing patterns and join styles.

Transformations

Many applications that employ a graphics engine will have features that need to display a set of graphical objects based on the current view point. An obvious example is a three-dimensional game, where the player moves a vir- tual character and manipulates the viewing directions based on user input.

The navigational features of the mobile application, developed for this thesis project, make use of similar techniques to implement functions like scrolling through the map as well as zooming into and rotating the map.

Since these operations need to affect every object, applying the necessary transformations separately on each individual object would cost a lot of com- puting power. Instead, the mathematical properties of transformation matrices can be harnessed to combine all the computations that need to be performed on the objects. Using this technique, only one matrix operation needs to be performed on an object, which can reduce the amount of computations dra- matically.

The Quartz 2D graphics engine supports the use of transformations and supplies data types and functions that apply typical transformations, like translations and rotations [31]. However, in order to get the correct results, it is crucial to apply the matrices in a specific order. For example, if an object should be rotated around its centre, it first needs to be moved into the cen- tre, then rotated by the desired degree, and finally moved back to its original position. Given the properties of matrix multiplication, these operations need to be performed in inverse order, because the last operation, performed on the matrix, will be the first operation to be applied on the object.

2.2 iBeacon Technology

Applications on devices running iOS can make use of the Core Location frame- work to locate the current position of the device [20]. The framework mainly uses the devices wireless connection to determine its location, like the mo-

(18)

Chapter 2. Foundations

bile cell tower, WiFi or, if enabled, GPS [3]. With iOS 4, the Core Location introduced geofences, a method of detecting the entry or exit of a certain re- gion. This method, however, relies on the location service of the Core Location framework, which can only estimate an approximate position within a larger area and is not suited for indoor location.

For the release of iOS 7, Apple introduced a new location feature, the iBeacon protocol, based on the new Bluetooth Low Energy (BLE) standard, which was released in 2010 [25]. The feature requires an iBeacon to be present at the location of interest, which can then be detected by a user’s device and be used to approximate its location within a very short range. That allows for detection of entry and exit of very small regions around the position of the beacon, even within a building.

The iBeacon technology offers a new level of interaction between a mobile application and the user’s environment. This allows application developers to provide users with exactly targeted information like notifications, reminders or advertisements. Furthermore, a lot of information about the user’s behaviour can be obtained, which can help shops and other operators, to evaluate the current situation and provide important statistics.

2.2.1 iBeacon Protocol

An iBeacon is a small BLE sender that broadcasts its identifier within a range of about 40 to 50 meters, which in turn can be used to query the beacons location and other information from a server. The identifier consists of a UUID, a major and a minor part [34]. The UUID is a 16 byte string used to differentiate between beacons of a certain application. The major and minor identifiers are 2 byte strings that identify a small group of beacons within the whole set of beacons used for the application, and an individual beacon respectively.

As an example for the usage of the identifiers, consider the iBeacons in the Apple Stores mentioned in the introduction. All beacons could share the same UUID to identify them as Apple Store beacons. The major number could then be used to distinguish between beacons in different stores, so that all beacons in a certain store share the same major number. Finally, the minor number is used to identify each individual beacon within the store.

To use the iBeacons as a location service, there are two more important steps to be performed. Once the broadcasting beacon has been identified, an application needs to get more information about the beacon. This can be done by querying a master server that maintains a list of all beacons and associated data. The server could then tell the application the exact position of the beacon and, for example, its role in the current environment.

Next, the application needs to determine the devices distance to the beacon.

(19)

2.2. iBeacon Technology

This is done by comparing the strength of the received signal, measured by the receiving device, with the power used to transmit the signal, which was measured by the beacon and included in the signal. Using this information, the distance to the beacon can be approximated. However, the signal strength can be significantly influenced by the environment, which makes it unsuitable for exact positioning within buildings. Because of this drawback, the distance to a beacon is not given exactly in meters, but rather divided into regions.

These regions are defined as following [8]:

• Immediate: up to 0.5 meters

• Near: 0.5 to 2 or 5 meters

• Far: 2 or 5 meters or more

These regions, in combination with the position of the beacon, as reported by the server, can now be used to estimate the location of the device. Fur- thermore, these regions can be used to trigger events within an application, like display a certain notification if a user enters the immediate region of a beacon, which is similar to using the geofences, just on a much smaller scale and suitable for indoor application.

2.2.2 Estimote

Since the iBeacon technology is just a standard specification, there are many different companies that provide products that implement the standard. The products usually differ in size, battery life, provided libraries and included software. The beacons used for this thesis project application are manufactured by Estimote [11]. Their beacons are advertised featuring a long battery life of 3 to 5 years and include many features like motion and temperature sensors, wireless updates as well as management and analytics software, that should make it easy to set the beacons up and maintain them.

Another benefit of using the Estimote beacons is the API provided by the Estimote SDK [12] (Software Development Kit), that makes it easy to integrate the beacons with a mobile application. Instead of using the Core Lo- cation framework directly to interact with iBeacons, the ESTBeaconManager, a wrapper around the CLLocationManager, can be used, which provides addi- tional functionality, like filtering and sorting. This simplifies the development and supports the overall integration process.

An additional feature of the Estimote SDK is the trigger engine, that can be used to trigger events based on custom rules, that can include a specific distance or state of a beacon. This could be helpful to send conditional no- tifications to the device’s user. Finally, the SDK provides integration with

(20)

Chapter 2. Foundations

the Estimote Cloud, another Estimote service that adds management and an- alytics functionality, which can help to maintain a larger amount of deployed beacons and gather statistics.

2.3 JSON Format

The JSON Format is a data exchange format designed to be easily readable and writable by both humans and machines [30]. Its long name, JavaScript Object Notation, reveals its syntactic relationship with JavaScript, which was used as a basis for the design of the format’s syntax. Owing to this, programmers familiar with C-style programming languages will immediately be familiar with the structure of a JSON document, what makes it an ideal exchange format.

In a JSON document, data is structured using two common types of con- tainers, an object, which is a collection of key-value pairs, and an ordered list of values. Since these data structures are implemented in almost every mod- ern programming language, the content of a JSON document can be handled naturally in such languages. For the types of keys and values, certain restric- tions apply. Keys can only be represented as strings. Values allow much more options and can not only represent strings, numbers and boolean values, but also the two basic JSON structure, which allows for nested data.

Given its simplicity, JSON is a reasonable alternative to more advanced formats like XML. The benefits for having such a simplistic format is that it makes it easy to check and modify JSON data by hand, as well as a less sophisticated implementation of a parser, which can improve the performance for parsing larger documents. However, there are certain limits to the JSON format. It is, for example, impossible to embed binary data within a JSON document.

2.3.1 GeoJSON

GeoJSON is a format based on JSON, used to store geographical data, like locations and areas [29]. It uses the same syntax as JSON, but restricts the layout of the document. A GeoJSON document only contains one single object, which in turn can contain other objects and lists. The main object also needs to define a pair with the key type and a certain value. The value determines the purpose of the main object, whether it, for example, just represents a point or contains a collection of geometries. Based on the type, other restrictions apply.

Since the format is specialised in storing geographical data, it is well-suited as a textual representation and an exchange format for the map used in this application. The fact that it is a subset of the JSON format also allows for

(21)

2.4. REST Architecture

seamless integration with the tools used for transmitting non-geographical data using the standard JSON format.

A simplified version of a map used for navigation could be represented by the following GeoJSON code, where the coordinates of geometry objects correspond to the features’ pixel coordinates in the generated map image:

1 { " t y p e ": " F e a t u r e L i s t ",

2 " f e a t u r e s ": [

3 { " t y p e ": " F e a t u r e ",

4 " id ": " E x h i b i t i o n H a l l ",

5 " g e o m e t r y ": {

6 " t y p e ": " P o l y g o n ",

7 " c o o r d i n a t e s ": [

8 [0 , 0] , [0 , 10] , [10 , 10] ,

9 [10 , 0] , [0 , 0]

10 ]

11 }

12 } , {" t y p e ": " F e a t u r e ",

13 " id ": " S t a n d 1 ",

14 " g e o m e t r y ": {

15 " t y p e ": " P o i n t ",

16 " c o o r d i n a t e s ": [2 , 5]

17 }

18 }]

19 }

Listing 2.5: Simplified map in GeoJSON format

2.4 REST Architecture

The Representational State Transfer (REST) architecture describes the funda- mental design of the World Wide Web [13]. The architecture aims at improving the quality of network services by imposing several design constraints. A ser- vice that complies to all the constraints is considered RESTful, and by design is capable of handling high loads of traffic. The most commonly used commu- nication protocol employed in combination with RESTful services is HTTP, using the same requests a web browser issues to fetch a website from, and post form data to a web server.

In order to qualify as a RESTful service, several constraints need to be fulfilled. For example, the service needs to follow the client-server model, which decouples the client from the server side and increases scalability and maintainability. Another important constraint is that the service needs to be stateless, which means the server does not store any client state between two separate requests. This enables a range of benefits like load balancing and caching. Several other constraints provide further improvements that ensure

(22)

Chapter 2. Foundations

that the service is capable of providing quality service under load.

Nowadays, RESTful services are used at many places where network in- teraction is required. Typical examples are websites or phone apps that fetch data from a central server. For these tasks, the REST architecture not only ensures the quality of the service, but also simplifies its usage, because it offers a simple interface for communication. The client just needs to do a request to a given URI (Uniform Resource Identifier) using, for example, a HTTP GET request, and would receive the requested data in response. The data is often encoded using JSON, but other formats are supported as well, like HTML is used to display websites.

(23)

Chapter 3 Features

In this chapter, the features of the mobile application will be listed and their intentions described on a pure functional level. Their actual design will be discussed in the following chapter. The app is divided into three main sections which provide the fundamental functionality. The basic requirements for this application is to provide location-based services to interact with nearby stands and to provide navigational assistance across the exhibition area. Furthermore, a general overview should give the user access to all shops at the exhibition in a clear and concise way.

3.1 Information Overview

The initial view of the ExpoMate app is the information overview. In this overview, general information about the exhibition is presented to the user, like the name of the exhibition, a short introduction text and the address of the event. Furthermore, functions to list all vendors, present on the exhibition area, are available. The user can list vendors by category, to get an overview of which categories are available and which vendors have stands belonging to these categories. There is also a searchable list of all vendors that offers a fast way to look up known vendors. The vendor information contains a short description of the company and their products, as well as a list of stands that are on the exhibition, including their location.

3.2 Location-Based Services

Location-based services improve the user experience by adjusting the content of the app according to the user’s location on the exhibition area. The app makes use of iBeacons to detect nearby stands as described in chapter 5. Using this information, the app can roughly estimate the user’s location and provide the user with information about stands in the proximity.

(24)

Chapter 3. Features

3.2.1 Nearby Stands

The nearby stands list shows all the stands that are currently close enough to the phone, such that it receives a signal from the beacons positioned at these stands. The list is sorted by the estimated distance to the stand, showing the closest stands first. This allows the user to quickly get an overview about the stands that are within a limited range.

3.2.2 Quick Exchange and Bookmarks

To help the user manage contact information about stands with interesting products, the user can add a vendor to the bookmarks list by using the quick exchange feature. This feature is the equivalent of the exchange of business cards. If the user is close to a certain stand, the quick exchange can be initiated by shaking the phone. This will add the vendor information of the closest stand to the bookmarks list. Now the user can access this information any time by just checking the bookmarks.

3.2.3 Notifications

As soon as the user approaches an exhibition hall, the phone will start receiving the signal of the beacons within this hall. Based on this signal, the app will be able to identify the hall based on the major number of the beacon identifier.

If the user has previously bookmarked stands that are in this same hall, the application will send a notification to remind the user about these stands.

3.3 Navigation

The navigational features aim to assist the user in finding the way across the exhibition and remove the need for printed maps. In coordination with the use of iBeacons and the server, which gathers information about all users on the exhibition, the app can also highlight certain stands.

3.3.1 Map View

On the map view, a sketch of the exhibition area is shown, including the different halls and the respective stands. The user can zoom into the map and move it around, like the maps of other navigational phone applications, to deal with larger maps for huge exhibitions. Based on the location information obtained by the beacons, the stand that is closest to the user will be marked as the approximate position of the user. If the map view was called in order to find a certain stand on the area, it will be highlighted on the map, so it is easy to distinguish from all the other stands.

(25)

3.4. Use Cases

Figure 3.1: Use case diagram showing possible use cases

3.4 Use Cases

The way these features can support an exhibition visitor during an exhibition will be further detailed by presenting use cases that cover typical activities the user would be interested in. For all these use cases, the visitor represents the main actor. Moreover, the scope of the use cases is the ExpoMate app, and they all belong to the user goal level. Figure 3.1 gives an overview of the use cases and the smaller subfunctions they contain.

3.4.1 Browse Information

The visitor is still at home and wants to prepare for the exhibition visit. Within the main screen, the visitor obtains a general description of the event and its address. Because the visitor is only interested in vendors of a certain category, the category list is used to select the category of interest. Upon selecting the category, a list of all stands that belong to the category is shown to the visitor.

Now, the visitor can scroll through the list of these stands and click on items to view more information about each stand.

The detail information show which kind of items the stand exhibits and in which hall it is located. Furthermore, it holds a reference to the vendor. Upon selecting the vendor, the visitor is presented with general information about the vendor, its contact information and a list of all stands the visitor has on this exhibition.

Next, the visitor is looking for a certain vendor, but does not know which

(26)

Chapter 3. Features

category its stands belong to. The visitor opens the list of all stands and uses the search function to filter the list according to the input. After typing a few characters, the list is minimised to only a few items and the visitor sees the stands of the vendor of interest. Again, the visitor accesses the stand details by selecting one of these stands.

3.4.2 View Nearby Stands

During the exhibition visit, the visitor wants to get an overview of the stands within the close proximity. On the nearby stands view, the user is presented with a list of all stands which beacon signals are received by the app. The visitor scrolls through the list and finds a stand of interest. By selecting the stand, the stand details are revealed.

The visitor is interested in the stand and approaches it, so that it is now the closest stand and shown on top of the list. The visitor wants to keep the information associated with that stand for a later review and uses the quick exchange gesture to add it to the bookmarks list.

3.4.3 Manage Bookmarks

The visitor has already bookmarked several stands. Within the bookmarks list, the visitor scrolls through all these items and selects a few of them to show the associated stand information. The visitor realises that one of the bookmarked stands is not relevant and decides to remove it from the list.

Browsing through the information of another stand, the visitor finds a new stand that is of interest. Using the function within the stand detail view, the visitor adds the stand to the list of bookmarks. When the visitor enters the hall that contains the newly added stand, a notification is shown that reminds the visitor of the bookmarked stand.

3.4.4 Get Directions

Because of the huge dimensions of the exhibition, the visitor got lost on the exhibition area. Using the map view, the visitor can see a map of the whole area. The stand that is closest to the visitor is highlighted, which provides a rough estimation of the visitor’s location. Based on these information, the visitor now can navigate across the area.

Since the visitor is looking for a certain stand, the visitor makes use of the show on map function within the stand’s detail view. The function redirects to the map view, but now a second stand is highlighted next to the closest stand. The other highlighted stand is the stand the visitor is looking for.

The visitor starts walking into a certain directions. When approaching another stand, the visitor sees that the closest stand now is farther away from

(27)

3.4. Use Cases

the destination. This shows the visitor that the stand of interest is in the opposite direction.

(28)

Chapter 3. Features

(29)

Chapter 4 Design

In the following sections, the design of the application will be described in detail. This will not only be limited to the visual design of the user interface, but also include the approach of developing the ExpoMate app and the lay- out of the source code. The design patterns applied during the development of this project will also be explained, using their application as an example.

Eventually, the representation of the exhibition map and the features included in the map view will be shown.

4.1 Project Organisation

This section will introduce the basic structure of the project as well as common processes and patterns applied during its creation. In order not to lose con- trol over the development of the ExpoMate application, the right development process has been considered carefully, despite the fact that no communication with an external customer was necessary. The complex structure of the appli- cation was simplified by the application of design patterns, that also allow for easier implementation and maintenance.

4.1.1 Development Process

Although this project was not driven by a customer’s interest, a common devel- opment process has been chosen for the implementation and evaluation of the applications features, in order to avoid the pitfalls unorganised development is known for.

One option for the development was to plan the whole project in a first phase, then starting to implement everything within a second phase and finally evaluate the functionality, which would correspond to the waterfall model.

This model in general is easy to maintain, because each phase is totally com- pleted, before the next phase begins. However, this does not allow for modifica-

(30)

Chapter 4. Design

Figure 4.1: Deployment diagram showing the distribution of the system

tions once the planning phase is done. Furthermore, if there are any problems with the realisation of the plan during the implementation phase, it is impos- sible to go back to the planning phase.

The downside of the waterfall model is most noticeable, when the customer is not sure about how the final product should look like. Since there was no customer for this thesis project, this would not be a problem. Still, planning every detail from the beginning is a difficult task to get right, especially if one is not familiar with the involved platform. Additionally, there should be the option to be open for new ideas and features during the course of this project, hence, such a static process should be avoided.

Instead, an iterative design process was chosen, that aims to focus at a few features at a time. These features should then be planned and implemented, similar to the waterfall model, but within a much shorter amount of time.

After their evaluation, a new iteration was initiated by reflecting on the design so far. The new iteration could then introduce new features or improve existing ones, depending on the needs at that stage. This process allows for a much more dynamic approach to yield the desired results, even though there was no third party to consult in between the iterations.

4.1.2 System Distribution

The ExpoMate app is only one part of a larger system. In order for the application to work, it needs to integrate with other components and access remote information. While some of these components are running on other devices than the phone that hosts the app itself, there is also a part that is running within the iOS platform on the users phone. Figure 4.1 shows all of the components that make up the whole system and shows how they are deployed and connected with each other.

For the iOS app, the mobile device is the main device needed for the exe- cution. The phone will run the application and provide its features, like Blue- tooth and network connections, to the application. Through the CoreData framework, the app also makes use of another component that is running on

(31)

4.1. Project Organisation

Figure 4.2: Activity diagram showing the interaction with the beacons

the users phone, namely the database. The ExpoMate app needs to store certain information permanently on the phone. The data is managed by the CoreData framework, which will use the local database to persist the data within the phone.

The beacons are separate devices that run permanently and independent from the iOS app. Each beacon can be set up and managed through the Esti- mote web interface. In order to interact with the ExpoMate application, the signal sent by the beacons needs to be registered by the app. This communi- cation is done via the Bluetooth low energy (BLE) profile, which is designed to consume little energy and thus enables the beacons to stay online for a long time by only using a small battery as power source.

In figure 4.2, the interaction between the mobile application and the beacon is shown in detail. The first step for using the advanced beacon functions that provide the list of nearby beacons is to activate the beacon ranging function- ality. When nearby beacons are registered, an event will be triggered that the application has to handle. First, the locally stored beacon information gets updated based on the list of registered beacons. Next, the observers, described in the following sections, are notified of the updated information. Finally, the execution branches, where one part returns to handling the next event if the ranging is still active, and the other part updates the view and terminates.

The third part in the system is the server that provides the mobile appli- cation with data. The server is running on a more powerful machine that is capable of handling multiple requests from many users. The server application, which is developed as another thesis project, is written in Java and makes use of the Spring framework to handle requests from the phone app. The server offers a REST interface that allows the mobile application to send requests over HTTP. The data is encoded using the JSON format for the transfer and needs to be decoded once received.

The steps for the communication with the server are shown in figure 4.3.

When the application starts, it will try to load the general exhibition informa- tion. If the database contains information about the exhibition, it will load the

(32)

Chapter 4. Design

Figure 4.3: Activity diagram showing the interaction with the server

data from the database and subsequently display the load data. If there is no related data stored in the database, the app will contact the server and obtain the data via the RESTful API. Once the data is received, it is transformed into objects that can be used with the CoreData framework. These objects are then inserted into the database and can then be retrieved from the database.

4.1.3 Design Patterns

The large amount of different libraries and technologies involved with the cre- ation of a mobile application in general, and this project in particular, requires to structure the code in a smart way, such that the coupling of classes is re- duced and parts can be extended and reused easily. The common way to achieve this, is to recognise common problems early during the design phase, and apply known design patterns, that solve the problem in a proven and elegant way.

Model-View-Controller

Throughout the libraries, that Apple provides for use with its mobile platform iOS, many design patterns are already applied. One of the core pattern, that can be found in many applications from all kinds of areas, is the Model-View- Controller (MVC) pattern. This pattern divides the code into three parts: The model will represent the objects the application deals with, which often are abstractions of real-world objects. All their data will be stored in these model objects, and objects can have relationships with other objects. The view defines the visual representation of the application. For the mobile applications, this will be the actual user interface shown on the mobile device. View objects are usually provided by the platform, like the UIKit provided by the iOS platform, which also follow the MVC pattern.

Finally, the controller handles the interaction between the model and the view in a way, that both do not interact with each other directly. That allows both the model and view objects to be reusable. If the user modifies some data within the user interface, this change will be forwarded to the controller. The controller then decides how to handle this event and modifies the model as

(33)

4.1. Project Organisation

needed. If the model changes, either by an event originated from the user via the view, or by any other part of the application, the change will be detected by the controller, which often works using the observer pattern discussed later.

The controller then reads the new model data and updates the view.

As mentioned earlier, this is a very fundamental pattern which is already partly implemented by the UIKit library. However, the user interface needs to be constructed according to the needs of the application. Within the Xcode IDE, there is a graphical editor for user interfaces called storyboard. Such a storyboard is used to create single screens and decorate them in any possible way. Further, it can define connections between screens that define transitions from one to the other. This allows the developer to define large parts of the view layer within the graphical editor. All other tasks, like filling fields and tables within the views, are done by the controller.

Next, the model and controller parts need to be implemented. The model can be represented in many different ways. For the sake of this project, another iOS library has been chosen to maintain the model data, namely the CoreData stack, which provides for a clean and easy definition of model objects and also handles the database integration that is needed for persistence. In combination with Apple’s Xcode development environment, the objects for the model part can be created and set up in a visual editor. Within the editor, objects, or entities, can be created and filled with data fields, called attributes. In order to connect entities with each other, relationships can be defined between to objects. These relationships can either be to-one or to-many relationships, and should always have a counterpart that makes it possible to traverse the object graph in both directions.

Once the entities are defined within the model editor, the IDE can generate actual classes from these definitions. That allows other parts of the applica- tion to address these entities with a specific class name instead of the generic super class for model objects. Furthermore, these classes can be extended with custom functionality that belongs to the certain entity.

The last, missing part to implement the MVC pattern, is the controller.

To handle basic user interface functionality, Apple already provides default controllers for standard view objects. These need to be extended in order to handle custom features, and the resulting child object of the default con- troller needs to be set as the handling controller for each view object. Thus, each screen, presented in the ExpoMate app, is backed by a separate, custom controller class.

As mentioned earlier, the controller has to connect the model with the view. In order to react to user input via the user interface, input events need to call into the controller code. With the Xcode editor, this is done by defining connections between elements in the view and methods in the controller class.

If the user triggers the action associated with the view element, the view will

(34)

Chapter 4. Design

forward that action to the controller and pass the necessary information as parameters. Now the controller can execute that action, which may alter the model as well. In order to change data shown in the view, properties of the controller class can be connected to elements in the view, similar to the way the methods are connected to them. Now the controller can access these elements directly and modify them accordingly.

Observer

The observer pattern is a design pattern that allows one part of the application to detect changes within another part. The main benefit for using this pattern is that it avoids a strong relationship between the two parts. This attribute is achieved by the definition of an interface that defines the interaction between the two participants. First, the part that wants to get notified of the change, which is also called observer, registers with the other part, known as subject.

The subject stores the observer in a list of observers, and when it changes its state, it will notify each registered observer. The observer then can decide how to handle this notification.

Once this relationship is established, the subject can maintain several ob- servers that may be of different types. Thanks to the abstract connection, the subject does not need to be modified in order to accept a new type of observer.

The same applies for the observer, which can observe several different subjects without having a tight relationship to these objects. Additional information needed to distinguish the subjects can be included in a notification message as a parameter of the callback method.

Within the iOS platform, the observer pattern can make use of the notifi- cation centre. This object plays the role as a global manager for notifications in an iOS application and further decreases the coupling between subject and observer. Using the notification centre, the subject can post a notification for a given name, including itself as the sending object and further information as needed. An observer can then add itself as observer for notifications with the given name, and register a callback function to be called for incoming notifications.

As mentioned earlier, this design pattern is often used in combination with the MVC pattern. The controller usually observes the model, so that it can detect changes in the data. The minimal coupling introduced by the observer pattern helps to establish the layering of the MVC pattern, so that the coupling between the model and the controller objects is as loose as possible.

Another use case within the ExpoMate project is the update of the nearby stands list. As explained in more detail in chapter 5, the EMBeaconManager holds a list of beacons that are within close proximity of the user. This list gets updated every second to provide up-to-date distance information about the beacons, and to add or remove beacons that have just become close enough

(35)

4.1. Project Organisation

Figure 4.4: Observer pattern using the nearby stands list as an example

Figure 4.5: Delegate pattern as used for the AppDelegate

to be detected or far enough to no longer be detected. Here, the controller that is associated with the nearby stands view, observes the beacon manager for updates in the beacon list, as shown in figure 4.4. As soon as the list gets updated, the controller gets a notification, retrieves the new list of beacons and updates the view accordingly.

Delegate

Another widespread design pattern commonly used within the iOS platform is the delegate pattern. This pattern is a very fundamental pattern and is used in other, more complex patterns. The main idea is that an object, that needs to handle different requests, can hold another object, the so-called delegate, and simply forward certain requests to the delegate. This way, an object can dynamically customised at runtime, by simply providing an appropriate delegate object. Instead of using inheritance to achieve a similar result, this solution described by this simple pattern is more flexible and avoids large and unnecessary complex class hierarchies.

The most obvious use case within an iOS application is the starting point of every such an application, namely the AppDelegate. Figure 4.5 shows the

(36)

Chapter 4. Design

Figure 4.6: The beacon manager as a singleton class

use of the delegate pattern with the app delegate as example. This is the object that gets forwarded requests from the main application object, like, for example, when the application finished loading and is ready to start its normal execution. In order to perform initialising tasks at the start of the application, the tasks can be placed within the delegate method that is called by the application object.

Singleton

A singleton is a class that only gets instantiated once, so that there is only one object of this class within the running application. Though this could be achieved by passing around the reference to this object to every other object that needs to interact with the singleton, the singleton design pattern has a more elegant solution for this problem. The singleton class provides a static access method that either creates a new instance, if there is no other instance so far, or returns the reference to the existing reference. This makes it easy to access the singleton object within any other object without having to pass the reference around.

This pattern can be found at several places within the iOS platform. One example is the main application object mentioned in the delegate section.

Since there is only one such an application object per application, it makes sense to use the singleton pattern here. Furthermore, the application object provides some important functions needed by different parts of the application, like the notification feature that displays a notification to the user. Another example is the notification centre introduced in the observer section. Again, the notification centre only exists once per application and is needed by every object that needs to post a notification to observers.

Within the ExpoMate project, there is another example that makes use of the singleton pattern, as depicted in figure 4.6. The beacon manager, that holds the list of beacons and also provides methods to enable and disable the ranging feature, is a singleton itself, so that objects that need to interact with the beacon manager can easily access the instance. Furthermore, there should be only one beacon manager, otherwise incoming events triggered by the beacons would be handled multiple times.

References

Related documents

The new campanies are: Nordea Bank Finland Pk, owner of all assets and liabilities related to the bankingbusiness in the demerged Nordea Bank Finland Pk, Nordea

Both Brazil and Sweden have made bilateral cooperation in areas of technology and innovation a top priority. It has been formalized in a series of agreements and made explicit

Swedenergy would like to underline the need of technology neutral methods for calculating the amount of renewable energy used for cooling and district cooling and to achieve an

You suspect that the icosaeder is not fair - not uniform probability for the different outcomes in a roll - and therefore want to investigate the probability p of having 9 come up in

8 The liti- gation that is the subject of this study, though, involves Shell s decade-long program to drill new exploratory wells in recently leased areas on the “laskan

improvisers/ jazz musicians- Jan-Gunnar Hoff and Audun Kleive and myself- together with world-leading recording engineer and recording innovator Morten Lindberg of 2l, set out to

Besides this we present critical reviews of doctoral works in the arts from the University College of Film, Radio, Television and Theatre (Dramatiska Institutet) in

The largest informal area within our project area is located south of Khulti Street/Mblini Street (see page 41) on land used as storm water detention ponds and the area floods