Proactive Event Reminder With Location Based Service

rSystem: A Location-based Event Service
with Proactive Notication

Ngo Minh Quan
Faculty of Environment and Information Studies
Keio University
5322 Endo Fujisawa Kanagawa 252-8520 JAPAN
Submitted in partial fulllment of the requirements
for the degree of Bachelor
Advisors:
Professor Tatsuya Hagino
Associate Professor Takashi Hattori
Copyright2010 Ngo Minh Quan
Abstract of Bachelors Thesis

rSystem: A Location-based Event Service
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 notication which has the
ability of locating users 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 users privacy which is a controversial issue of location-aware service generally.
Ngo Minh Quan

Faculty of Environment and Information Studies, Keio University

rSystem:
(LBSNS)
LBS
rSystem
rSystem
rSystem
ii
Contents
1 Introduction
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Structure of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Background: The Prospect of Location-based in SNS
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Current Trends and Future Possibilities of SNS . . . . . . . . . . . . . . . .
2.3
Location-based, An Emerging Trend in Social Networking . . . . . . . . . .
2.3.1
Denition and Classcation of LBS . . . . . . . . . . . . . . . . . . .
2.3.2
Emergence of LBS in Social Networking . . . . . . . . . . . . . . . .
2.3.3
Geosocial Networking . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
3 Problem, Motivation and Related Works
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Current Problems of LBS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1
Essential Work for the Next Generation of LBS . . . . . . . . . . . .
3.2.2
The Need of New User Experience beyond the Check-in . . . . . . .
10
3.2.3
Users 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 Notication
15
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2
rSystem, A Location-based Event Service with Proactive Notication . . . .
15
4.3
Conceptual Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.3.1
rEvent, A Location-based Event . . . . . . . . . . . . . . . . . . . . .
16
4.3.2
rNotify, A Proactive Location-based Notication . . . . . . . . . . .
18
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
4.4
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
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
5.5
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
Qualitative Evaluation of rSystem . . . . . . . . . . . . . . . . . . . . . . . .
47
6.3.1
Method and Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .
47
6.3.2
Result and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.3
6.4
7 Conclusion and Future Work
51
A Appendix
57
List of Tables
2.1
Comparison between Reactive and Proactive Service . . . . . . . . . . . . .
4.1
Comparison among GPS, Network and Dead Reckoning . . . . . . . . . . . .
22
5.1
Specication of Servers Implementation . . . . . . . . . . . . . . . . . . . .
30
6.1
Detailed Specication 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 . . . . . . . . . . . . . . . . . . . .
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
Users 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 networking 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 users interest, next generation of service that oers new user experience is highly
expected. Therefore, in this thesis we propose rSystem, a LBS that focuses on social event
and oers a proactive notication 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
users concern for privacy that need to be considered. And nally, as well as developing any
service users 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 notication. 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.
Chapter 2
Background: The Prospect of
Location-based in SNS
2.1 Introduction
This chapter describes the overlook of location-based concept in social networking. In the
rst 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 reecting 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 oers 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 users prole 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 surng 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 signicant movement to mobile device.
Development of mobile devices with such technologies as satellite positioning and cellular positioning, have as well made mobile tracking possible within an aordable 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.
2.3 Location-based, An Emerging Trend in Social Networking

2.3.1 Denition and Classcation of LBS
LBS, which is also known as location-aware service or location-related service, is dened
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 ltering
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 predened
location.
Based on their characteristic and interaction, LBS can be classied 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 automatically initialized as soon as a predened location event occurs, for example when the user
approaches, or leaves a certain specied 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.
Initializing
Condition
Interaction
Location tracking
Reactive
Requested by User
User invokes
Synchronous
Once
Proactive
Self-initialized
Predened event occurs
Asynchronous
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 nder 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 signicant 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 nally, 3G service has freed mobile devices
from xed 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].
Figure 2.1: The Evolution of Location-based Services as described in LBS: Back to the
Future [4]
2.3.3 Geosocial Networking

Geosocial networking is a type of social networking in which geographic services and capabilities 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 specic 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
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
signicantly 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.
Chapter 3
Problem, Motivation and Related
Works
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 users 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 LBS

