rSystem: A Location-based Event Servicewith Proactive Notification

Ngo Minh Quan

Faculty of Environment and Information Studies

Keio University5322 Endo Fujisawa Kanagawa 252-8520 JAPAN

Submitted in partial fulfillment of the requirementsfor the degree of Bachelor

Advisors:Professor Tatsuya Hagino

Associate Professor Takashi Hattori

Copyright©2010 Ngo Minh Quan

Abstract of Bachelor’s Thesis

rSystem: A Location-based Event Servicewith Proactive Notification

Development of mobile technology has enabled the possibility of Location-based concept

in social networking as many Location-based Social Network Service (LBSNS) have been

deployed recently and achieved considerable popularity among users. However, users in fact

expect from Location-based Service (LBS) more than just the reactiveness that requires their

attention and interaction inconveniently. Therefore, it is understandable that future LBS

highly require the capability of proactiveness.

In this thesis we introduce rSystem, a LBS focusing on the concept of social event. In

order to provide proactiveness, rSystem is built with a proactive notification which has the

ability of locating user’s position to inform him about event information. Our user study

revealed that rSystem along with its proactive feature was appreciated by users because of

their usefulness as well as accuracy. This thesis also describes our approach on the problem

of user’s privacy which is a controversial issue of location-aware service generally.

Ngo Minh QuanFaculty of Environment and Information Studies, Keio University

i

卒論文要旨２０１０年度（平成２２年度）

rSystem: プロアクティブ通知を用いた

位置ベースのイベントサービス

モバイル技術の発展によりソーシャルネットワークサービスに位置ベースというコンセプトが

可能になった。最近いろいろな位置ベースのソーシャルネットワークサービス(LBSNS)が公開さ

れ、人気を得てきた。しかし、ユーザの集中と動作を必要とする不便なリアクティブサービスよ

り、将来のLBSはプロアクティブの方を期待されている。

本論文はrSystemを提案する。本システムは位置ベースのソーシャルイベントに基づき、プ

ロアクティブ通知サービスを提供する。具体的には、ユーザの現在地を測定し、そこでのイベ

ントを自動的にプッシュする機能である。このプロアクティブ通知サービスの有用性と正確さの

おかげでrSystemはユーザに高い評価を受けた。最後に、一般の位置アウェアサービスと同じく

rSystemを展開するときにもユーザのプライバシーが問題になっているから、本論文でその対策

を説明する

慶應義塾大学 環境情報学部

ゴー　ミン　クアン

ii

Contents

1 Introduction 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Structure of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background: The Prospect of Location-based in SNS 3

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Current Trends and Future Possibilities of SNS . . . . . . . . . . . . . . . . 3

2.3 Location-based, An Emerging Trend in Social Networking . . . . . . . . . . 5

2.3.1 Definition and Classfication of LBS . . . . . . . . . . . . . . . . . . . 5

2.3.2 Emergence of LBS in Social Networking . . . . . . . . . . . . . . . . 6

2.3.3 Geosocial Networking . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Problem, Motivation and Related Works 9

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Current Problems of LBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Essential Work for the Next Generation of LBS . . . . . . . . . . . . 9

3.2.2 The Need of New User Experience beyond the Check-in . . . . . . . 10

3.2.3 User’s Concern for Privacy . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.4 Motivation on Introducing a Proactive Event Service . . . . . . . . . 12

3.3 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

iii

4 rSystem, A Location-based Event Service with Proactive Notification 15

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 rSystem, A Location-based Event Service with Proactive Notification . . . . 15

4.3 Conceptual Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3.1 rEvent, A Location-based Event . . . . . . . . . . . . . . . . . . . . . 16

4.3.2 rNotify, A Proactive Location-based Notification . . . . . . . . . . . 18

4.4 Technical Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4.1 Implementation on Micro Blogging Twitter . . . . . . . . . . . . . . 19

4.4.2 Positioning Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.3 Map-based Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4.4 Privacy and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5 Possible Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Design and Implementation of rSystem 27

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Data Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4 Implementation of rServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4.1 Worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.4.2 Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.4.3 Twitter Streamer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.4.4 Server Functional Module . . . . . . . . . . . . . . . . . . . . . . . . 33

5.5 Implementation of rClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.5.1 Client Functional Module . . . . . . . . . . . . . . . . . . . . . . . . 35

5.5.2 Mapping Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.5.3 Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.5.4 rNotify Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

iv

5.6 Request/Response between rServer and rClient . . . . . . . . . . . . . . . . 41

5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Evaluation of rSystem 43

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Quantitative Evaluation of Positioning method . . . . . . . . . . . . . . . . 43

6.2.1 Method and Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.2 Result and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3 Qualitative Evaluation of rSystem . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3.1 Method and Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3.2 Result and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7 Conclusion and Future Work 51

A Appendix 57

v

List of Tables

2.1 Comparison between Reactive and Proactive Service . . . . . . . . . . . . . 6

4.1 Comparison among GPS, Network and Dead Reckoning . . . . . . . . . . . . 22

5.1 Specification of Server’s Implementation . . . . . . . . . . . . . . . . . . . . 30

6.1 Detailed Specification of Device used for Evaluating . . . . . . . . . . . . . . 44

6.2 Result of Positioning Method Evaluation in Open Area . . . . . . . . . . . . 46

6.3 Result of Positioning Method Evaluation in Urban Area . . . . . . . . . . . 47

6.4 Result of rEvent Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.5 Result of rNotify Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vi

List of Figures

2.1 The Evolution of Location-based Services . . . . . . . . . . . . . . . . . . . . 7

4.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 rEvent Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 rNotify Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 Combination of 3 Positioning Methods . . . . . . . . . . . . . . . . . . . . . 23

4.5 Map service on many platforms . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 System Design using Sever-Client model . . . . . . . . . . . . . . . . . . . . 28

5.2 Data Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.3 rServer Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.4 Master-Worker Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.5 rClient Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.6 Technique of Mapping items on Android Map Service . . . . . . . . . . . . . 36

5.7 Displaying Items on rClient . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.8 Input location by touch interaction . . . . . . . . . . . . . . . . . . . . . . . 38

5.9 rNotify Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Samsung Galaxy S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 User’s Concern for Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

vii

Chapter 1

Introduction

1.1 Introduction

Since the introduction of Web 2.0, Social Network Service (SNS) has become one of the most

used online service on the Internet. In the past few years, many advances in both content

and technology of SNS have been seen, especially the development of mobile technology

which has set the trend for current Web-based SNS such as Facebook, Myspace and Twitter

to turn into mobile. Moreover, it is this development of mobile technology that did not only

resurrect Location-based Service (LBS) but also allowed it to spread into social network-

ing to create the pattern of Location-based Social Networking Service (LBSNS), in which

geographical location is utilized in order to provide location-related social service. Along

with real-time concept, location-based concept is currently the setting trend for the future

of social networking.

However, as well as LBS in general, LBSNS is also facing identical problem which is

the lack of proactiveness. Especially when current trend “Social Check-in” will no longer

attract user’s interest, next generation of service that offers new user experience is highly

expected. Therefore, in this thesis we propose rSystem, a LBS that focuses on social event

and offers a proactive notification which bases on location of a user to proactively inform him

with nearby event. Because LBSNS often involves location-tracking, there are also several

challenges that come up during development of rSystem, which are positioning method and

user’s concern for privacy that need to be considered. And finally, as well as developing any

1

service user’s satisfaction is also a great challenge of our system. This thesis also emphasizes

on our approach and solution toward those problems and challenges.

1.2 Structure of Thesis

The thesis is organized as follows. Chapter 2 describes the background of LBSNS in social

networking, followed by Problems, Motivaton and Related Works discussed in Chapter 3. In

Chapter 4, we introduce our approach by proposing rSystem, a location-based social event

service with proactive notification. Details on Design and Implementation of rSystem will

then be discussed in the Chapter 5, while Evaluation of the system will be presented in the

next chapter. Finally, we conclude with Conclusion and Future Work in Chapter 7.

2

Chapter 2

Background: The Prospect ofLocation-based in SNS

2.1 Introduction

This chapter describes the overlook of location-based concept in social networking. In the

first section, the background of SNS and its future possibilities are introduced. The next

section discusses about LBSNS and its emergence in social networking, as well as geosocial

networking which is currently the mainstream of LBSNS at the moment.

2.2 Current Trends and Future Possibilities of SNS

SNS is an online service on the Internet, platform, or website that focuses on building

and reflecting of social networks or social relations among people who share interests and

activities on the Internet.

Born in the early 1990s with such services as chat rooms and bulletin board services,

however not until the introduction of Web 2.0 in the late of the decade have social networking

and social network technologies developed rapidly and become one of the most courses for

Internet usage these days [18].

Most SNSs are web-based which are called social network sites. There are hundreds and

counting sites in all over the world, some of which are being widely used such as Facebook,

3

Twitter, Friendster, Myspace (North America), Mixi (Japan) and Cyword (Korea) with

approximately 800 million registered user currently [1, 14, 24, 25].

Twitter, one of the most well-known social network sites that we mentioned above, is

a good example of a successful service, which offers a social networking and microblogging

service, enabling its users to send and read other users’ messages called tweets . Tweets are

text-based posts of up to 140 characters displayed on the user’s profile page [13]. Twitter

set the trend for ”real time” services, where users can broadcast to the world what they are

doing, or what is on their minds within 140 character limit. It is its simplicity that makes

Twitter popular, especially among “always-connected” generation, who use handheld devices

to organize their lives and coordinate social interactions, because Twitter enables them to

update as well as stay updated with the latest information in such short and simple tweets.

Recently with development of mobile Internet, an explosively increasing number of users

are performing their daily Internet activities such as surfing web, reading news, checking

mail as well as social networking via their handheld. Researchers have shown that mobile

Internet is expected to take over by 2015 [5].Therefore, it is highly possible that future trend

for SNS will be a significant movement to mobile device.

