Our project is to develop an Android application, which develop social network among its users based on the users real life social activity, such as meetings, voice calls, and text messages. The motivation of our application comes from Facebook which is the most popular social network website. As an Android application, it’s developed based on client and server structure. The client side is run on Android cell phones, and the server side is run on computers. The server collects the data of the user’s voice call history, text message record as well as meeting information from the client side to build the real life social network. And we have a standard for evaluation for every user based on his social activity.The topology of our application is in Fig. 1.

The overview diagram of our application is shown in Fig 2.

• On the client side:

  1. If it is the first time for a client to use our AZA application, he has to registration to our server. If the user name has never been signed up, it will successfully open our application. While an old user returns to our AZA, he has to sign in with the correct user name and password before playing with AZA.

  2. After successfully login, the app will submit all the voice call and text message history since last time of login automatically to the server.

  3. To detect the meeting information, we implement Bump API. If two friends meet with each other, they bump the phone together. And the Bump server will return the match status of these two phones. If they match with each other, the user with a less user ID should send a message to our server about the IDs of the two friends and the timestamp.

  4. To keep checking if the meeting is still going on, we use GPS location information. If the distance between the users is more than 50 meters over 10 seconds, or either of the users wants to disconnect, the app assume that the meeting is over and send the ending timestamp to the server.

  5. The user can check for friend lists, which show the list of top five closest friends and the list of five most popular persons among the network.

  The main component of client side is shown in Fig 3.

  

• On the server side:

  1. The server manages a database and maintains two tables, User Table and Relation Table.

  2. The server is multithread, and it can handle requests from multiple users.

  3. If the type of the request from the user is sign in/up, the server looks up the User Table and decides whether to allow the user login.

  4. The server receives the voice call and text msg history whenever the user successfully login. It updates the Relation Table according to the newly information of the user’s social activity.

  5. If the server receives the msg about a meeting, it will keeps the two client ID and timestamp of meeting beginning as well as over, and update the meeting item in Relation Table.

  The main component of server side is shown in Fig 4.

  

• Matlab analysis:

  To analysis the established social network, we use all the data that our server collected. After the social activity standard of evaluation, the server calculates the point between every two users. According to all the points, we use Matlab to simulate a network graphic to make it visible to see how active a user is in his real social life.

• Clients
1. AZAClientActivity

   This activity is the main activity of the application. The function of the activity is simple and only to show the title of application. There is a Start button in this activity. After clicking this button, the application will jump to Sign In activity.

2. SignInActivity

   The application requires its users to apply for a user name and password. In this activity, users can enter their user name and password to sign in. Besides sending sign in information to server through socket, this activity also implements the validation of input content. There is three buttons in this activity, they are Sign in (Submit), Sign up (jump to sign up activity) and back. Another important function of this activity is to update the communication history of the user.

3. SignUpActivity

   When the signup button in signin activity is clicked, the application will jump to signup activity. In sign up activity, users need to enter a new user name, password. Their phone number will be fetched automatically. If the fetch fails, user will need to enter their phone number manually. A validation will be applied before the information submitted to the server.

   

4. BumpActivity

   By implemented the Bump API, it allows us to match two users when they bump their phone together which is the process to detect a conversation between friends. To implement the Bump API, we firstly initialize the API with the function configure(user ID, Bump API key). Whenever the phone bumps, the API will return with the information with BumpAPIIntents.MATCHED or BumpAPIIntents. NOT_MATCHED, so we use unmatched information to detect if the Bump API works fine.

   If the users match with each other, they can send msg to each other. And we send msg to our server with the msg format of Meeting#myID#yourID#timestamp#. And the server will return an unique meeting ID assigned to this meeting.

   Then we detect the if the msg is still going on by GPS location information. By implement a timer, we check the distance between the two user every 3 seconds. If the distance is over 50 meters for more than 10 seconds, we assume that the meeting is over. Or if either of the user wants to over the meeting manually, we also send msg to the server with the msg format of Apart#meetID#timestamp#.

   After the meeting is over, the application will return to the status to wait for a new bump activity.

   

5. FriendListActivity

   The function of this activity is to show the best friends of users and the most popular users of the application. When the activity starts, it sends a request to the server. The server will fetch the sorted data and send it back to the client. At last, the client displays the ranking.

   

6. ClientSocket

   In this file, we have the ClientSocket class which includes socket connect functions and the protocol defined to communicate with server and client. To establish a socket with server, there are 4 functions:

   1. public void InitializeClient();
   2. public void SendMessage(String fromClient);
   3. public boolean ReceiveMessage();
   4. public void closeSocket();

   And the message format is as following:

   1. Sign up msg: Sighup#username#password;
   2. Sign in msg: Signin#username#password;
   3. Meeting beginning msg: Meeting#myID#yourID#timestamp;
   4. Meeting apart msg: Apart#meetID#timestamp;
   5. Call history msg: Call#myID#timeStamp#yourPhoneNum@duration#…;
   6. Text message history msg: Msg#myID#timeStamp#yourPhoneNum#…;