3.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 problems of the early LBSs was that that they were reactive, self-referencing, single-target and
content-oriented. The panel also identied 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.
Secondly, cross-referencing is necessary because its 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 nally, a movement from content-oriented to application-oriented is expected,
which in short enables applications content to be dynamically changed based on users
interest.
Most of current LBSs are still reactive and self-referencing. For example, some services that
we have mentioned in previous chapter only oer check-in services, where users use can
check-in into predened places around their positions. Whereas not many service has the
capability of proactiveness. Therefore we conclude that more eort 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 ones 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 its too late to rethink the basics, or theyre 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, trac 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 Users Concern for Privacy

Because LBS is a context-aware service involving tracking peoples location which is classied
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 its 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 nd them less threatening and more acceptable [2, 6].
A study on users privacy concerns shows that, they concern more on location-tracking,
in which users 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 benet their service
oers and users 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 users 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 notication
service.
3.3 Related Works

The idea of using location as an element of context-aware to provide proactive notication
is not new as much work has been done to deploy such service in the past few years. Sharing 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
predened location, with given time constraints. When a user was near that location and
the timing constraints are both satised, he would be alerted with an audio alert.
Another recent work was Place-Its [23] which provides location-based reminders on Symbian 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 location. 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 campus 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 predened locations on campus such as buildings or classrooms.

These pioneering eorts mentioned above, although used dierent 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 noncovered areas, GPS positioning appears to be the most accurate method [7]. Nevertheless,
before GPS-capable devices became popular and aordable, 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 eorts 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 signicant conclusion they have found out is that location-based reminder service was highly accepted by users. In spite of having low accuracy, most participants of Place-Its found it useful. Other researches on evaluating the eect of memory
aids used to help recall also stated that displaying uncertainty was eective to improve recall
rates [22]. For this reason, such location-based notication 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 dierent approach, instead of providing proactive reminder like
above works, it oers recommendations that match users interest. GeoLife was a GPSdata-driven social networking service where people can share life experiences and connect to
13
each other with their location histories. By mining users location history and their friends
activities , GeoLife is able to predict the individuals interest in the locations to suggest
recommendation about places of interest.
The importance of proactive service is also agreed by some previous research. For example, Location Based Community Services [10] is a service emphasizing on friend nder 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 notication.
14
Chapter 4
rSystem, A Location-based Event
Service with Proactive Notication
4.1 Introduction
This chapter contains our approach on the problems stated in the previous chapter by proposing rSystem, a location-based event service with proactive notication. 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 Service

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 notication 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 pro15
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 notication service. Server-Client model is considered
to help reduce clients 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 notication 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 events basic information, rEvent consists of three elements (see Fig. 4.2).
1. The rst element is participant who takes part in the event. This information distinguishes 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 events 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 events 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
( )
d
R
= haversin (2 1 ) + cos 1 cos 2 haversin
given that
haversin () = sin2
( )
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 Rd
An event is considered as nearby event when the distance from this event to users
current location is within a range predened by user. Based on events location information, users are able to search for nearby events or events in a specied 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 Twitters
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 notied about the event when the time constraint or location constraint
satises. 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 notied 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 Notication

With the purpose of producing proactive characteristic for rSystem, we propose rNotify as
a solution. rNotify is a proactive notication service, which based on users current location
automatically informs user with incoming events and nearby events without requiring users
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 users 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 rst module constantly requests
for location information of user from the devices positioning service. The other stays updated 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 users attention
by sending notication 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 briey 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 users 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
Twitters 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
Twitters 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 rSystems 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 oers nearby tweet and nearby
friend function, the former of which displays tweets that is sent around a specic 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 rst 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 availability 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 powerconsuming. Because of the requirement of at least four satellites in sight, it is dicult 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 sucient strength inside building and
many Indoor GPS methods are being developed, GPS positioning is still considered
the most valuable source to detect users location.
21
Dead Reckoning
Method
Respond time
Accuracy
Powerconsumption
Estimating on last
known location
Immediately
Very low
None
Network
Positioning
Cellular & WiFi
based sensing
Fast
Medium
High
GPS Positioning
Satellite sensing
Slow
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-eciency requires a lot of consideration. On this specic 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 between accuracy and battery-eciency 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 specied 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 predened 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 notication service, keeping track of users 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 devices
positioning service. In other words, rNotify keeps track of users location by continuously
send request to devices 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 dicult for users to comprehend. 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 on (b) Google Maps on (c) Ovi

Android
iPhone
Nokia
Maps
on (d) Bing Maps on

BlackBerry
Figure 4.5: Map service on many platforms
4.4.4 Privacy and Security