Development of mobile devices with such technologies as satellite positioning and cel-

lular positioning, have as well made mobile tracking possible within an affordable cost. It

is this essential improvement of location service that enabled LBS, a new trend of social

network service which utilizes location information. Along with real-time-based, the concept

of location-based is currently and will continue to be the key terms for the development of

social networking in the future.

4

2.3 Location-based, An Emerging Trend in Social Net-working

2.3.1 Definition and Classfication of LBS

LBS, which is also known as location-aware service or location-related service, is defined

by the GSM Association as services that use the location of the target for adding value to

the service, where the target is the “entity” to be located (and this entity is not necessarily

also the user of the service) [15]. For example, those values can be provided by filtering

information such as showing nearby place of interests, displaying the location of a target

on map, or automatically activating the service when target enters or leaves a predefined

location.

Based on their characteristic and interaction, LBS can be classified into reactive and

proactive service. The former is a service that is always explicitly activated by the user. The

interaction between LBS and user can be described as following routine.

1. User invokes the service and establishes a service session.

2. User requests for certain functions and information.

3. Service gathers location data, processes it and responses to user.

Proactive service, on the other hand is not explicitly requested by the user but automat-

ically initialized as soon as a predefined location event occurs, for example when the user

approaches, or leaves a certain specified target which can be a location or other users. The

interaction between service and user happens asynchronously.

1. Location event occurs.

2. Service self initializes.

Therefore, in contrast to reactive ones where the user is only located once, proactive LBS

requires to permanently track him in order to detect location events.

5

Reactive ProactiveInitializing Requested by User Self-initializedCondition User invokes Predefined event occursInteraction Synchronous AsynchronousLocation tracking Once Permanently

Table 2.1: Comparison between Reactive and Proactive Service

2.3.2 Emergence of LBS in Social Networking

First generation of LBS was in fact developed in the late 1990s, which provided finder services

that delivered to user a list of nearby points of interests like restaurants, gas stations or

ATMs. However, those kinds of service did not succeed in attracting users’ interest and were

quickly turned down. Fortunately, in the past few year, LBS has been resurrected thank

to several significant developments and conditions. It was about 2005 when GPS-capable

mobile devices widely emerged and Web 2.0 model as well as 3G broadband wireless services

was introduced that contributed to this resurrection.

Firstly, assisted GPS allowed low-power positioning, which is an essential factor of a

LBS. Secondly, Web 2.0 enabled location itself to become one of context items that can

be exchanged among a social network. And finally, 3G service has freed mobile devices

from fixed Internet connection, thus allowing users to access service even when they are

on-the-move, which is also a requirement for a LBS.

As we can see in Fig. 2.1, it is now 2010 that Google maps services has been available for

many platforms and the new generation of smartphone such as Apple iPhone and Android

has become very popular. These conditions have provided a rich development environment

for application developer, thus also contributed to the evolution of LBS in the future. In the

past few years, LBS has also spread into SNS, making the concept of LBSNS which is the

combination of location-based concept and social concept. As more and more development

would be achieved in the next few years, location-based is expected to be a promising trend

for future SNS [28].

6

Figure 2.1: The Evolution of Location-based Services as described in LBS: Back to theFuture [4]

2.3.3 Geosocial Networking

Geosocial networking is a type of social networking in which geographic services and capabil-

ities such as geocoding and geotagging are used to enable additional social dynamics [19,20].

The most basic geosocial service allows user to add geotagging information into their

message, for example “Tweet with location” function currently provided by Twitter. The

location information that is shared publicly with Tweet can be either exact location of user

or a general area like a neighborhood or town [12, 26].

Many SNS, such as Foursquare, Facebook and Gowalla provide social check-in service

which allows users to ”check-in” to a physical place and share their location with their

friends [21]. Users can check-in to a specific location which is determined by their current

location using GPS or selected from list of nearby places. Once checked-in, they have the

option of sharing their location with friends in services such as Twitter or Facebook, thus

makes the social aspect of this service and the name “social check-in”.

Report shows that 4% of online Americans use service such as Foursquare and Gowalla

and on any given day, 1% of Internet users are using these services [30]. Data that was

7

collected in our system, which we would mention in later chapter, also revealed that more

than 31% of tweets containing geotagging in Japan in 24 hours came from users using

Foursquare which was 8634 over 27649 tweets. This fact proves that social check-in has been

significantly popular among users and is believed to be one of the most successful LBSNSs

so far.

2.4 Summary

In this chapter, we have mentioned about the background of SNS and its two concepts of

real-time and location-based. With the rise of mobile internet and the increasing use of

mobile devices and development in mobile technology, that location-based is expected to be

the ideal tendency for social networking as more and more LBSNSs would be available in

the near future.

8

Chapter 3

Problem, Motivation and RelatedWorks

3.1 Introduction

This chapter discusses the problems in developing LBS at the present. They are the lack of

proactive service, the need of new user experience and user’s concern for privacy when using

LBS. Understanding these issues, we would like to introduce our motivation in this project

and related works on the problem.

3.2 Current Problems of LBS3.2.1 Essential Work for the Next Generation of LBS

On March 2008 the Mobile Location-Based Service Summit hold a panel on the topic “What

was wrong with First-Generation Location-based Service”, which has pointed out the prob-

lems of the early LBSs was that that they were reactive, self-referencing, single-target and

content-oriented. The panel also identified that four major changes required to provide a

satisfaction of LBSs [4].

• In particular, current reactive type of services should be replaced by proactive ones,

which demand less user attention and interaction.

9

• Secondly, cross-referencing is necessary because it’s important to distinguish between

user and location-based target, where the former is the person who requests service

while the latter can be anything whose location is requested to be processed by the

service. This means that the objective of LBS should not emphasis only on the location

of a user is but also the location of what he requested.

• The third evolvement should be made is the ability to detect multiple targets in one

service session.

• And finally, a movement from content-oriented to application-oriented is expected,

which in short enables application’s content to be dynamically changed based on user’s

interest.

Most of current LBSs are still reactive and self-referencing. For example, some services that

we have mentioned in previous chapter only offer check-in services, where users use can

check-in into predefined places around their positions. Whereas not many service has the

capability of proactiveness. Therefore we conclude that more effort on developing proactive

service is highly required at the moment.

3.2.2 The Need of New User Experience beyond the Check-in

As we have mentioned in Chapter 2, one of the most popular trends in current LBS is social

check-in service such as Facebook Place, Foursquare and Gowalla. However many opinions

from the social media believe that check-in will never appeal to the mainstream. They

stated that check-in is viewed by non-adopters as a trivial game, gratuitous to both the

unique experiences and daily drudge of the places we visit. However, the relentless chore of

updating one’s location has even spawned a new phrase “Check-in fatigue”. And the reason

why many service providers still make it the central of user experience is that “perhaps these

companies think it’s too late to rethink the basics, or they’re afraid of veering away from

what has given them a small trending foothold” [8].

10

Indeed, with these services users are able to share their location information with others.

However there is not much service that is able to provide users with useful adding values

on the given location such as places of interest, local events, traffic information or weather

information. Therefore, the need of new user experience should also be considered when

developing a new LBSNS in the future.

3.2.3 User’s Concern for Privacy

Because LBS is a context-aware service involving tracking people’s location which is classified

as high-sensitive information, it is the fact that users highly concern about their location

privacy. They often concern for the risk that their personal information and data collected

and processed during service usage may be misused by unauthorized parties or by the service

provider itself, and yet LBS spam is another problem to worry. We have also conducted an

survey on this problem and found out that 100% of the participants worry about the exposure

of location data and the threat of being tracked by other people.

However, many researches on this problem have been conducted so far, and they conclude

that despite these risks of privacy exposing, users approve of disclosing their location to 77%

of the time requested when it’s appropriate and useful for the requester. Furthermore, being

provided with adequate information on what and how their data is measured, stored, used

and the usefulness of LBSs, users find them less threatening and more acceptable [2, 6].

A study on users’ privacy concerns shows that, they concern more on location-tracking,

in which user’s location is tracked by other parties, than in location-aware service where

the device itself has knowledge of its current location although both service are evaluated

equally in usefulness [3].

In conclusion, it is essential for developers to balance between the benefit their service

offers and user’s privacy when designing, as well as have knowledge of what technology and

method are acceptable for user when implementing a LBS.

11

3.2.4 Motivation on Introducing a Proactive Event Service

As the current check-in services are fading and will no longer stay in the mainstream, besides

there is now a lack of proactive services that are able to provide user with useful information

about location in advance without demanding user’s attention and interaction, therefore in

this thesis we propose a design and implementation of a simple proactive service focusing on

location-based event, which allows a user to create, invite or look for events around him as

well as proactively informs him about incoming or nearby event with a built-in notification

service.

3.3 Related Works

The idea of using location as an element of context-aware to provide proactive notification

is not new as much work has been done to deploy such service in the past few years. Shar-

ing the similarity in objective of informing user with events, some projects utilize location

information to provide self-reminder type of LBS, in which user is automatically remind of

a task when he approaches or leaves the location of this task.

Developed in 2000, ComMotion [16] is one of the pioneers in providing a location-aware

reminder service. Using GPS technology for location-sensing, users can set reminders around

predefined location, with given time constraints. When a user was near that location and

the timing constraints are both satisfied, he would be alerted with an audio alert.

Another recent work was Place-Its [23] which provides location-based reminders on Sym-

bian OS mobile using cellular positioning. This application is designed to reproduce the

post-it note usage, and named for its ability to place a reminder message at a physical loca-

tion. The trigger for reminder is signaled upon arrival or departure of the associated place,

displaying a text message about the task.

Unlike the previously mentioned systems, ActiveCampus [9] restricts to a university cam-

pus setting and provides a location-based reminders system. This system uses 802.11 wireless

radios set up within the area for location sensing. Student can set reminders to be triggered