• Server

  The server mainly offers the following services, sign up and sign in service, updating meeting data and retrieving data for friend list.

  For sign up. When the server receive a sign up request, it will check if the desired user name exists. If so, it will reply a fail message “SignUp#Fail#”. Otherwise, it will connect to database and insert the new user name with its password and phone number. And then a message “SignUp#<user id>#” will be sent by the server to the new user.

  For sign in. The user will send a message with its user name and password “SignIn#<user name>#<password>#”. After receiving the message, the server will check the existence of the user name and the correctness of it s password. If no error happens, it will reply a message “SignIn#<user id>#” to client. Otherwise, a message “SignIn#Fail#” will be sent to client. If the user successfully signs in, it will then send it call and message record to the server. The server will detect the existing user by phone number, if the existing users have relation with the user who sent the records. Their communication record will be updated.

  For updating meeting data. When two users successfully bump each other, one of them will send “Meet#<user1 id>#<user2 id>#<start time>#”. After receiving this message, the server will retrieve the relation between these tow users and returns message “Meet#<relation id>#” to the client. When these two users end their meeting, a message “Apart#<relation id>#<end time>#” will be sent to the server. The serve will compute the meeting time according to start time and end time and update meeting time data in database.

  For friend list retrieving. The user will send a message “Friendlist#<user id>#” to server, the server will retrieve the top 5 best friends of the user by using this score computing formula “Duration/60+Msg+MeetTime/30”. Also the most popular users, who have most connection among all users, will be found. The best friend and most popular users will be sent back to users by the formatted message “Friendlist#<best friends>#<most popular users>#”.

• MySQL Database

  There are two tables in our database, users table and relations table. In users table, there are four columns, UID, User name, Password and PhoneNumber. In relations table, there are six columns, RID, UID1, UID2, Duration, MsgNum and PhoneNumber. The design of the database follows the database normal forms. So that, there is no column for the score which can be computed by the Duration, Msg Num and PhoneNumber from this formula “Duration/60+Msg+MeetTime/30”. The database is managed by the server through JDBC. And the two tables in database is shown in Fig. 8.

  

• MATLAB Processing

  After the calculation of point between every two users, we have the table of point according to the users social activity like Fig.9. In Fig. 10 we use MATLAB to analysis the established network. Using the size of the red dot to represent how active the user is in the real social network, we can tell some interesting phenomenon from the graphic. Take user 6 for example, the user is really popular connected with most of people inside the network and has three close friends. On the contrary, user 9 is maybe a lonely boy, he seldom involved in any social life. And although user 4 only know two people in the network, but they are good friends which means that maybe user 4 is a little shy to make new friends to extend his network.

  

  

Please download the sourcecode.zip in the folder of files!

The github link of sourcecode.zip: https://github.com/EE579Group5/AZA

Please download the overview_presentation.pdf, midterm_presentation.pdf and final_presentation in the folder of files to see our presentation.

• How to deduce the workload of the server?

  The server is multithread process, and it has to handle multiple requests from clients. To deduce the workload of the server, we use the following two ways:

  1. By implemented Bump API, it allows to send msg between each other. To avoid the calculation work of the server, we let the client side to exchange location information and calculate the distance, then decide whether the meeting is still going.
  2. To deduce the client request to the server, only the client with the smaller ID will send the meeting and apart information to the server. By this way, the server can deduce half thread running.

• Meeting issue: what will happen if the WiFi does not work during a meeting?

  If a meeting has begin, and the client side has send the meeting beginning msg to the server, then the phone could not connect the WiFi, the server could not close this socket connection and calculate the time duration of this meeting. To solve this problem, we send confirm msg every minute to keep contact with the server. As a result, if the server does not receive the confirm msg for more than five minutes, the server will assume that the meeting has over and update the meeting duration.

• Meeting issue: what will happen if the GPS does not work indoors?

  Sometime GPS does not work indoors. In this scenario, we use Bump API to detect if the meeting is still going on. By Bump API, we keep sending msg to each other every one minute. If the client receives the other’s msg, then assume the meeting is still going on and keeps check. If the client does not receive the data for more than three minutes, it assumes that the meeting is over. And the client with the smaller ID sends apart msg to server.

• Application evaluation.

  The AZA application establishes a social network among all the users throng collecting the data of real social life activity. The users also can communicate with their friends and check the friend lists. Besides, the UI of our AZA application is friendly. But because of the restriction of Bump API, we only could allow two users to bump together and match with each other. In the further, we want to extend the functionality for multiple user bump together and begin a conversation.

• Jingwei Liu
  • Implement Bump API and meeting scenario function, and test case for meeting scenario.
  • Implement socket and design the communication protocol between the server and client.
  • Matlab statistic simulation
  • Final report
• Chong Luo
  • Server side implementation
  • Database manipulation
  • UI implementation
  • Final report
• Wenying Li
  • Friend list and related database
  • Call/msg information extraction
  • UI implementationn
  • Presentation ppt

Email address:

Jingwei Liu:jingwei@usc.edu

Chong Luo:chongluo@usc.edu

Wenying Li:wenyingl@usc.edu