As indicated in Chapter 3, users 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, users 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 notication function where tracking of users 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 noties user where he approaches to an
event.
Secondly, although users location is not recorded, his trace is still stored in some cases,
for example by creating, joining an event, sending tweet. The rst 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 xed. 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 notication about the event meeting by Ken. By using
rSystem, they are able to see the location where the meeting will take place. When its 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 Hondas 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 notication which are the core of the system in the hope of bringing new
user experience. An approach to take full advantage of mobile devices available locationservices 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 of
rSystem
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 Twitters data.
There are two types of accesses between rServer and Twitter. The rst using Stream
API allows server to capture real time status from Twitters public stream to lter for events
27
Figure 5.1: System Design using Sever-Client model
which were sent from Twitters user via website and other applications. The other utilizes
REST API to provide access to data of Twitters 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 users 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 notication, 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 interaction 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 users 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 rst 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. Specically, username is a users 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 specication is shown as Table 5.1
Implementation
Hardware
Server
Available Resource
Operating System
Address
Java platform
Database Server
Specication
2 x Xeon L5520 CPU 6GB Memory
Virtual Server
2 core 1024MB Memory
CentOS version 5.5
enkaku.tom.sfc.keio.ac.jp
OpenJDK Runtime Enviroment
MySQL version 5.0.77
Table 5.1: Specication of Servers 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 servers 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
nally, 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
specied 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
Twitters public stream. It lters 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 lter 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 expressed 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 Twitters mention @ notation
and the hashtag #rmemo species 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 rServers database. Information 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 nding 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, specically within 6 hours from current
time.
Nearby tweet handler which handles request for nearby tweet. Instead of nding
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 specied location. 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 notication 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 oered 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
users home time line, updating new status, nding nearby friend.
Nearby Tweet handler provides a fast response for nearby tweet sent around a
35
specic location by looking in the rServers database instead of searching directly from
Twitter as mentioned above.
Weather handler provides weather information of a specied 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 dened by latitude and longitude values. For events
of which location is not dened or is null, they are displayed as onscreen items that are
not bound to a xed 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 Items (b) Display Items (c) A

on Map
on Map with Satel- Event
lite View
touched
Private (d) A Public Event (e) A Tweet when

when when touched
touched
Figure 5.7: Displaying Items on rClient