12

at predefined locations on campus such as buildings or classrooms.

These pioneering efforts mentioned above, although used different positioning method,

were generally restricted by the limitation of technology at the time. Relying on wireless

radios to positioning, ActiveCampus was restricted to a small area of university campus and

required a network of beacons to be set up in the environment, which was not feasible in

both cost and deployment. Place-Its utilized GSM-based cellular positioning in mobile phone

with the advantage of low-cost and popularity of the device, however obtained relatively

low accuracy. On the other hand, in spite of a weakness in operating indoor and non-

covered areas, GPS positioning appears to be the most accurate method [7]. Nevertheless,

before GPS-capable devices became popular and affordable, previous work like ComMotion

required portable PC and additional GPS receiver, which took both cost and inconvenience

into account.

Despite having such restriction on technology, those efforts have obtained considerably

satisfactory results. They revealed that mobile devices were the ideal environment to develop

LBS because of their low-cost and high usability. Furthermore ComMotion, which was able to

provide GUI and speech input, determined that a visualized display is essential. Researchers

on this project also realized the importance of sharing information among community, which

would produce the social aspect of LBS.

Finally, the most significant conclusion they have found out is that location-based re-

minder service was highly accepted by users. In spite of having low accuracy, most par-

ticipants of Place-Its found it useful. Other researches on evaluating the effect of memory

aids used to help recall also stated that displaying uncertainty was effective to improve recall

rates [22]. For this reason, such location-based notification is expected to be helpful for users

in their daily activities.

There are several projects that also focus on location-based event concept, for example

GeoLife2.0 [29], however has different approach, instead of providing proactive reminder like

above works, it offers recommendations that match user’s interest. GeoLife was a GPS-

data-driven social networking service where people can share life experiences and connect to

13

each other with their location histories. By mining user’s location history and their friends’

activities , GeoLife is able to predict the individual’s interest in the locations to suggest

recommendation about places of interest.

The importance of proactive service is also agreed by some previous research. For exam-

ple, Location Based Community Services [10] is a service emphasizing on friend finder and

sharing notes among users. On their work, they found out the requirement of proactiveness

and Push-based interaction as well as determined privacy as serious issue to consider.

3.4 Summary

With recent advancement of technology, we are now able to break through the restrictions

that previous works were limited. For this reason, we would like to introduce our proposal

on solving the problem in the next chapters by introducing rSystem, a location-based event

service with proactive notification.

14

Chapter 4

rSystem, A Location-based EventService with Proactive Notification

4.1 Introduction

This chapter contains our approach on the problems stated in the previous chapter by propos-

ing rSystem, a location-based event service with proactive notification. Starting with system

overview, this chapter emphasizes on rSystem and the conceptual approaches and technical

approaches that is applied in the system. Finally, we describe some scenarios where rSystem

might prove to be useful in real life.

4.2 rSystem, A Location-based Event Servicewith Proactive Notification

As pointed out in Chapter 3, mobile devices are the ideal platform to develop LBSNS.

Therefore, we propose rSystem which focuses on providing a LBS for mobile device, where

users basically are able to create, invite or manage as well as take part in events called rEvent.

A proactive notification service which is implemented in the client application deployed in

mobile devices, automatically informs user with incoming event or nearby event based on

his current location.

rSystem operates under Server-Client model (see Fig. 4.1), where server stores and pro-

15

Figure 4.1: System Overview

cesses data of users and events while a mobile application works as a client to track location,

handle user interaction and provide notification service. Server-Client model is considered

to help reduce client’s workload, which suits our implementation on mobile devices.

4.3 Conceptual Approaches

In this section, we describe the concept of rEvent which is a location-based event and rNotify

which is the proactive notification service.

4.3.1 rEvent, A Location-based Event

rEvent as mentioned above is a location-based event is the main target of our LBS. In

addition of an event’s basic information, rEvent consists of three elements (see Fig. 4.2).

1. The first element is participant who takes part in the event. This information distin-

guishes two types of event: private and public event. A private event is used by one

individual or a group of users, where only users of this event are able to view, while on

the contrary public event is available for everyone to search and join. Using the data

16

Figure 4.2: rEvent Overview

of users taking part in an event, it is also possible to count the number of participants,

which would give a user additional data when he is looking for interesting events.

2. The factor of time, which expresses the period of time when the event occurs, is

bounded by start time and end time value. An event is considered to be ongoing if

current time is in this event’s occurring period.

3. The location-based characteristic of rEvent is achieved because of the fact that location

element plays the most important role in an event’s data. Location information is

described by geo location which is constructed from a pair of latitude and longitude

value. Based on these values, distance between two points can be calculated by using

Haversine formula as below.

haversin(

dR

)= haversin (φ2 − φ1) + cosφ1 cosφ2haversin∆λ

given that

• haversin (φ) = sin2(φ2

)• d is the distance between the two points

• R is the radius of the sphere, which is 6 378.1 km in case of the Earth

17

• φ1 is the latitude of point 1

• φ2 is the latitude of point 2

• ∆λ is the longitude separation

from which distance can be calculated by

d = 2R arcsin(√

h)where h = haversin

(dR

)An event is considered as nearby event when the distance from this event to user’s

current location is within a range predefined by user. Based on events’ location in-

formation, users are able to search for nearby events or events in a specified area.

Moreover, these events can be displayed on map for visualization.

rEvents are basically created by users, by function implemented in the client or by sending

tweets containing “#rmemo” hashtag to Twitter using any application or from Twitter’s

website, where this messages will be collected and processed at the server under a simple

Natural Language Processing module. A user is able is use rEvent as private reminder, in

which he will be notified about the event when the time constraint or location constraint

satisfies. It is also possible to invite others to an event by create the event with their

usernames on the participant list. This scenario is considered helpful when rEvent is used

as group reminder, where all members will be informed about this event and notified when

it happens or they approach near the place. When it comes to public event, it can be used

with the purpose of event promotion or advertisement because it will be open to public, thus

help other users to have knowledge about the event.

4.3.2 rNotify, A Proactive Location-based Notification

With the purpose of producing proactive characteristic for rSystem, we propose rNotify as

a solution. rNotify is a proactive notification service, which based on user’s current location

automatically informs user with incoming events and nearby events without requiring user’s

operation. In order to do that, it is essential for this service to operate individually with the

18

main program as well as keep track of user’s location. Therefore we propose such approach

to work on this problem.

Figure 4.3: rNotify Overview

rNotify consists of two modules, shown in Fig. 4.3. The first module constantly requests

for location information of user from the device’s positioning service. The other stays up-

dated with database of events by continuously sending request and processing response. If an

event matches any condition of ongoing or nearby event, rNotify will attract user’s attention

by sending notification such as playing sound or vibrating.

4.4 Technical Approaches

This section describes two technical approach that is applied in rSystem. They are the

implementation on Twitter, positioning method and our approach to privacy and security

problem.

4.4.1 Implementation on Micro Blogging Twitter

This subsection discuss on the reason of our implementation of rSystem on SNS, particularly

Twitter. As we have briefly mentioned in the background, Twitter is a popular microblogging

19

service well-known for its simplicity and trendy. According to Compete.com, Twitter is

ranked as the third most used social network service in all over the world with 175 million

registered users, and 95 million tweets per day [11, 14].

In Japan, Twitter also witnessed an impressive rise as it has grown by 400% in 2010

to reach 13.2 million users, in comparison with 13.5 million of Mixi.jp - the largest SNS so

far [17].

Twitter is also considered the most open of all social networks by providing an API which

allows outside developers access user’s status updates. The Twitter API basically consists of

two REST APIs and a Streaming API. The formers enable developers to access core Twitter

data within a rate limitation while the latter provide near real-time high-volume access to

Twitter’s status stream.

There are three advantages of implementing our system on Twitter. Firstly, Twitter

has numerous users, many of who are “tweeting” via applications on their mobile devices.

Implementing rSystem into a Twitter application allows users to try the service without the

inconvenience of moving to a new SNS, thus make it more acceptable.

On the other hand, Twitter API is an ideal tool for developing services, including geo

methods for developing location-related services. This allows developers to build applications

on top of Twitter infrastructure and come up with many ideas which are even better than the

Twitter’s original basic function. Furthermore, Twitter API has a large number of libraries

which are available for almost every programming language. In this case of rSystem, we used

Twitter4J [27] developed by Yusuke Yamamoto, which is an open-sourced, mavenized and

Google App Engine safe Java library for the Twitter API, released under the BSD license.

Finally, by implementing on Twitter rSystem has the capability to send update about

event to Twitter as tweet, such as when a user creates an event or joins an event. And on

the contrary it is also possible to get event updates from Twitter stream, for example getting

new events update posted as tweet by Twitter user. This enables the sharing of information

between rSystem’s users and users who do not use the system, as well as produces the social

aspect of rSystem.

20

Moreover with the ability to access Twitter data, rSystem offers nearby tweet and nearby

friend function, the former of which displays tweets that is sent around a specific place

while the latter displays friends of a user who is currently nearby. Its allows users to have

knowledge about people and events happening around them, which contributes to help them

with decision in creating or joining event as well as inviting friends to an event.

4.4.2 Positioning Method

Location-sensing is considered as one of the key techniques in a LBS. There exist several

methods of positioning which we have mentioned in the last chapter. By choosing mobile

device as the environment for deploying service, generally we are able to take advantage

of GPS provider and Network provider for location-sensing. In this thesis, we propose a

combination of three methods of obtaining location information.

1. The first is Dead Reckoning, which estimates current position by previous determined

position. It is apparently low on accuracy but can be obtained immediately.

2. The second is Network based positioning, which determines location based on avail-

ability of cell tower and WiFi access points. This method allows result to be obtained

shortly but fairly accurate.

3. The third is GPS based positioning, which determines location using satellites. In this

method it is required to receive signals from at least four satellites, three of which is used

