Location Based
Dating Service
Arun Ponnusamy
Abhisheak Iyer
Deepak
Swathi Gangisetty
Location Based Dating Service
Index
Introduction ..................................................................................................................... 2
Motivation ......................................................................................................................... 3
Background ..................................................................................................................... 4
Architecture ..................................................................................................................... 5
Implementation............................................................................................................... 6
Registration Module.................................................................................................................... 6
Database Implementation............................................................................................................ 7
Querying ...................................................................................................................................... 8
Chat Client ................................................................................................................................ 12
Implementation Issues............................................................................................................... 13
The Learning Curve ..................................................................................................... 14
Conclusion and Future Work ................................................................................... 15
References ..................................................................................................................... 16
1
Location Based Dating Service
Introduction
The aim of this project is to develop a mobile location based dating service to
which the users can subscribe to find and meet prospective dates in a given region. The
user can log onto the service through the mobile phone and the user will be shown a list
of all available users within a specified proximity range to a public location. This project
gathers location details from the GPS and leverages Google Maps API to perform location
based analysis. This project uses Google's Android as the underlying Mobile Platform for
Application Development. The users will have to register their mobile phone number and
create a profile online displaying their details and indicating their interests and
preferences. Once the user logs into the Mobile Location-Based Dating Service through
the mobile, the users’ location details are captured and updated in the database. Now the
user can look up others using this service within a specified proximity range to a public
location. The user can contact a prospective Date and negotiate the appointment through
text chat or by calling. The caller's mobile number could be obfuscated if necessary based
on his/ her privacy settings. The users’ locations would be updated periodically. This
project also addresses some of the privacy issues like optional mobile number
obfuscation, disclosure of only the range proximity to a public location and not the actual
location coordinates to others users.
2
Location Based Dating Service
Motivation
We embarked upon this project due to the growing interest in the academic community
and the industry in the field of Location based services. As the world turns towards Web 2.0 and
with Mobile phones becoming all pervasive, Location Based Services has emerged as the next big
thing and Telecom and GPS companies are already competing for their market share in this
lucrative industry.
This graduate level course on “Advanced Internet Application Development” provided us
with an opportunity to explore this emerging field and to develop a prototype implementation of a
Location based service on the soon to be commercially released platform, The Android, developed
by Google, Inc. This location based service would enable two people to discover each other
through the Google maps interface by actual positioning using the GPS system of the mobile
phone.
While there are indeed several current implementations of online and mobile dating
services, most of them require you to register online or would promise to match your profile based
on your preference and send you alerts to your inbox or SMS inbox when a profile match occurs.
Our primary motive was to develop stand-alone software to be installed on the mobile phone and to
be used as an instant dating tool where the user can choose to date people by discovering profiles
by themselves rather than allowing a third party service provider to match profiles and send alerts.
There are several advantages to develop and deploy stand alone dating software and are
discussed in detail in the later sections of this report. Yet another motivation has been the Android
developer
Challenge
posed
by
the
Open
handset
alliance
(http://code.google.com/android/index.html). This would be a great platform for us to present our
application and further the scope of this project.
3
Location Based Dating Service
Background
In this section we present our study of various contemporary implementations of location
based dating services and buddy finders. This study also provided the learning curve that was
crucial behind the successful implementation of our project.
Meetmoi is currently one of the most popular and widely used location based dating
service that requires subscribers to create an online profile and does a profile matching of users
based on their criteria and returns profiles back to the users through SMS.
While it does indeed track people by using the Zip code of a specific user which they enter
while creating a profile, it is not location based in the true sense. It does not use GPS for location
positioning of the user. Besides we explored and studied a lot of security flaws and privacy
violations that the user must agree to for using this service. In fact it is these limitations that have
restricted the popularity of LBS services. Meetmoi was to us an example of not what a location
based service should be, but instead what a location based service should not be. It also had a
feature through which it would alert the user by continuously sending SMS whenever a profile
match occurs. This can be quite annoying if a user does not want his inbox to be flooded or if he is
not in the mood to date or receive profiles. To deactivate this feature one had to go online to
change his preferences.
This majorly influenced our decision to develop a system which does not match profiles
based on textual data. But instead to provide the profiles to the users on a map interface and let
the user decide how many profiles or whom he/she wants to see to contact.
We have also done a good deal of study on other contemporary services such as the
Dodgeball and Meetro and have comp up with similar results. The impact of this study greatly
influenced the way we wanted to design this dating software.
4
Location Based Dating Service
Architecture
Our System architecture is closely modeled based on the three tier system. The front end
software is deployed on the Google Android Mobile. The front end software which interacts with the
user is developed using Java and the Android Toolkit. This interacts with a database which is a
MySQL database. In reality this would be modeled as the external database of the service provider
providing this service. The database also interfaces with the GPS system of the mobile phone to
continuously update the location information of the user who are currently using this service.
The following high-level diagram best summarizes our system design.
5
Location Based Dating Service
Implementation
This section deals with the implementation details of the above described system. We
have described the following use case diagram to represent the flow of control in the software.
Use case diagram
Registration Module
This is the first step any user would have to do on logging into the software. This is when
the user creates a user name and password and also sets their preferences such as the kind of
information they wish to reveal to others and contact preferences.
At the current level of implementation we have just included a limited profile of name, age,
sex . But in future we would work to include a picture profile and possibly to import data from social
networking sites to make profile creation easy and simple. Once the use registers he/she is allotted
a primary key in the database and their current location details are updated by retrieving the
6
Location Based Dating Service
latitude and longitude information from the GPS system and updating the corresponding record for
that user.
Snapshot of the Login Screen
Database Implementation
In order to provide the necessary support for user information and to store and update user
activity, the application relies on MySQL - an Open Source Relational Database. The database
schema comprises of three major tables that store and manipulate data specific to each user such
as his profile information, location specifics details and a list of ignored users. The table handling
user profiles has columns that cater to the personal details of the users who are registered to the
application, such as user name, password, first name, last name, age, and sex and e-mail id. Since
the user name is unique to each profile, it is chose and the primary key for the table. Location
specific details of the user are stored in another table that has user name, latitude and longitude
coordinates of the user and, availability of the user as the entries in the table. As this table has to
be mapped to the user profile information during run time, the user name is unanimously chosen to
be the foreign key. Another table, for containing the ignored lists of each user, has two columns;
obviously one column holds the user name of the user and the second column has an list of
ignored users represented by their user names and delimited by a special character.
The schema of each table is highlighted below
User_Profile
7
Location Based Dating Service
user_name pwd
(varchar)
(varchar)
first_name
(varchar)
last_name
(varchar)
age
(int)
sex
(varchar)
values = 'M' or 'F'
email
(varchar)
Primary key
User_location
uname
(varchar)
latitude
(float)
longitude available
(float)
(varchar)
values = 'Y' or 'N'
Foreign key
User_ignore List
uname
(varchar)
ilist
(varchar)
Foreign key
Querying
In alignment with the proposal, the application realizes the back end and front end
connection by leveraging JDBC technology to communicate with the MySQL database, since a
majority of the development activity is programming in Java. Based on the performance of JDBC in
transmitting and executing the queries over the phone and also by conducting trial runs, we quickly
realized that the overhead was exceeding the limiting factor. In order to overcome the problem, we
went ahead with the lightweight solution – sockets. The model we adopted was simple yet
effective. To process a query, the database was connected to a TCP socket and the requisite
parameters were passed from the Android application. These queries were executed at the server
and the results were communicated to the application. We had further improvised the system by
multithreading the server so as to aid connections from multiple clients. A separate socket
connection is used for each type of query. To support this we built three servers that listen for the
parameters from clients and spawn a JDBC connection to execute to query inside the thread.
A list of the queries used in the application is given below
8
Location Based Dating Service
Login Check:
This query is used in the Login Page
Parameters from Client: User=<Username>, Password=<pwd>
Result from Server: Success or Failure
s = con.prepareStatement ("Select Pwd From user_profile where user_name=?");
s.setString (1, User);
After executing this query, the system verifies if the returned password is same as the one the user
entered.
Registration:
This query is used in the Registration Page
Parameters from Client: User=<Username>, Password=<pwd>, Email=<email>, Age=<age>,
Sex=<sex>, FirstName=<fname>, LastName=<lname>
Result from Server: Success or Failure
s = con.prepareStatement ("Insert into user_profile (user_name, pwd, firstname, lastname, age,
sex, email) VALUES ()");
s.setString (1, User);
s.setString (2, Password);
s.setString (3, FirstName);
s.setString (4, LastName);
s.setInt (5, Age);
s.setString (6, Sex);
s.setString (7, Email);
List of Users who meet the users preference criteria:
This query is used in the preference page.
Parameterss from Client: User=<Username>, Gender=<sex>, ageL=<age_lower_limit>,
ageH=<age_higher_limit>, Prox=<With in a required proximity range in miles>
Result from Server: List of Records Delimited as - Record1$$Record2$$...where any RecordN is
<usr>##<lati>##<longi>##<fn>##<ln>##<ag>##<em>
s = con.prepareStatement ("SELECT u.user_name UN,u.firstname FN,u.lastname LN,u.age
A,l.latitude LAT,l.longitude LON,u.email EM FROM user_profile u, user_location l where
u.user_name=l.uname and l.available=? and u.sex=? and u.age >= ? and u.age <= ?");
9
Location Based Dating Service
s.setString (1, "Y");
s.setString (2, Gender);
s.setInt (3, ageLow);
s.setInt (4, ageHigh);
And for each of the records, the result is filtered by performing a distance calculation:
private double distance (double lat1, double lon1, double lat2, double lon2) {
double theta = lon1 - lon2;
double dist = Math.sin(deg2rad(lat1))*math.sin(deg2rad(lat2)) + Math.cos(deg2rad (lat1)) *
Math.cos(deg2rad(lat2)) * Math.cos(deg2rad(theta));
dist = Math.acos(dist);
dist = rad2deg(dist);
dist = dist * 60 * 1.1515;
return (dist);
}
After the results are returned to the Android Client, the fields are parsed and stored in
static variables. These fields used by the maps API to plot the users on the map that is displayed to
the user.
Location Simulation: We had tried using the mock GPS provider but the locations shown
were random and unfit for our simulation. While working with the database location was hard coded
as lat= 33.7759 and long = -84.3927. Later, during execution of the code, the location details are
changed at the DB manually to get the good demo scenario for proximity as it could be set to the
regions we want to show.
The logical flow of control is depicted below:
First screen: Login Page
1. Login as a registered user or register as a new user
2. If (Registered User)
Redirect to preference page
10
Location Based Dating Service
3. If (New User) { Redirect to registration page after successful registration, redirect to preference
page. }After preference page, show the users on the maps
11
Location Based Dating Service
Chat Client
As and when a user finds a profile on the map that interests him, there is an option to
initiate a chat session. This is quite an exciting feature of our application. With text messaging
being charged for in the USA, and users too not willing to let their personal information, the chat
features tends becomes instantly popular with the users. The simplicity of this interactive feature is
that it simply runs inside the application as long as the application is active and does not need any
direct support from the service provider of the cell phone. Moreover, it is not linked to the message
inbox of the user and thus promotes total privacy.
This interactive chat application embedded into the system is based on the Extensible
Message and Presence Protocol (XMPP). XMPP is an open XML technology for presence and real
time communications. It was developed by the Jabber open source community in 1999, formalized
by IETF in 2004 and continuously extended through the standards process of XMPP standards
foundation. Jabber is a decentralized network of Instant Messaging services. It offers privacy
against monitoring of messages by letting the users create an independently owned IM service. We
have used Smack chat client API to provide the utility functions that enabling interactive chat
sessions. Smack is an Open Source XMPP (Jabber) client library for instant messaging and
presence. It is a pure Java library that can be embedded into an application to create anything from
a full XMPP client to simple XMPP integrations such as sending notification messages and
presence-enabling devices. We had considered Smack as an option because of several
advantages that it offers
• While preserving simplicity, Smack provides a powerful API. Sending a chat message can be
accomplished with a few lines of code.
• Smack distinguishes itself from other libraries by refraining from forcing the developer to code at
packet level. Instead it provides intelligent higher level constructs such as Chat and Roster
classes which let the developer program more efficiently.
• It provides easy machine to machine communication by giving the developer a free reign in the
number of properties on each message, including properties that are Java objects.
• Developing using Smack API does not essentially need the developer to be familiar with XMPP
standards
A snippet of code to send a text message, taken from the application, looks like this
XMPPConnection connection = new XMPPConnection("jabber.org");
connection.connect( );
connection.login("arun", "password");
Chat chat = connection.getChatManager( ).createChat("cs@gatech.edu", new MessageListener()
{
public void processMessage(Chat chat, Message message)
{
System.out.println("Received message: " + message); }});
chat.sendMessage("Howdy!");
12
Location Based Dating Service
Implementation Issues
Given that this was our first project on the Android platform, it was quite a challenging task
to even set up the development environment and to keep up with the continuous incremental
versions of the Android SDK.
Besides, because of the fact that the platform is very recent, we did not have a big
developer support such as the ones. Though big developer forums do exist, we did not enjoy the
same support that we might have got had we worked on a Symbian platform. Of course we do
anticipate a huge expansion in developer activity in the coming months, but it was tiresome
troubleshooting certain issues by self.
Another major aspect was interfacing the emulator with the external MySQL database and
implementing the sockets for connectivity.
Yet another major drawback that we faced with the Android is the extremely limited version of the
Google Maps API that is provided as a package within the SDK.
Besides a few functions such as creating a Map layout and basic functionalities , the SDK
lacked more important features such as placing a marker , displaying a pop up and so on. We had
to devise a work around in a less sophisticated manner but we achieved the same functionality.
And finally we did face the classical problem of integrating the modules that the four of us
had coded separately. While we did have a decent amount of knowledge exchange during the
development process to keep each other informed about what the other was doing, it was a
daunting task to integrate the mutually independent pieces of code
13
Location Based Dating Service
The Learning Curve
Despite the successful outcome of the project presentation and the project demonstration,
we had a lot to gain as far as the learning that went into the whole course of the project. It was a
great experience to be able to bridge the classroom lectures on Location based services and
mobile computing into the ideas that shaped our project. The lecture and readings on LBS in
Mobile information systems provided the necessary understanding and knowledge that was very
crucial for this project.
Though we did learn a lot about the privacy aspects of a LBS application, we haven’t
focused our efforts into the subscriber security and privacy aspects. Instead we utilized the
freedom and opportunity provided by the course to design a dating service that we felt was shifting
the control of the dating experience from the service provider to the subscriber. In short we wanted
to develop a software that would give the user the complete control of the dating experience.
Besides we also found ourselves at an advantage by the timing of the course and project
schedule. The LBS lectures that initiated our project idea and subsequently the proposal were
delivered by the instructor in the first few weeks of the class. Another factor that worked to our
advantage was the Google Android challenge which coincided exactly with the course schedule.
The competition begun just when the course begun and ended a week early to the end of the
course.
14
Location Based Dating Service
Conclusion and Future Work
To conclude, we’re excited to have completed this project successfully within the given
time frame for this project. At the same time we also regret the fact that we could have included
more interesting features had we had more time.
We had a lot of ideas which are yet to be incorporated into this application. The most
important of them was the idea of a revenue model by which could feature advertisements when
we match two people to a common landmark on the Google maps interface. For instance if two
people decide to meet and are browsing simultaneously to choose a landmark on the map , we
could feature local advertisement of a shop or a restaurant that gives name or price of the special
item on the menu for any particular day or time. We could devise a means for vendors to publish
such information that the users can use to decide on where to meet. This would not only enrich the
dating experience, but also promote the business of the landmarks overlayed on the maps.
Another way of promoting ads would be to maintain a wish list or favorite list in the profile
that the user can edit or change any time. Based on this information we could suggest the user a
particular shop where an item that the person whom he/she is just about to date, is available. This
would dramatically improve the social experience of the user and at the same time provide a
commercial avenue for the service provider/host to publish ads of shops/restaurants.
Another idea would be to let people rate landmarks depending on their dating experience
at that particular location. If a fool proof mechanism can be implemented so that vendors
themselves don’t subscribe and increase their ratings, it would be a great way for people to decide
on a location in a wise manner.
We’re very happy at the level of productivity and creativity we were able to put into this
project and hopefully we’d be able to extend this system in a future point in time.
15
Location Based Dating Service
References
[1]
[2]
[3]
[4]
[5]
Google Android, http://code.google.com/android/
XMPP Standards Foundation, http://www.xmpp.org/
Smack API, http://www.igniterealtime.org/projects/smack/
Jabber Open Source Community, http://www.jabber.org/
Location Based Services, IBM Developer Works
http://www.ibm.com/developerworks/ibm/library/i-lbs/
[6] MySQL, http://www.mysql.com/
16