overlay is also implemented to capture users 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 users 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 interface
1
2
3
public interface MyLocation {

public void getLocation ( Location l ) ;
}
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 calling for last known location. If this location satises an evaluation of time, accuracy and
37
(a) Pin is dropped to (b) Display Weather (c) Create a Tweet (d) Create an Event
Touch Point
Info
with this location
with 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 satises
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 satises above
38
conditions, both GPS Provider and Network Provider is terminated which also nishes this
modules 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 MyLocationManagers
startLocating() method, for example as shown in List 5.2.
Listing 5.2: Using Location-service in other Activity by implementing interface
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
private LocationManager lm ;
private MyLocationManager mlm ;
public class MappingActivity extends MapActivity implements MyLocation {
public void onCreate ( Bundle savedInstanceState ) {
// l o c a t i o n manager
lm = ( LocationManager ) this . getApplication ( ) . getSystemService ( LOCATION_SERVICE ) ;
mlm = new MyLocationManager ( this , lm , 0 ) ;
}
// s t a r t l o c a t i n g
public void doStartLocating ( View v ) {
if ( mlm . startLocating ( ) == false ) {
Toast . makeText ( this . getBaseContext ( ) , getText ( R . string . gps_disable ) , Toast . LENGTH_SHORT ) . show ( ) ;
}
else {
Toast . makeText ( this . getBaseContext ( ) , getText ( R . string . gps_enable ) , Toast . LENGTH_SHORT ) . show ( ) ;
}
}
}
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 o by user without troubling his attention
and requiring his action. During its process, it call for two repeating scheduled tasks, the
rst 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 notication 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
event
ongoing (d) A nearby Event (e) Instant & Constant Notication
Figure 5.9: rNotify Service
Listing 5.3: Calculating distance between two location with given co-ordinates
1
2
3
4
5
6
7
8
9
10
11
12
13
// h a v e r s i n e f o r m u l a
private boolean isNear ( double lat , double lon , int range ) {
if ( currentLat == 1 | | currentLon == 1)
return false ;
double earthRadius = 6 3 7 1 ;
double dLongRad = Math . toRadians ( lon currentLon ) ;
double dLatRad = Math . toRadians ( lat currentLat ) ;
double lat1Rad = Math . toRadians ( lat ) ;
double lat2Rad = Math . toRadians ( currentLat ) ;
double haversine = Math . sin ( dLatRad / 2 ) * Math . sin ( dLatRad ) + Math . cos ( lat1Rad ) * Math . cos ( lat2Rad ) * Math . sin ( dLongRad / 2 ) * Math . sin ( dLongRad/2) ;
double d = 2 * earthRadius * Math . asin ( Math . sqrt ( haversine ) ) ;
return d * 1000 < range ;
}
rNotify oers two kind of notication which are instant notication and constant notication (see Fig. 5.9(e)). Constant notication is shown by icons and a short statistical text
indicating the number of ongoing event and nearby event. While on the contrary, instant
40
notication 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 users
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 eld 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 rst eld is assumed to be the type of request and following elds 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 dened as follows.
getmemo%nuser_name%npassword
where the rst eld describes request type followed by username and password which will
be used for verication at server.
CSV format is chosen to because of its simplicity and the fact that the format of requests
is predened with xed number of elds 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 elds of data and undened 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 transmitting through Internet and will be decrypted at the opposite side. The encryption we have
41
Listing 5.4: XML format of a response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<memo>
<i d>1</ i d>
<l a t i t u d e>latitude</ l a t i t u d e>
<l o n g i t u d e>longitude</ l o n g i t u d e>
<c r e a t e b y>author</ c r e a t e b y>
< t i t l e>event data</ t i t l e>
<s t a r t>start time</ s t a r t>
<end>end time</ end>
<count>number of participants</ count>
</memo>
<memo>
<i d>2</ i d>
<l a t i t u d e>latitude</ l a t i t u d e>
<l o n g i t u d e>longitude</ l o n g i t u d e>
<c r e a t e b y>author</ c r e a t e b y>
< t i t l e>event data</ t i t l e>
<s t a r t>start time</ s t a r t>
<end>end time</ end>
<count>number of participants</ count>
</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 consists 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 implemented 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 locationservice 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 users 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 method

6.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 eciency 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 rst 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 inuence on location-sensing,
therefore above test was carried out in both urban area with lots of high obstacles and open
area.
Specication
Device
Samsung Galaxy S (Fig. 6.1)
Model number GT-I9000
Firmware
Android OS 2.2
CPU
ARM Cortex A8 1GHz
Memory
512MB RAM
Network
3G & WiFi
Table 6.1: Detailed Specication of Device used for Evaluating
Figure 6.1: Samsung Galaxy S
rSystems positioning method was compared with following applications using same platform 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 rst 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 o after
the rst estimation. In some cases, the rst estimation was identical to the last estimation
when the process stopped after the rst result. GPS worked ne in most of the cases therefore
all methods obtained high accuracy.
45
Subject
rSytem
LbsTestMode
Maps Application
First estimation
Time Distance
1.5s
26.65m
2.3s
25.30m
3.0s
25.00m
108.0s 50.20m
30.0s 60.39m
12.0s 18.63m
3.5s
29.81m
1.0s
23.58m
3.0s
28.13m
Last estimation
Time Distance
14.0s 43.93m
62.3s 25.30m
14.0s 19.43m
108.0s 50.20m
30.0s 60.39m
12.0s 18.63m
3.5s
29.81m
60.0s 5.70m
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 rst 5 seconds. It was also considered to achieve eciency 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 rst estimation was produced by Network Provider,
which had the preciseness within 50m while the last estimation was usually given by GPS
which had the dierence at 70m-100m. This fact proved the necessity of utilizing both source
to determine users 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 rSystems 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
rSytem
LbsTestMode
Maps Application
First estimation
Time Distance
5.9s
50.30m
2s
30.71m
2.2s
37.86m
32.0s 77.57m
29.0s 38.26m
34.0s 112.92m
1s
37.31m
3.0s
38.59m
2.0s
45.20m
Last estimation
Time Distance
50.0s 180.97m
27.4s 71.29m
64.3s 37.86m
32.0s 77.57m
29.0s 38.26m
34.0s 112.92m
27s
110.95m
80.0s 164.45m
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 notication service.
6.3 Qualitative Evaluation of rSystem