to calculate distance to each satellite and the fourth is used for time synchronization.

GPS positioning provide high accurate result in the cost of slow response and power-

consuming. Because of the requirement of at least four satellites in sight, it is difficult to

work when surrounded by obstacle such as high buildings or trees and merely impossible

to work indoor. However, nowadays some mobile devices are equipped with modern

receivers which can receive GPS signal with sufficient strength inside building and

many Indoor GPS methods are being developed, GPS positioning is still considered

the most valuable source to detect user’s location.

21

Dead Reckoning Network Posi-tioning

GPS Positioning

Method Estimating on lastknown location

Cellular & WiFibased sensing

Satellite sensing

Respond time Immediately Fast SlowAccuracy Very low Medium HighPower-consumption

None High Very high

Table 4.1: Comparison among GPS, Network and Dead Reckoning

Because each method has its advantage and disadvantage, the balance between accuracy,

speed and battery-efficiency requires a lot of consideration. On this specific case of rSystem,

we implemented a positioning module which maintains the best estimate while keep the

consumption of power minimum and response time acceptable.

In order to maintain the best estimate of location, new location acquired by any method is

compared to the current best considered location by considering the time of acquiring, source

and accuracy. If the new location does not satisfy these conditions, it will be dismissed.

Based on the characteristic of each method, we applied following policy to balance be-

tween accuracy and battery-efficiency as shown in Fig. 4.4.

• Because Dead Reckoning is considered to be the worst estimate, therefore even when

the location is determined by last known data other location-sensing processes will

continue to work for a specified period before self-stopping.

• Secondly, Cellular and WiFi access point based is believed to be not as precise as

GPS however it can provide quick response. For this reason, after new location is

obtained, Network positioning process is stopped while GPS will continue to work for

a predefined period before self-stopping.

• GPS is considered to be the most accurate source. Therefore after data from this

source is obtained all location-sensing processes including GPS positioning itself will

be stopped.

22

Figure 4.4: Combination of 3 Positioning Methods: GPS, Network and Dead Reckoning

When it comes to proactive notification service, keeping track of user’s location is necessary.

However, because the requirement of power-conserving should also be considered seriously,

we placed a limitation of minimum time interval between requests from rNotify to device’s

positioning service. In other words, rNotify keeps track of user’s location by continuously

send request to device’s location service but only after restricted time could it request for

the next update of location data.

4.4.3 Map-based Interaction

It is the fact that a location-based data which is usually described as pair of co-ordinates in

the system is readable for machine but on the contrary rather difficult for users to compre-

hend. Therefore a visualization of these data is highly required, and in case of places and

location, the best method is to visualize them on a map.

Moreover, nowadays map service is available in many platforms as seen in Fig. 4.5,

for example Google Maps on Android and iPhone, Ovi Map on Nokia handheld and Bing

Maps for Windows Phone based mobile devices, so that the idea of providing a map-based

23

interaction is deployable.

In rSystem, we introduce a map-based interaction, in which the output data is mainly

displayed on map such as Tweets or events. On the other hand, input location data can

also be inserted by directly selecting from items on the map. With map-based interaction,

rSystem is exptected to bring up new user experience. The implementation of map-based

interaction will be discussed in detail in next chapter.

(a) Google Maps onAndroid

(b) Google Maps oniPhone

(c) Ovi Maps onNokia

(d) Bing Maps onBlackBerry

Figure 4.5: Map service on many platforms

4.4.4 Privacy and Security

As indicated in Chapter 3, user’s concern for privacy is an important problem that developers

should consider carefully when developing a LBS especially if involving user-tracking service.

However, since the target of service is event, of which location is essential for the rSystem

while user is the one who requests for the target, whose location is not necessary to be

tracked by the system, we propose following policies to work on this issue.

Firstly, user’s location data is not stored in the database but is self-monitored by the

mobile device. In searching functions, a request containing current position of user is sent to

server, then based on this information server will process and response with matched data

24

without saving it inside the system. In notification function where tracking of user’s location

is employed, request is sent from client without any location data. After receiving reply from

server, the client itself checks for matching conditions between location of events and current

position. This method is known as location-aware which the device itself has the knowledge

about its current location, and by self-monitoring it notifies user where he approaches to an

event.

Secondly, although user’s location is not recorded, his trace is still stored in some cases,

for example by creating, joining an event, sending tweet. The first measure is simply allowing

him to decide whether to send his location data such as tweet without location or create

event with “null” location. On the other hand, if he approves to send his location, a measure

to protect this data is required. rSystem applied a protection that a user is not able to see

who participate in the event except for the total number of attendants. Finally, in order to

avoid the threat of exposure of transmission between server and client, request and response

are encrypted as a security enhancement implemented in rSystem.

4.5 Possible Scenarios

In order to clarify the operation of rSystem, we introduce following possible scenarios where

rSystem might prove to be the most useful.

Ken is a student, who is going to school by train everyday in the morning. One day,

when he is waiting on the platform at the station for the train to school, he uses rSystem

to check out nearby tweet to get information about what is happening around. He notices

that a tweet sent by a twitter bot of a mall nearby tells that this mall is holding a special

sale today including something he wants to buy. He sets a private event at the location of

the mall to remind him about going shopping when he comes back from school. And in

the afternoon on his way home, he is passing by the mall when he receives a message from

rSystem reminding him that he is approaching a event named ”shopping at X mall”. He

recalls of this task and does his shopping immediately.

25

Ken, Tom and Yuri is students of a workgroup. They have group meeting everyweek but

the location and time is usually not fixed. Ken uses rSystem to set up a meeting by creating

an event for group and adding his friends username into the participant list. Finally, he sets

up the time and location for the meeting. Tom and Yuri who are also using rSystem on

their mobiles, immediately receive notification about the event ”meeting” by Ken. By using

rSystem, they are able to see the location where the meeting will take place. When it’s time

for the meeting, their mobiles ring and remind them to go. They immediately leave for the

place.

Takeshi is a event organizer. One time, he is hired to hold a festival where a lot of people

are expected to join. In order to promote for this event, he decides to send this event to

rSystem as a public event. He does not use rSystem on his phone, however he uses a Twitter

application to send tweet to Twitter with ’#rmemo” hashtag containing information about

the festival. Ken, Tom and Yuri are currently going out nearby, they use rSystem to search

for nearby entertainment event and they notice about Honda’s festival. They think it is

interesting so they decide to participate.

In these scenarios, it is proved that rSystem is considerably helpful in daily life. By using

rSystem application on mobile devices, users can schedule reminder, arrange meeting as well

as publicize event to others.

4.6 Summary

As an approach to the pointed out problem, in this chapter we have introduced rSystem and

its main features and methods including proposing rEvent, a location-based event service and

rNotify, a proactive notification which are the core of the system in the hope of bringing new

user experience. An approach to take full advantage of mobile device’s available location-

services to provide estimation with acceptable accuracy while conserving energy has also

been introduced as well as our solution on privacy problem.

26

Chapter 5

Design and Implementation ofrSystem

5.1 Introduction

This chapter emphasizes on the design and implementation of rSystem that was discussed

in the previous chapter. Starting with the design of system and data model, details of the

system implementation including server and client as well as their modules and functions

will be described in the following sections.

5.2 System Design

rSystem consists of a server and clients implemented in mobile devices as shown in Fig. 5.1.

The server, which is called rServer, is implemented with Database Server, and functional

modules which are responsible for following functions of rServer.

• Manage database by sending queries to Database Server

• Handle request/response with clients

• Access to Twitter’s data.

There are two types of accesses between rServer and Twitter. The first using Stream

API allows server to capture real time status from Twitter’s public stream to filter for events

27

Figure 5.1: System Design using Sever-Client model

which were sent from Twitter’s user via website and other applications. The other utilizes

REST API to provide access to data of Twitter’s user such as updating status, obtaining

time line.

rClient is a mobile application which contains following functions.

• Handle request/response with server

• Provide UI with map and GUI

• Track user’s current location

• Notify user with events

Connection between rServer and rClient is maintained by a sequence of request/response

messages. Therefore the procedure of this operation can be described as follows. Firstly,

initialized by user or self-initialized in case of proactive notification, rClient sends a message

to server requesting for some data. Then, rServer processes this request and reply with a

response containing required data. Based on this data, rClient provides appropriate inter-

action with user, for example displaying events on a map or notifying nearby event with

28

sound.

5.3 Data Model Design

Figure 5.2: Data Model Design

There are two main entities in the data model of rSystem, which are user and event (see

Fig. 5.2). The relation between them describes the data of who takes part in what event.

As mentioned above, by deploying as a Twitter application, rSystem enables users to

access to their Twitter account via the client. Hence, data for Twitter authentication is

required, for example user’s email/username and password. However, in order to avoid the

exposure of sensitive data, we use the OAuth authentication, where instead of username and

password, an access token given by a combination of consumer key, consumer secret, token

key and token secret is used to gain access to a Twitter account. In particular, an application

must at first register itself with Twitter to obtain consumer key and secret while token key

and token secret can be achieved by the permission of this user to allow the application to

read/write to his account.

User data model contains four attributes which are username, password, token and token

secret. Specifically, username is a user’s Twitter screen name while password is his password

used in the system which will be stored in the database as the hash string generated from

the original password. Token and token secret store the data for OAuth authentication as

described above.

29

On the other hand, data model of an event includes title, author, location and time

related information. Location consists of latitude and longitude while time is constructed

from two attributes which are start_time and end_time.

Data is stored in a DBS implemented in server which means that no data will be kept at

clients, allowing the client to be more compact and database-platform-independent as well

as ensuring security better.

5.4 Implementation of rServer

rServer was implemented on Java as a multi-thread socket server, using MySQL server as

Database Server. Both rServer program and its DBS were placed at a high-spec server

machine. Detailed specification is shown as Table 5.1

Implementation SpecificationHardware 2 x Xeon L5520 CPU 6GB MemoryServer Virtual ServerAvailable Resource 2 core 1024MB MemoryOperating System CentOS version 5.5Address enkaku.tom.sfc.keio.ac.jpJava platform OpenJDK Runtime EnviromentDatabase Server MySQL version 5.0.77

Table 5.1: Specification of Server’s Implementation

Java was chosen to develop rSystem because of its following advantages.

• Java is an open source

• Java is platform independent

• Java API is easy to use and comes with helpful documentation.

• Java uses automatic memory allocation and garbage collection which manage memory

automatically

• Java is object-oriented which allows creating modular programs and reusable codes

• Java is considered to be more secure than other languages

30

As described in Fig. 5.3, rServer contains four modules which are Worker, Database

Management, Twitter Streamer and Functional Module. Modules which require access to

Twitter are implemented with Twitter4J, a library for Java [27].

Figure 5.3: rServer Structure

5.4.1 Worker

Worker module is a child thread created by server’s main thread to handle request from

client (see Fig. 5.4). A worker thread is created when server accepts a new connection. It

then read the request sent by the client and analyzes format of the message. Depending on

the type of request Worker calls for the appropriate method of the Functional Module. After

obtaining the result data from this method, it produces response and reply to the client and

finally, ends itself assuming no error is found. Otherwise, Worker will throw exception before

self-terminating.

31

Figure 5.4: Master-Worker Architecture

5.4.2 Database Management

Database Management is implemented with JDBC driver to gain access to MySQL Server.

There are two main functions of this module.

• Firstly, it provides methods which get data from database by sending SQL queries to

DBS and parsing results to other modules, for example method to get events near a

specified location or method to get all events where a user have decided to participate.

• Secondly, it holds methods to manage the data stored in the database such as method

to remove events which are out-of-date. These methods are scheduled to run themselves

periodically.

5.4.3 Twitter Streamer

This module is implemented with Twitter Stream API to read the real-time status from

Twitter’s public stream. It filters the stream for the statuses which contain geotagged tweets

and “rmemo” hashtagged tweet.

For geotagged tweets, they are processed and stored in database as data of nearby tweet

32

function. Currently, the filter is set to collect tweets that came from Japan only by bounding

the latitude and longitude values to a square containing Japan where the northeast corner

is (141.5, 43.1) of Hokkaido and the southwest corner is (129.5, 30.9) of Kagoshima.

On the other hand, “rmemo” hashtagged tweets contain data of rEvent, therefore they

are processed in a higher level of complexity. Firstly the location of event is expected to be

similar to the location of the tweet. The text content of this tweet is decomposed into pieces,

then by using a simple Natural Language Processing module, start time and end time data

is extracted as well as the attendants of the event.

Although this tweet is written in natural language, it is expected to have the following

format

content of event from start_time to end_time @participant1 @participant2 #rmemo

Given that, start_time and end_time describe the two time attributes which can be ex-

pressed in both absolute and relative syntax. Concretely, such absolute syntaxes as “yy/

mm/dd” or “yyyy-mm-dd” are accepted while relative syntaxes like “now” and “tomorrow”

are also recognizable. List of participants can be added using Twitter’s mention @ notation

and the hashtag #rmemo specifies tweet containing data of an event.

5.4.4 Server Functional Module

This module contains functional method of rServer which provide services such as creating

events, joining events, viewing attended events and viewing nearby events as well as Twitter

function like view home time line or update status.

This module is often called by Worker when handling request from client. Generally,

there are four main types of function provided by this module.

• rEvent handler which handles request related to rEvent such as creating new event,

getting events and joining an event. Data is then stored in rServer’s database. Infor-

mation about these activities can also be published to Twitter if the user approves of

publication.

33

• Twitter handler which handles request related to Twitter such as viewing home

time line, updating new status and finding nearby Twitter followers. Data is sent or

obtained from Twitter by using Twitter REST API. In order to provide information

nearby followers of a user, rServer looks for lastest tweets made by friends in his list,

and searchs for tweet containing location data. This location is considered as current

location of this friend if it is recent enough, specifically within 6 hours from current

time.

• Nearby tweet handler which handles request for nearby tweet. Instead of finding

nearby tweet by directly accessing Twitter data, this operation can be done by accessing

database of rServer, where geotagged tweets were stored in advance, thus enabling

response to be instantly obtained.

• Weather handler which handles request for weather information of a specified lo-

cation. Using Google Weather API to obtain an xml containing result from Google,

server will parse it to achieve the weather information for that place.

5.5 Implementation of rClient

Since rClient is designed to operate as an mobile application, there are several platforms to

consider for the implementation of rClient, for example Android, iOS as well as Windows

Phone. Eventually, rClient is decided to deploy in Android platform because of following

advantages.

• Android is open source platform

• Android comes with a helpful software development kit provided by Google

• Android platform supports Google Maps service

• Android supports advanced notification using background process

• The ability of using Java programming language to develop applications on Android

platform

34

rClient consists of four modules which are Client, Mapping, Location service and rNotify

service (see Fig. 5.5).

Figure 5.5: rClient Structure

5.5.1 Client Functional Module

This module is the center of the client, which contains a network sub-module and a functional

module. The network sub-module is used to maintain network connection with server, to

be exact, by sending requests and receiving response. While the functional module contains

the functional methods providing services in the client.

There are currently four types of service offered in the client corresponding to those

deployed at the server side.

• rEvent handler handles methods related to event service such as creating new event,

joining an event, deleting an event or search for nearby event.

• Twitter handler contains methods related to Twitter service, for example viewing

user’s home time line, updating new status, finding nearby friend.

• Nearby Tweet handler provides a fast response for nearby tweet sent around a

35

specific location by looking in the rServer’s database instead of searching directly from

Twitter as mentioned above.

• Weather handler provides weather information of a specified location.

5.5.2 Mapping Module

As proposed in the previous chapter, this module is used to provide map-based interaction

between user and application by implementing Android Maps API. In order to mapping

items, items need to be implemented as extended MapOverlays as seen in Fig. 5.6. Therefore,

we have implemented following classes to display tweets and events on the map. Those items

Figure 5.6: Technique of Mapping items on Android Map Service

are then placed to their exact locations defined by latitude and longitude values. For events

of which location is not defined or is “null”, they are displayed as onscreen items that are

not bound to a fixed point but stick on the screen and move together with the screen when

the view changes hence the name onscreen item. In Fig. 5.7, events that a user decided to

take part in or was invited are displayed as red V mark icons while nearby public events are

displayed as blue ones and events without location as green onscreen items (see Fig. 5.7).

Besides mapping, in order to provide a full map-based interaction, user must be able to

directly interact with items on the map. Therefore we also implemented those overlays to

be touchable, in which those items will display their detailed information when their overlay

is touched as well as available activities such as join this event or delete this event. A touch

36

(a) Display Itemson Map

(b) Display Itemson Map with Satel-lite View

(c) A PrivateEvent whentouched

(d) A Public Eventwhen touched

(e) A Tweet whentouched

Figure 5.7: Displaying Items on rClient

overlay is also implemented to capture user’s touched point of location which give user the

ability to select the location directly by touching the place he wants to tweet or create event.

The selected location is then automatically used as the location of the corresponding tweet

or event, shown as X mark in Fig. 5.8.

5.5.3 Location Service

This module takes charge of measuring user’s current location to provide this data to other

module when requested, therefore it is implemented with call-back model, shown in List 5.1.

The operation of location service module is basically described in the previous chapter, which

uses the combination of three methods the detect location.

Listing 5.1: Location-service call-back interface1 public interface MyLocation{2 public void getLocation ( Location l ) ;3 }

When location is requested, this module starts up by requesting for both GPS provider

and Network Provider if available. After 5 seconds, it applies for Dead Reckoning by call-

ing for last known location. If this location satisfies an evaluation of time, accuracy and

37

(a) Pin is dropped toTouch Point

(b) Display WeatherInfo

(c) Create a Tweetwith this location

(d) Create an Eventwith this location

(e) Private Event (f) Public Event

Figure 5.8: Input location by touch interaction

source (see List A.3), it is then parsed to requesting module by call-back architecture, and

simultaneously scheduled a termination for Network request-update in 30 seconds and GPS

request-update in 120 seconds respectively, shown in List A.1.

As declared in List A.2, if a new location is detected by Network Provider and satisfies

evaluating conditions, it is parsed to the requesting instance and request for location update

from Network Provider is terminated immediately for battery-saving however GPS Provider

will still be enabled to listen for location update in more 30 seconds because of the fact that

GPS is more accurate and takes more time to respond.

On the other hand, in case a new location is detected by GPS Provider and satisfies above

38

conditions, both GPS Provider and Network Provider is terminated which also finishes this

module’s process.

This module is implemented as MyLocationManager class. In order to request for location

in another Acitivity, this Activity should be implemented with above interface, constructing

its own MyLocationManager instance and start locating by calling MyLocationManager’s

startLocating() method, for example as shown in List 5.2.

Listing 5.2: Using Location-service in other Activity by implementing interface1 private LocationManager lm ;2 private MyLocationManager mlm ;34 public class MappingActivity extends MapActivity implements MyLocation{5 public void onCreate ( Bundle savedInstanceState ) {6 // l o c a t i o n manager7 lm = ( LocationManager ) this . getApplication ( ) . getSystemService (←↩

LOCATION_SERVICE ) ;8 mlm = new MyLocationManager (this , lm , 0) ;9 }

10 // s t a r t l o c a t i n g11 public void doStartLocating ( View v ) {12 if ( mlm . startLocating ( ) == false ) {13 Toast . makeText ( this . getBaseContext ( ) , getText (R . string . gps_disable ) , ←↩

Toast . LENGTH_SHORT ) . show ( ) ;14 }15 else{16 Toast . makeText ( this . getBaseContext ( ) , getText (R . string . gps_enable ) , ←↩

Toast . LENGTH_SHORT ) . show ( ) ;17 }18 }19 }