6.3.1 Method and Procedure
In order to evaluate users 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.
Specically, participants were asked about their general satisfaction after using the service, followed by their evaluation on the concept of rEvent and rNotify as well as their
assessment of the eectiveness 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
predened 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 satised 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
Self reminder
Group reminder
Event promotion
Event suggestion
Very
Useful
(2)
1
0
2
0
Useful
(1)
Average
(0)
Not Useful (-1)
Useless
(-2)
Total
6
5
5
7
1
3
1
1
0
0
0
0
0
0
0
0
1
0.625
1.125
0.875
Table 6.4: Result of rEvent Evaluation
Evaluation on rNotify
Secondly, participants were asked for their assessment for notication service, including
notication 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 eective feature.
Function
Very
Useful
(2)
Overall notica- 2
tion service
Notify for new 1
event
Notify for starting 3
event
Notify for nearby 3
event
Useful
(1)
Average
(0)
Not Useful (-1)
Useless
(-2)
Total
1.125
1.25
1.25
Table 6.5: Result of rNotify Evaluation
Another interesting nd is that those instant type of notication was preferred than
constant notication because according to a participant, it was the instant notication 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 maps 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: Users Concern for Privacy
In conclusion, our user study shows that rSystem was considered useful with its capability of giving instant notication, especially when an event is about to start or when the
user approaches near an event, which reminded them about the event eectively. 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. rSystem is appreciated for its usefulness and eectiveness of giving proactive notication. Technical approach applied in the system also achieved considerable accuracy on positioning, while
proved to be ecient on power-saving. Our privacy policy was proved to have inuence on
users concern for the problem as well.
50
Chapter 7
Conclusion and Future Work
In conclusion, rSystem have proved that location-awareness can oer user with more benet
if proactive service is added into LBS. In addition to traditional time-based notication, we
found out that location-based notication 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-eciency. Moreover, instead of having the system tracking users location, the method in which the application itself is aware of its current location to provide
corresponding reaction, was proved to be eective toward the problem of users 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 classied 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 HumanComputer interaction, pages 709712.
[4] Paolo Bellavista, Axel Kpper, and Sumi Helal. Location-based services: Back to the
future. In IEEE Pervasive Computing, volume 7 Issue 2, pages 8589, April 2008.
[5] Je Bertolucci. Mobile internet to dominate within 5 years. http://www.pcworld.com/
article/184876/mobile_internet_to_dominate_within_5_years_study.html, December 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 8190. ACM Press, 2005.
[7] Goran M. Djuknic and Robert E. Richton. Geolocation and assisted gps. Computer,
34:123125, 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:7381, 2003.
[10] Georg Groh and Christian Hillebr. Lbcslocation based community services: Proactive
lbs services for mobile communities in the research project cosmos. Technical report,
Technical University of Munich, 2004.
[11] Compete
Inc.
ter climbs.
Social
networks:
Facebook
takes
over
top
spot,
twit-
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 Kpper. Location-based Service Fundamentals and Operation. John Wiley and
Sons Ltd, 2005.
[16] Natalia Marmasse and Chris Schmandt. Location-aware information delivery with commotion. In HUC 2000, pages 157171. 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 ICDM10:
10th IEEE International Conference on Data Mining, pages 1417, 2010.
[20] Needleman Rafe, Claire Cane Miller, and Adrianne Jeries. 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 eects of
displaying uncertainty in context-aware applications. In 6th International Conference
on Ubiquitous Computing (ubicomp 2004), pages 5469, 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 232250. 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.
ging.
tweet your location from twitter next move in location-based blog-
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-ndings.aspx, November 2010.
56
Appendix A
Appendix
Start Positioning using GPS, Network Provider and Dead
Reckoning
Listing A.1: Method used to start positioning
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
\\ start locating location