5.5.4 rNotify Service

rNotify works as a background service in Android mobile device. When activated, this service

will work in the background until being turned off by user without troubling his attention

and requiring his action. During its process, it call for two repeating scheduled tasks, the

first of which continuously requests the location-service module mentioned in Sub-section

5.5.3 for location updates while the other constantly send request to server to obtain a list

of events where the user has decided to take part.

39

In order to notify user with new event rNotify keeps track of the event list where after

receiving response any change indicates a new event therefore it will send a notification to

user about the new event. Similarly, rNotify keeps track of an ongoing list as well as a list

of nearby events to detect new ongoing event and nearby event.

(a) rNotify Setting (b) A new event (c) An ongoingevent

(d) A nearby Event (e) Instant & Con-stant Notification

Figure 5.9: rNotify Service

Listing 5.3: Calculating distance between two location with given co-ordinates1 // haver s ine formula2 private boolean isNear ( double lat , double lon , int range ) {3 if ( currentLat == −1 | | currentLon == −1)4 return false ;5 double earthRadius = 6371 ;6 double dLongRad = Math . toRadians ( lon − currentLon ) ;7 double dLatRad = Math . toRadians ( lat − currentLat ) ;8 double lat1Rad = Math . toRadians ( lat ) ;9 double lat2Rad = Math . toRadians ( currentLat ) ;

10 double haversine = Math . sin ( dLatRad /2) * Math . sin ( dLatRad ) + Math . cos (←↩lat1Rad ) * Math . cos ( lat2Rad ) * Math . sin ( dLongRad /2) * Math . sin ( dLongRad←↩/2) ;

11 double d = 2 * earthRadius * Math . asin ( Math . sqrt ( haversine ) ) ;12 return d * 1000 < range ;13 }

rNotify offers two kind of notification which are instant notification and constant notifi-

cation (see Fig. 5.9(e)). Constant notification is shown by icons and a short statistical text

indicating the number of ongoing event and nearby event. While on the contrary, instant

40

notification is done by sending sound and vibration along with a text message when a new

event is found. Nearby events is detected by calculating distance from the event to user’s

current location by using an implementation of Haversine formula, as mentioned in List 5.3.

5.6 Request/Response between rServer and rClient

It is the fact that connection between server and clients is maintained by sequences of

request/response therefore they play an important role in rSystem.

Request is constructed using character-separated values format. Each field is separated

with each other by character “%n”. For instance, a request for nearby events will have the

following format:

publicmemo%nNE_latitude%nNE_longitude%nSW_latitude%nSW_longitude

where the first field is assumed to be the type of request and following fields describe the

boundary of searching which are respectively latitude, longitude co-ordinate of northeast

point and southwest point.

While format of a request for attended events is defined as follows.

getmemo%nuser_name%npassword

where the first field describes request type followed by username and password which will

be used for verification at server.

CSV format is chosen to because of its simplicity and the fact that the format of requests

is predefined with fixed number of fields corresponding to the type of request. On the other

side, response is mainly constructed in the format of XML because response requires much

complex format than request with more fields of data and undefined number of records.

Therefore an XML builder is deployed in server as well as an XML parser in client. For

example, a response for request mentioned in above example is described in List 5.4.

For the matter of security enhancement, request and response are encrypted before trans-

mitting through Internet and will be decrypted at the opposite side. The encryption we have

41

Listing 5.4: XML format of a response1 <memo>2 <id>1</ id>3 <l a t i t u d e>latitude</ l a t i t u d e>4 <long i tude>longitude</ long i tude>5 <createby>author</ createby>6 <t i t l e>event data</ t i t l e>7 <s t a r t>start time</ s t a r t>8 <end>end time</end>9 <count>number of participants</count>

10 </memo>11 <memo>12 <id>2</ id>13 <l a t i t u d e>latitude</ l a t i t u d e>14 <long i tude>longitude</ long i tude>15 <createby>author</ createby>16 <t i t l e>event data</ t i t l e>17 <s t a r t>start time</ s t a r t>18 <end>end time</end>19 <count>number of participants</count>20 </memo>

implemented in rSystem is AES cryptology provided by Java Security Package. AES Keypass

is currently pre-setup at both ends.

5.7 Summary

In this chapter, we have discussed on the design and implementation of rSystem which con-

sists a Java multi-thread server deployed on a Server computer and an Android application

employed in Android mobile devices. By operating as background service, rNotify imple-

mented in the client is able to proactively imform user with new events, ongoing events as

well as nearby events.

42

Chapter 6

Evaluation of rSystem

6.1 Introduction

To fully evaluate design and implementation of rSystem as well as the mixed location-

service technique proposed in the system, we introduce two types of evaluation. Firstly,

a quantitative analysis was applied to evaluate the positioning method in the matter of

accuracy and respond speed. Secondly, a qualitative evaluation by survey was conducted to

obtain user’s opinion and satisfaction with the system and its services. This chapter focuses

on describing those evaluation as well as their result.

6.2 Quantitative Evaluation of Positioning method6.2.1 Method and Procedure

It is the fact that location-sensing plays an important role in a LBS, therefore an evaluation

on such technique is essential. As being proposed in previous chapters, rSystem utilizes a

positioning method which combines GPS with Network and Dead Reckoning for the sake

of the balance between accuracy and respond speed as well as power-consuming. In order

to evaluate the efficiency of this method, we conducted a comparison between positioning

method used in rSystem and other methods by doing following test.

1. Activate the method.

2. Evaluate its first estimation by the two values, respond time and distance from real

43

position.

3. Evaluate its last estimation before the method stops listening.

Due to the fact that surrounding terrain does considerable influence on location-sensing,

therefore above test was carried out in both urban area with lots of high obstacles and open

area.

SpecificationDevice Samsung Galaxy S (Fig. 6.1)Model number GT-I9000Firmware Android OS 2.2CPU ARM Cortex A8 1GHzMemory 512MB RAMNetwork 3G & WiFi

Table 6.1: Detailed Specification of Device used for Evaluating

Figure 6.1: Samsung Galaxy S

rSystem’s positioning method was compared with following applications using same plat-

form and hardware, described in Table 6.1.

44

• Get Position Test function in LbsTestMode

LbsTestMode is a pre-implemented application on Android devices which is used

by developer to test GPS. It can be accessed in Android OS 2.2 Froyo by dialing

*#*#3214789650#*#* from the Keypad. This method uses only satellite-sensing for

positioning.

• Android Maps application

Maps application is a service provided by Google in Android devices, which uses a both

GPS provider and Network Provider including Cellular and WiFi AP-based sensing as

well as sensor aiding. All of these methods were set enabled during tests.

Firstly, a test was conducted indoor inside a thin-wall two-storey apartment near SFC

campus. Surroundings was open area where there was no high building or trees. Each

method was performed three times in following order.

1. rSystem, LbsTestMode, Maps

2. Maps, rSystem, LbsTestMode

3. LbsTestMode, Maps, rSystem

Similarly, the second attempt was carried out inside a building near Shinjuku station

where surroundings was covered with multi-storey buildings. These two areas were selected

because they represent the contexts where users tend to use the system the most, which are

houses and public entertainment places.

6.2.2 Result and Conclusion

Result of the first test is described in Table 6.2. Because of the design of LbsTestMode that

its function did not stop listening after obtaining location, it was manually turned off after

the first estimation. In some cases, the first estimation was identical to the last estimation

when the process stopped after the first result. GPS worked fine in most of the cases therefore

all methods obtained high accuracy.

45

Subject First estimation Last estimationTime Distance Time Distance

rSytem1.5s 26.65m 14.0s 43.93m2.3s 25.30m 62.3s 25.30m3.0s 25.00m 14.0s 19.43m

LbsTestMode108.0s 50.20m 108.0s 50.20m30.0s 60.39m 30.0s 60.39m12.0s 18.63m 12.0s 18.63m

Maps Application3.5s 29.81m 3.5s 29.81m1.0s 23.58m 60.0s 5.70m3.0s 28.13m 120.0s 10.19m

Table 6.2: Result of Positioning Method Evaluation in Open Area

Deriving from the result, the data proved that mixed method applied in rSystem was able

to provide result with acceptable accuracy and time, where preciseness inside 50 meter range

could be acquired within the first 5 seconds. It was also considered to achieve efficiency in

power-saving as the last estimation was determined within 60 seconds.

The second experiment produced result as demonstrated in Table 6.3. Because of being

surrounded with high obstacles, GPS did not work as well as Network sensing which had

advantage of the availability of Wireless APs and the better Cellular signal in municipal area.

For example, in case of rSystem, the first estimation was produced by Network Provider,

which had the preciseness within 50m while the last estimation was usually given by GPS

which had the difference at 70m-100m. This fact proved the necessity of utilizing both source

to determine user’s location.

Taking advantage of both positioning method, even operating in urban area, rSystem

was able to detect location within 60 seconds with the accuracy up to 50m. Because of the

fact that rSystem’s target is event, the range of 50m is acceptable for such outdoor event as

concerts, fairs or exhibitions.

In conclusion, in both experiments rSystem had the capability of determining location

with considerable preciseness while maintaining low power consumption. Moreover, although

it is still controversial issue to evaluate whether GPS or Network sensing is better in each

46

Subject First estimation Last estimationTime Distance Time Distance

rSytem5.9s 50.30m 50.0s 180.97m2s 30.71m 27.4s 71.29m2.2s 37.86m 64.3s 37.86m

LbsTestMode32.0s 77.57m 32.0s 77.57m29.0s 38.26m 29.0s 38.26m34.0s 112.92m 34.0s 112.92m

Maps Application1s 37.31m 27s 110.95m3.0s 38.59m 80.0s 164.45m2.0s 45.20m 80.0s 38.12m

Table 6.3: Result of Positioning Method Evaluation in Urban Area

particular case, combination of both methods is proved to achieve good result since whatever

source is used, at least one estimation can be obtained in 60 seconds with acceptable accuracy,

which is a required ability when providing notification service.

6.3 Qualitative Evaluation of rSystem6.3.1 Method and Procedure

In order to evaluate user’s satisfaction for the rSystem, we conducted an exploratory user

study where 8 participants were requested to try the system for several days and give opinion

about rSystem and its features.

Specifically, participants were asked about their general satisfaction after using the ser-

vice, followed by their evaluation on the concept of rEvent and rNotify as well as their

assessment of the effectiveness that map-based interaction brought. Finally on the matter

of privacy and security, we studied on their concern on the problem and their evaluation on

the methods applied in rSystem.

In addition to their real experience on using the system, participants were given with some

predefined scenarios of usage which helped them to comprehend the functions of rSystem

easier.

47

6.3.2 Result and Conclusion

Firstly, rSystem received considerably good evaluation from users when 75% of participants

appreciated it as useful in their daily lives and satisfied with the service while the rest of

25% considered it as average level.

Evaluation on rEvent

When it comes to rEvent service, participants were asked to evaluate following functions by

giving mark from -2 to 2 corresponding to the order of ‘Useless’, ‘Not Useful’, ‘Average’,

‘Useful’ and ‘Very Useful’.

• Create private event to use as self-reminder purpose.

• Create private event to use in a group as group-reminder or meeting arrangement.

• Create public event for promotion and invitation.

• Look for nearby public events for suggestion of event.

Detailed result is described in Table 6.4 which shows that although all functions’ usefulness

were admitted, the purposes of event promotion and self-reminder were appreciated the most.

Function VeryUseful(2)

Useful(1)

Average(0)

Not Use-ful (-1)

Useless(-2)

Total

Self reminder 1 6 1 0 0 1Group reminder 0 5 3 0 0 0.625Event promotion 2 5 1 0 0 1.125Event suggestion 0 7 1 0 0 0.875

Table 6.4: Result of rEvent Evaluation

Evaluation on rNotify

Secondly, participants were asked for their assessment for notification service, including

notification for new event, event that was about to start and nearby event. The result

48

shown in Table 6.5, expresses the fact that information of starting event and nearby event

were considered the most effective feature.

Function VeryUseful(2)

Useful(1)

Average(0)

Not Use-ful (-1)

Useless(-2)

Total

Overall notifica-tion service

2 5 1 0 0 1.125

Notify for newevent

1 6 1 0 0 1

Notify for startingevent

3 4 1 0 0 1.25

Notify for nearbyevent

3 4 1 0 0 1.25

Table 6.5: Result of rNotify Evaluation

Another interesting find is that those instant type of notification was preferred than

constant notification because according to a participant, it was the instant notification that

helped them to notice the tasks they wanted to be reminded.

Evaluation on Map-based Interaction

All participants have used smartphone such as iPhone or Android so they are familiar with

the “touch” interaction. The survey revealed that the input of interaction, which allows

users to directly interact with map’s items, was considered even more useful than the output

displaying items on the map as 8/8 participants agreed that the former was more helpful.

Evaluation on Privacy Problem

Before trying rSystem, 8 participants were asked whether they were concerned for privacy

problem, 100% of whom claimed that they would worry about the threat of being track

by other people. After being described with the privacy policy as well as security method

applied in rSystem, 3 of 8 participants acknowledged them as being good enough while 5

users appraised them as average level. As shown in Fig. 6.2, 25% of participants no longer

worry about above threat when using rSystem.

49

Figure 6.2: User’s Concern for Privacy

In conclusion, our user study shows that rSystem was considered useful with its capa-

bility of giving instant notification, especially when an event is about to start or when the

user approaches near an event, which reminded them about the event effectively. Besides,

the ability to publicize event is highly appreciated. This fact proves that the possibility

of location-based marketing or advertisement is practical. However, such service should

be considered carefully when developing because user are extremely concerned about their

privacy.

6.4 Summary

In this chapter, we have mentioned about our evaluating methods applied to rSystem. rSys-

tem is appreciated for its usefulness and effectiveness of giving proactive notification. Techni-

cal approach applied in the system also achieved considerable accuracy on positioning, while

proved to be efficient on power-saving. Our privacy policy was proved to have influence on

user’s concern for the problem as well.

50

Chapter 7

Conclusion and Future Work

In conclusion, rSystem have proved that location-awareness can offer user with more benefit

if proactive service is added into LBS. In addition to traditional time-based notification, we

found out that location-based notification is highly appreciated.

When it comes to the concept of an event, location factor shows its usefulness by the

capability of providing many location-related service as well as enabling visualization of the

event on the map.

Since location-sensing is the key technology in a LBS, our research revealed that a method

taking advantage of both GPS and Network positioning as well as using Dead Reckoning

appropriately, could provide result with considerable accuracy within acceptable time while

achieving battery-efficiency. Moreover, instead of having the system tracking user’s loca-

tion, the method in which the application itself is aware of its current location to provide

corresponding reaction, was proved to be effective toward the problem of user’s concern for

privacy.

During our user study, we have acquired some valuable opinion for the development of

rSystem in the future. Firsly, the concept of event should be made more sophisticated, for

example event should be classified by type so that users can search for event matching their

interest. Moreover, in order to have a large database of event, event is expected to be created

not only by users, but also be collected from other sources of database. Finally, users are

looking forward to using the system on more platform, especially iPhone.

51

Acknowledgement

First of all, I would like to thank my advisor, Professor Tatsuya Hagino for his great advice,

guidance and encouragement during my research. I am also extremely grateful to Associate

Professor Takashi Hattori for his valuable comments and support on my project and this

thesis.

I am deeply thankful to Mr. Hiroto Yahagi and Mr. Junya Hirose for helping me a lot

since I joined HxH Lab., as well as all members of HxH Laboratory and POS group for their

great support and encouragement.

I highly appreciate my friends and my juniors from Vietnamese student group for their

precious aid when I carried out experiments on rSystem.

Last but not least, I am very grateful for receiving consecutive encouragement from my

family and my friends here in Japan during my study abroad.

52

Bibliography

[1] Mixi counter. http://s.hamachiya.com/mc/.

[2] Louise Barkhuus. Privacy in location-based services, concern vs. coolness. In Mobile

HCI 2004 Workshop on Location Systems Privacy and Control.

[3] Louise Barkhuus and Anind Dey. Location-based services for mobile telephony: a study

of users’ privacy concerns. In 9th IFIP TC13 International Conference on Human-

Computer interaction, pages 709–712.

[4] Paolo Bellavista, Axel Küpper, and Sumi Helal. Location-based services: Back to the

future. In IEEE Pervasive Computing, volume 7 Issue 2, pages 85–89, April 2008.

[5] Jeff Bertolucci. Mobile internet to dominate within 5 years. http://www.pcworld.com/

article/184876/mobile_internet_to_dominate_within_5_years_study.html, Decem-

ber 2009.

[6] Sunny Consolvo, Ian E. Smith, Tara Matthews, Anthony Lamarca, Jason Tabert, and

Pauline Powledge. Location disclosure to social relations: Why, when, & what people

want to share. In In Proc. CHI, pages 81–90. ACM Press, 2005.

[7] Goran M. Djuknic and Robert E. Richton. Geolocation and assisted gps. Computer,

34:123–125, February 2001.

[8] Yan-David Erlich. Beyond the checkin: Where location-based social networks should

go next. http://mashable.com/2010/07/01/location-social-media, July 2010.

53

[9] William G. Griswold, Patricia Shanahan, Steven W. Brown, Robert Boyer, Matt Ratto,

and et al. Activecampus – experiments in community-oriented ubiquitous computing.

IEEE Computer, 37:73–81, 2003.

[10] Georg Groh and Christian Hillebr. Lbcs–location based community services: Proactive

lbs services for mobile communities in the research project cosmos. Technical report,

Technical University of Munich, 2004.

[11] Compete Inc. Social networks: Facebook takes over top spot, twit-

ter climbs. http://blog.compete.com/2009/02/09/facebook-myspace-twitter-social-

network, February 2009.

[12] Twitter Inc. About the tweet location feature. http://support.twitter.com/articles/

78525-about-the-tweet-location-feature.

[13] Twitter Inc. About twitter. http://twitter.com/about, September 2010.

[14] Twitter Inc. A few twitter facts. http://twitter.com/about, September 2010.

[15] Axel Küpper. Location-based Service Fundamentals and Operation. John Wiley and

Sons Ltd, 2005.

[16] Natalia Marmasse and Chris Schmandt. Location-aware information delivery with com-

motion. In HUC 2000, pages 157–171. Springer, 2000.

[17] ComScore Data Mine. Twitter sees impressive growth in japan. http:/

/www.comscoredatamine.com/2010/11/twitter-sees-impressive-growth-in-japan,

November 2010.

[18] Mobile Advertising News. Grand Truth: Half of all the time spent on the mobile

internet is on Social Networking Sites. http://www.mobiadnews.com/?page_id=4529,

April 2010.

54

[19] Daniele Quercia, Neal Lathia, Francesco Calabrese, Giusy Di Lorenzo, and Jon

Crowcroft. Recommending social events from mobile phone location data. In ICDM’10:

10th IEEE International Conference on Data Mining, pages 14–17, 2010.

[20] Needleman Rafe, Claire Cane Miller, and Adrianne Jeffries. Reporters’ roundtable:

Checking in with facebook and foursquare. http://www.cnet.com/8301-30976_1-

20015615-10348864.html, September 2010.

[21] Riva Richmond. Three best ways to use location-based social media. The Wall Street

Journal, September 2010.

[22] Bernt Schiele, Stavros Antifakos, and Adrian Schwaninger. Evaluating the effects of