public boolean startLocating ( ) {
timer = new Timer ( ) ;
// g e t l a s t l o c a t i o n a f t e r 5 s
timer . schedule ( new TimerTask ( ) {
public void run ( ) {
if ( locationManager . isProviderEnabled ( LocationManager . GPS_PROVIDER ) == true ) {
lastLocationGPS = locationManager . getLastKnownLocation ( LocationManager . GPS_PROVIDER ) ;
if ( lastLocationGPS != null ) {
// o n l y a c c e p t a c c u r a t e data
if ( isAccurate ( lastLocationGPS ) ) {
bestLocation = lastLocationGPS ;
myLocation . getLocation ( lastLocationGPS ) ;
// w a i t f o r 120 more s e c o n d s f o r gps l o c a t i o n change b e f o r e terminating
new Timer ( ) . schedule ( new TimerTask ( ) {
locationManager . removeUpdates ( locationListenerGPS ) ;
}
} , 120000) ;
// w a i t f o r 30 s f o r nw l o c a t i o n change b e f o r e t e r m i n a t i n g
locationManager . removeUpdates ( locationListenerNW ) ;
}
} , 30000) ;
}
}
57
28
29
}
if ( locationManager . isProviderEnabled ( LocationManager . NETWORK_PROVIDER ) == true ) {
lastLocationNW = locationManager . getLastKnownLocation ( LocationManager . NETWORK_PROVIDER ) ;
if ( lastLocationNW != null ) {
// o n l y a c c e p t a c c u r a t e data
if ( isAccurate ( lastLocationNW ) ) {
bestLocation = lastLocationNW ;
myLocation . getLocation ( lastLocationNW ) ;
// w a i t f o r 120 more s e c o n d s f o r gps l o c a t i o n change
// TODO Autog e n e r a t e d method s t u b
}
} , 120000) ;
// w a i t f o r 30 s f o r nw l o c a t i o n change
// TODO Autog e n e r a t e d method s t u b
}
} , 30000) ;
}
}
}
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
}
} , 5000) ;
boolean gps = false ;
boolean network = false ;
try {
gps = locationManager . isProviderEnabled ( LocationManager . GPS_PROVIDER ) ;
network = locationManager . isProviderEnabled ( LocationManager . NETWORK_PROVIDER ) ;
}
catch ( Exception e ) {}
if ( gps == false && network == false ) {
return false ;
}
else {
locationManager . requestLocationUpdates ( LocationManager . GPS_PROVIDER , minUpdateTime , 0 , locationListenerGPS ) ;
locationManager . requestLocationUpdates ( LocationManager . NETWORK_PROVIDER , minUpdateTime , 0 , locationListenerNW ) ;
return true ;
}
60
61
62
63
64
65
66
67
68
69
70
58
Timing of GPS and Network Provider

Listing A.2: Timing of GPS and Network Provider
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
locationListenerGPS = new LocationListener ( ) {

// g e t new l o c a t i o n
public void onLocationChanged ( Location location ) {
if ( isAccurate ( location ) ) {
// t h i s i s b e s t l o c a t i o n
bestLocation = location ;
// remove g e t l a s t l o c a t i o n t i m e r t a s k
if ( timer != null )
timer . cancel ( ) ;
// send new l o c a t i o n t o a c t i v i t y and t e r m i n a t e a l l r e q u e s t f o r l o c a t i o n change
myLocation . getLocation ( location ) ;
}
}
};
locationListenerNW = new LocationListener ( ) {
public void onLocationChanged ( Location location ) {
if ( isAccurate ( location ) ) {
// t h i s i s b e s t l o c a t i o n
bestLocation = location ;
// remove g e t l a s t l o c a t i o n t i m e r t a s k
if ( timer != null )
timer . cancel ( ) ;
// send new l o c a t i o n t o a c t i v i t y and t e r m i n a t e NW r e q u e s t f o r l o c a t i o n change
myLocation . getLocation ( location ) ;
// s t i l l w a i t 60 s e c o n d s f o r GPS l i s t e n e r
}
} , 60000) ;
}
}
};
59
Evaluating Accuracy of New Location