displaying uncertainty in context-aware applications. In 6th International Conference

on Ubiquitous Computing (ubicomp 2004), pages 54–69, 2004.

[23] Timothy Sohn, Kevin A. Li, Gunny Lee, Ian Smith, James Scott, and William G.

Griswold. Place-its: A study of location-based reminders on mobile phones. In In

Ubicomp, pages 232–250. Springer, 2005.

[24] New York Times. Losing popularity contest, myspace tries a makeover. http://

www.nytimes.com/2009/05/04/technology/companies/04myspace.html, May 2009.

[25] New York Times. Facebook tops 500 million users. http://www.nytimes.com/2010/07/

22/technology/22facebook.html, July 2010.

[26] Amar Toor. ’tweet your location’ from twitter next move in location-based blog-

ging. http://www.switched.com/2010/03/11/tweet-your-location-from-twitter-next-

move-in-location-based-b, March 2010.

[27] Yusuke Yamamoto. Twitter4j. http://twitter4j.org/en/index.html.

55

[28] Max Zeledon. Why social media should welcome location-based services. http:/

/www.businessweek.com/technology/content/sep2009/tc20090927_138649.htm,

September 2009.

[29] Yu Zheng, Yukun Chen, Xing Xie, and Wei-Ying Ma. Geolife2.0: A location-based

social networking service. In Proceedings of the 2009 Tenth International Conference on

Mobile Data Management: Systems, Services and Middleware, MDM ’09, pages 357–

358, Washington, DC, USA, 2009. IEEE Computer Society.

[30] Kathryn Zickuhr and Aaron Smith. 4% of online americans use location-based

services. http://www.pewinternet.org/Reports/2010/Location-based-services/Report/

Main-findings.aspx, November 2010.

56

Appendix A

Appendix

Start Positioning using GPS, Network Provider and DeadReckoning

Listing A.1: Method used to start positioning1 \\start locating location2 public boolean startLocating ( ) {3 timer = new Timer ( ) ;4 // get l a s t l o c a t i o n a f t e r 5 s5 timer . schedule ( new TimerTask ( ) {6 public void run ( ) {7 if ( locationManager . isProviderEnabled ( LocationManager . GPS_PROVIDER ) == ←↩

true ) {8 lastLocationGPS = locationManager . getLastKnownLocation (←↩

LocationManager . GPS_PROVIDER ) ;9 if ( lastLocationGPS != null ) {

10 // only accept accurate data11 if ( isAccurate ( lastLocationGPS ) ) {12 bestLocation = lastLocationGPS ;13 myLocation . getLocation ( lastLocationGPS ) ;14 // wait f o r 120 more seconds f o r gps l o c a t i o n change be f o r e ←↩

te rminat ing15 new Timer ( ) . schedule ( new TimerTask ( ) {16 public void run ( ) {17 locationManager . removeUpdates ( locationListenerGPS ) ;18 }19 } , 120000) ;20 // wait f o r 30 s f o r nw l o c a t i o n change be f o r e te rminat ing21 new Timer ( ) . schedule ( new TimerTask ( ) {22 public void run ( ) {23 locationManager . removeUpdates ( locationListenerNW ) ;24 }25 } , 30000) ;26 }27 }

57

28 }29 if ( locationManager . isProviderEnabled ( LocationManager . NETWORK_PROVIDER )←↩

== true ) {30 lastLocationNW = locationManager . getLastKnownLocation (←↩

LocationManager . NETWORK_PROVIDER ) ;31 if ( lastLocationNW != null ) {32 // only accept accurate data33 if ( isAccurate ( lastLocationNW ) ) {34 bestLocation = lastLocationNW ;35 myLocation . getLocation ( lastLocationNW ) ;36 // wait f o r 120 more seconds f o r gps l o c a t i o n change37 new Timer ( ) . schedule ( new TimerTask ( ) {38 public void run ( ) {39 // TODO Auto−generated method stub40 locationManager . removeUpdates ( locationListenerGPS ) ;41 }42 } , 120000) ;43 // wait f o r 30 s f o r nw l o c a t i o n change44 new Timer ( ) . schedule ( new TimerTask ( ) {45 public void run ( ) {46 // TODO Auto−generated method stub47 locationManager . removeUpdates ( locationListenerNW ) ;48 }49 } , 30000) ;50 }51 }52 }53 }54 } , 5000) ;55 boolean gps = false ;56 boolean network = false ;57 try{58 gps = locationManager . isProviderEnabled ( LocationManager . GPS_PROVIDER ) ;59 network = locationManager . isProviderEnabled ( LocationManager .←↩

NETWORK_PROVIDER ) ;60 }61 catch ( Exception e ) {}62 if ( gps == false && network == false ) {63 return false ;64 }65 else{66 locationManager . requestLocationUpdates ( LocationManager . GPS_PROVIDER , ←↩

minUpdateTime , 0 , locationListenerGPS ) ;67 locationManager . requestLocationUpdates ( LocationManager . NETWORK_PROVIDER ,←↩

minUpdateTime , 0 , locationListenerNW ) ;68 return true ;69 }70 }

58

Timing of GPS and Network Provider

Listing A.2: Timing of GPS and Network Provider1 locationListenerGPS = new LocationListener ( ) {2 // get new l o c a t i o n3 public void onLocationChanged ( Location location ) {4 if ( isAccurate ( location ) ) {5 // t h i s i s bes t l o c a t i o n6 bestLocation = location ;7 // remove g e t l a s t l o c a t i o n t imer task8 if ( timer != null )9 timer . cancel ( ) ;

10 // send new l o c a t i o n to a c t i v i t y and terminate a l l r eque s t f o r ←↩l o c a t i o n change

11 myLocation . getLocation ( location ) ;12 locationManager . removeUpdates ( locationListenerNW ) ;13 locationManager . removeUpdates ( locationListenerGPS ) ;14 }15 }16 } ;17 locationListenerNW = new LocationListener ( ) {18 public void onLocationChanged ( Location location ) {19 if ( isAccurate ( location ) ) {20 // t h i s i s bes t l o c a t i o n21 bestLocation = location ;22 // remove g e t l a s t l o c a t i o n t imer task23 if ( timer != null )24 timer . cancel ( ) ;25 // send new l o c a t i o n to a c t i v i t y and terminate NW reques t f o r l o c a t i o n←↩

change26 myLocation . getLocation ( location ) ;27 locationManager . removeUpdates ( locationListenerNW ) ;28 // s t i l l wait 60 seconds f o r GPS l i s t e n e r29 new Timer ( ) . schedule ( new TimerTask ( ) {30 public void run ( ) {31 locationManager . removeUpdates ( locationListenerGPS ) ;32 }33 } , 60000) ;34 }35 }36 } ;

59

Evaluating Accuracy of New Location

Listing A.3: Method used to compare the accuracy of new location data with current bestknown location

1 private boolean isAccurate ( Location l ) {2 // do not accept too o ld l o ca t i on , o l d e r than 5 mins3 long now = new Date ( ) . getTime ( ) ;4 if (l . getTime ( ) < now − 1000 * 60 * 5)5 return false ;6 // there i s no be t t e r l o c a t i o n7 if ( bestLocation == null )8 return true ;9

10 int providerDif = compareProvider (l , bestLocation ) ;11 // same prov ide r12 if ( providerDif == 0) {13 long timeDif = l . getTime ( ) − bestLocation . getTime ( ) ;14 boolean isNewer = timeDif > 0 ;15 boolean isMuchNewer = timeDif > 12000;16 boolean isMuchOlder = timeDif < −12000;17 // t h i s l o c a t i o n i s 2 minutes newer than best l o c a t i o n18 if ( isMuchNewer )19 return true ;20 // t h i s l o c a t i o n i s 2 minutes o ld e r than best l o c a t i o n21 else if ( isMuchOlder )22 return false ;23 // between time gap24 else{25 float accuracyDif = l . getAccuracy ( ) − bestLocation . getAccuracy ( ) ;26 boolean isMoreAccurate = accuracyDif < 0 ;27 boolean isLessAccurate = accuracyDif > 0 ;28 boolean isNotAccurate = accuracyDif > 20 ;29 // more accurate r e s u l t30 if ( isMoreAccurate )31 return true ;32 // same accurate but newer i n f o33 else if ( isNewer && ! isLessAccurate )34 return true ;35 // l e s s accurate but newer i n f o and from GPS36 else if ( isNewer && ! isNotAccurate && l . getProvider ( ) . equals (←↩

LocationManager . GPS_PROVIDER ) )37 return true ;38 else39 return false ;40 }41 }42 // from weaker prov ide r43 else if ( providerDif == −1){44 // l a r g e r time d i f45 long timeDif = l . getTime ( ) − bestLocation . getTime ( ) ;

60

46 boolean isNewer = timeDif > 0 ;47 boolean isMuchNewer = timeDif > 60000;48 // much newer i n f o49 if ( isMuchNewer )50 return true ;51 // newer i n f o52 else if ( isNewer ) {53 float accuracyDif = l . getAccuracy ( ) − bestLocation . getAccuracy ( ) ;54 boolean isVeryAccurate = accuracyDif < − 20 ;55 // much more accurate56 if ( isVeryAccurate )57 return true ;58 else59 return false ;60 }61 // not newer i n f o62 else63 return false ;64 }65 // from be t t e r prov ide r66 else{67 long timeDif = l . getTime ( ) − bestLocation . getTime ( ) ;68 boolean isNewer = timeDif > 0 ;69 // newer i n f o70 if ( isNewer )71 return true ;72 // o ld e r i n f o73 else{74 float accuracyDif = l . getAccuracy ( ) − bestLocation . getAccuracy ( ) ;75 boolean isNotAccurate = accuracyDif > 20 ;76 // not too bad accuracy77 if ( ! isNotAccurate )78 return true ;79 else80 return false ;81 }82 }83 }

61