Listing A.3: Method used to compare the accuracy of new location data with current best
known location
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
private boolean isAccurate ( Location l ) {

// do not a c c e p t t o o o l d l o c a t i o n , o l d e r than 5 mins
long now = new Date ( ) . getTime ( ) ;
if ( l . getTime ( ) < now 1000 * 60 * 5 )
return false ;
// t h e r e i s no b e t t e r l o c a t i o n
if ( bestLocation == null )
return true ;
int providerDif = compareProvider ( l , bestLocation ) ;
// same p r o v i d e r
if ( providerDif == 0 ) {
long timeDif = l . getTime ( ) bestLocation . getTime ( ) ;
boolean isNewer = timeDif > 0 ;
boolean isMuchNewer = timeDif > 1 2 0 0 0 ;
boolean isMuchOlder = timeDif < 12000;
// t h i s l o c a t i o n i s 2 minutes newer than b e s t l o c a t i o n
if ( isMuchNewer )
return true ;
// t h i s l o c a t i o n i s 2 minutes o l d e r than b e s t l o c a t i o n
else if ( isMuchOlder )
return false ;
// between time gap
else {
float accuracyDif = l . getAccuracy ( ) bestLocation . getAccuracy ( ) ;
boolean isMoreAccurate = accuracyDif < 0 ;
boolean isLessAccurate = accuracyDif > 0 ;
boolean isNotAccurate = accuracyDif > 2 0 ;
// more a c c u r a t e r e s u l t
if ( isMoreAccurate )
return true ;
// same a c c u r a t e but newer i n f o
else if ( isNewer && ! isLessAccurate )
return true ;
// l e s s a c c u r a t e but newer i n f o and from GPS
else if ( isNewer && ! isNotAccurate && l . getProvider ( ) . equals ( LocationManager . GPS_PROVIDER ) )
return true ;
else
return false ;
}
}
// from weaker p r o v i d e r
else if ( providerDif == 1){
// l a r g e r time d i f
60
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

boolean isMuchNewer = timeDif > 6 0 0 0 0 ;
// much newer i n f o
if ( isMuchNewer )
return true ;
// newer i n f o
else if ( isNewer ) {
boolean isVeryAccurate = accuracyDif < 2 0 ;
// much more a c c u r a t e
if ( isVeryAccurate )
return true ;
else
return false ;
}
// not newer i n f o
else
return false ;
}
// from b e t t e r p r o v i d e r
else {
// newer i n f o
if ( isNewer )
return true ;
// o l d e r i n f o
else {
boolean isNotAccurate = accuracyDif > 2 0 ;
// not t o o bad a c c u r a c y
if ( ! isNotAccurate )
return true ;
else
return false ;
}
}
}
61

Proactive Event Reminder With Location Based Service

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Proactive Event Reminder With Location Based Service

Enviado por

Direitos autorais:

Formatos disponíveis

rSystem: A Location-based Event Service

with Proactive Notication

Copyright2010 Ngo Minh Quan

Abstract of Bachelors Thesis

Ngo Minh Quan

2 Background: The Prospect of Location-based in SNS

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

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

Denition and Classcation of LBS . . . . . . . . . . . . . . . . . . .

Emergence of LBS in Social Networking . . . . . . . . . . . . . . . .

3 Problem, Motivation and Related Works

Current Problems of LBS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

Users Concern for Privacy . . . . . . . . . . . . . . . . . . . . . . . .

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

4 rSystem, A Location-based Event Service with Proactive Notication

rSystem, A Location-based Event Service with Proactive Notication . . . .

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

rNotify, A Proactive Location-based Notication . . . . . . . . . . .

Implementation on Micro Blogging Twitter

Privacy and Security . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Design and Implementation of rSystem

Data Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Server Functional Module . . . . . . . . . . . . . . . . . . . . . . . .

Client Functional Module . . . . . . . . . . . . . . . . . . . . . . . .

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

Quantitative Evaluation of Positioning method

Method and Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .

Result and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .

Qualitative Evaluation of rSystem . . . . . . . . . . . . . . . . . . . . . . . .

Method and Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .

Result and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Conclusion and Future Work

Comparison between Reactive and Proactive Service . . . . . . . . . . . . .

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

Specication of Servers Implementation . . . . . . . . . . . . . . . . . . . .

Detailed Specication of Device used for Evaluating . . . . . . . . . . . . . .

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

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

Result of rEvent Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .

Result of rNotify Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Combination of 3 Positioning Methods . . . . . . . . . . . . . . . . . . . . .

Map service on many platforms . . . . . . . . . . . . . . . . . . . . . . . . .

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

Data Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Displaying Items on rClient . . . . . . . . . . . . . . . . . . . . . . . . . . .

Input location by touch interaction . . . . . . . . . . . . . . . . . . . . . . .

Users Concern for Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Structure of Thesis

2.2 Current Trends and Future Possibilities of SNS

2.3 Location-based, An Emerging Trend in Social Networking

Table 2.1: Comparison between Reactive and Proactive Service

2.3.2 Emergence of LBS in Social Networking

2.3.3 Geosocial Networking

3.2 Current Problems of LBS

Secondly, cross-referencing is necessary because its important to distinguish between

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

3.2.3 Users Concern for Privacy

3.2.4 Motivation on Introducing a Proactive Event Service

3.3 Related Works