FYP_12130648_FriendNav

Final Year Project 2016 1

FriendNav – An Android Social App

- Final Year Project 2016 -

Daniel O’Neill

UL Undergraduate Student ID: 12130648

LM118 – B.Eng. Electronic and Computer Engineering

4th Year.

Supervisor:

Dr. Máirtín Ó Droma

Electronic and Computer Engineering Dept.,

University of Limerick,

Ireland.

Date: 29th March 2016


Abstract

Social media in recent years has made people less social, in a real face to face context.

People’s personal information can be found all over the internet and there is a chance that you

may know a huge amount about somebody just through their social accounts. The following

document describes the design and implementation processes of a final year project based on

an Android application named “FriendNav”. FriendNav is a social media application. It was

inspired by the lack of real socialising in the world of social media applications. FriendNav in

terms of design has been keeping the theme of simplicity and its purpose is to be a gateway

for friends to meet up with each other face-to-face. FriendNav is not set out to re-invent the

wheel – The application however does intend to spin it a little differently.


Table of Figures

Figure Content

1 Strawpoll result showing most popular smartphone operating system [1].

2 Online result of smartphone market share [2].

3 Android Studio Logo.

4 Popularity of smartphone applications per type [3].

5 Instagram Font.

6 Tinder’s Bright Colour Theme

7 Instagram’s Navigation Menu.

8 Server – Client Communication [4].

9 Android Activity Implementation.

10 FriendNav Colours.

11 FriendNav Font.

12 FriendNav Font Code.

13 FriendNav Features Hierarchy.

14 FriendNav Main Activity.

15 FriendNav PostLogin Activity & Notification.

16 FriendNav Alerts Activity.

17 FriendNav Alert Exclamation.

18 FriendNav Friends Activity All Tabs.

19 FriendNav Settings Activity All Tabs.

20 FriendNav Events Activity All Tabs.

21 FriendNav Chat Activity.

22 FriendNav Maps Activity.

23 FriendNav General Data Structure.

24 FriendNav User Profile Data Structure.

25 Server Side TCP Socket Code.

26 Client Side TCP Socket Code.

27 FriendNav Live Server Log.

28 Table of Request Commands.

29 FriendNav Client getData() Method Code.

30 FriendNav Client sendData() Method Code.

31 FriendNav Activity Coding Logic.

32 FriendNav Reloading Activity Logic.

33 FriendNav Communication Diagram.

34 FriendNav Google Maps API Location Call.

35 FriendNav NetBeans Projects.

36 FriendNav Server Log Client IP.

37 FriendNav Memory and Size Usage.

38 FriendNav Server Performance Test Code.

39 FriendNav Server Performance.


Table of Contents

(1) Introduction ................................................................................................ 7

(1.1) General .................................................................................................................... 7

(1.2) Android ................................................................................................................... 7

(1.3) Application name - “FriendNav” ......................................................................... 7

(1.4) Project Outline ....................................................................................................... 8

(1.4.1) What is the aim of this project? ........................................................................ 8

(1.4.2) Is this project feasible? ....................................................................................... 8

(2) Analytical Background ............................................................................ 10

(2.1) Background Research ............................................................................................ 10

(2.2) Design Research ...................................................................................................... 13

(2.2.1) Font ................................................................................................................... 13

(2.2.2) Colour Scheme ................................................................................................. 13

(2.2.3) Ease of Navigation ........................................................................................... 14

(2.3) Implementation Research ...................................................................................... 15

(2.3.1) Client – Server ................................................................................................. 15

(2.3.1) Android Programming .................................................................................... 16

(3) Design ........................................................................................................ 17

(3.1) GUI Design ................................................................................................................. 17

(3.1.1) Logo ................................................................................................................... 17

(3.1.2) Colours .............................................................................................................. 18

(3.1.3) Font ................................................................................................................... 19

(3.2) Features Design .......................................................................................................... 20

(3.2.1) Main Activity .................................................................................................... 21

(3.2.2) PostLogin Activity ........................................................................................... 21

(3.2.3) Alerts Activity .................................................................................................. 22


(3.2.4) Friends Activity ................................................................................................ 23

(3.2.5) Settings Activity ............................................................................................... 24

(3.2.6) Events Activity ................................................................................................. 25

(3.2.7) Chat Activity .................................................................................................... 26

(3.2.8) Maps Activity ................................................................................................... 27

(3.3) Data Storage Design ............................................................................................... 28

(3.3.1) General Data Storage ...................................................................................... 28

(3.3.2) Profile Specific Data Storage .......................................................................... 29

(4) Implementation ........................................................................................ 30

(4.1) Server - Client Communication ............................................................................. 30

(4.2) Server Implementation........................................................................................... 31

(4.2.1) Server Commands List .................................................................................... 32

(4.3) Client Implementation ........................................................................................... 33

(4.3.1) Client Requesting Data ................................................................................... 33

(4.3.2) Client Sending Data ......................................................................................... 34

(4.3.3) Activities Implementation Logic .................................................................... 35

(4.3.4) Communications Diagram .............................................................................. 36

(5) Testing ....................................................................................................... 37

(5.1) Testing Environment .............................................................................................. 37

(5.2) Performance Testing ............................................................................................. 38

(5.2.1) Application Performance ................................................................................ 38

(5.2.2) Server Performance ......................................................................................... 39

(6) Results ....................................................................................................... 40

(6.1) General Results ....................................................................................................... 40

(6.2) Potential Improvements ......................................................................................... 40

(6.2.1) Result Buffering ............................................................................................... 41

(6.2.2) More Feature Options ..................................................................................... 41


(6.2.3) Optimisation ..................................................................................................... 41

(6.2.4) Client Request .................................................................................................. 42

(6.2.5) Compressing Images........................................................................................ 42

(6.2.6) Security .............................................................................................................. 42

(7) Conclusions ............................................................................................... 43

(8) References ................................................................................................. 44

(9) Acknowledgements .................................................................................. 45

(10) Poster ......................................................................................................... 46


(1) Introduction

(1.1) General

The project described in this document is for the purpose of final year examination. Initially

the project was simply titled as “Android Application”, which turned into what it is now

through some research, brainstorming and decision making. The project is both challenging

and intriguing. There is a lot of components in play that make the application work and this

document is set to explain each and every step taken to design and implement FriendNav. The

reason that this project was chosen is simply because of the popularity of Android and also

the internal workings and structure proving to be an interesting topic to research and work

with. Android is my personal platform of choice and this is another factor which contributed

to the choice of this style of final year project.

(1.2) Android

The Android OS is a platform that is currently widely used in the smartphone market.

Android holds around a fifty per-cent market share of all smartphone devices as of this

moment. This number suggests that Android is a popular platform and hence there is a huge

amount of support structure for Android development. With this in mind it makes a lot of

sense to develop an Android application as a final year project because of the scale of

Android and what can be achieved with it.

(1.3) Application name - “FriendNav”

The application name “FriendNav” was inspired the words “Friend” and “Navigation”. The

name of the application is meant to be a clear indication of what the application is supposed to

do. It is a social media application, which explains the word “Friend”, and the general theme

of the application is to promote “real” socialising. It is to promote the idea of meeting your

friends face to face. It is a navigator to your friends, hence the use of the abbreviated word

“Nav”.


(1.4) Project Outline

The project outline describes specifics of the project by answering the following questions:

• What is the aim of the project?

• Is this project feasible?

• What features are included in FriendNav?

By answering these questions the project becomes more clearly defined in its scope.

(1.4.1) What is the aim of this project?

The aim of this project is to design and develop an Android platform, social media style

application. That takes example from but does not try to mimic the mainstream social media

that is available today. With FriendNav there is more emphasis on face to face interaction and

hence it is a tool to be used to meet up with your friends.

The standard of the project is to rival current social media in terms of design,

implementation to the best level possible. It is unrealistic to think that the end result will be

capable of overtaking any of the mainstream applications, however the goal is to get as close

to that point as possible while taking into consideration the constraints that are in place. This

project has many limitations so the goal is to keep the project simple and working, rather than

complex and unfinished in the end.

(1.4.2) Is this project feasible?

The feasibility of the project is dependent on how many features are to be included when

implementing this style of application. The framework of the project itself is a big task and

hence the features that are included are down to the amount of time that is available to

develop them. This project aims to be simple yet working, so the features that are included are

the ones that are realistic to achieve.


(1.4.3) What features are included in FriendNav?

FriendNav in its early stages was very ambitious in the features it was due to have. The

original design plans and feature list included things that were unrealistic to try and

implement in such a limited amount of time and resource. The following list, which is a list

that has been looked at more vigorously is a better and more realistic goal to achieve,

considering the scale of this project and knowledge base required for this project.

• Map View - This feature would be considered the main application selling point. It is

intended to allow users who are “visible” on Map View to be shown on a Google Map inside

the application. This allows a user to launch Map View at any location and check to see if any

of their friends are nearby.

• Chat module - To complement the Map View feature a chat module is another feature that

the application will have. It is essential to be able to arrange with someone in real time where

to meet up and other details.

• Events module – The ability to create events and to have them visible to your friends is

directly associated with meeting up with people. Cutting out the invitation list was a strategic

move to force a user to write to the person they wish to attend this event. Following the theme

of face to face interaction this feature is a very basic but effective one.

These three main features are the basic concept of the application. They all follow the same

theme of letting people meet up. As well as these features there are some unmentioned

standard features that are in social media. The ability to have a personal profile that is very

basic is included, as well as the ability to search for and add friends.


(2) Analytical Background

With such a project, a large amount of research has to be done. There is two main types of

research involved in this project. These are design research and implementation research.

There is also some initial research that is called background research which justifies the

project in general. Design research describes the interface design choices of the application, or

how the application graphical user interface will look based on how other applications have

designed it previously. Implementation research includes how to actually make the design

choices a reality and what needs to be done to get these to work.

(2.1) Background Research

Before even starting the project. There was some general research undertaken to get a baseline

for the project to work from. One thing that was proven was the popularity of Android. An

online survey was created to ask people in UL what smartphone platform they use. As it

turned out Android was the most popular, further pushing the idea of developing an Android

application as opposed to programming the application on any other platform. The survey

results are shown in the figure below [1].

Fig. 1. Strawpoll result showing most popular smartphone operating system [1].


The result of the above figure shows that Android amongst friends is the most popular

platform. This is following the global trend that shows the same result. In 2015 Android holds

around fifty per-cent of global market share. This is shown in the figure below.

Fig. 2. Online result of smartphone market share [2].

Once Android was established as the platform of choice, it came down to deciding what

development environment to use for this project. Since Android is so popular and open, there

is a lot of choice in development suites. The goal was to find one that would be an all-round

contender. Initially research results pointed towards Eclipse. Which is known to be a very

good platform for various programming languages. However, once looking into it with more

detail it became clear that Eclipse was designed for seasoned developers who know generally

what they are doing, and considering that Android programming was a new skill that I was

learning at the time, I didn’t want to use Eclipse. The next option was Android Studio – which

turned out to be very intuitive and had lots of hints and tips internally. I chose to use this

development suite for the project.

Fig. 3. Android Studio Logo


Once the platform and the development environment was established. The type of application

had to be decided. Initially there was no decision made as to what type of application to

develop. Throwing around ideas and looking into application type popularity a choice was

made to go with a social application because of the following info-graphic in the figure

below.

Fig. 4. Popularity of smartphone applications per type [3].

The choice was determined by looking at the most popular type of application. This was

according to the info-graphic a video game. However, since the development of a game

generally requires a lot art work, the choice was made to go with the next best type, which

was social media. Social media requires a lot of software components to run and hence it

made sense to use this category as the project.


(2.2) Design Research

The main question that was asked in association of the design research of this project was,

“How have other applications done this before?”

With this in mind taking a look at most mainstream applications the following key points

were seen in all the applications:

• Signature font.

• Signature colour scheme.

• Easy to navigate.

The most inspiration for FriendNav GUI was taken from Instagram. Hence this application

will be the main example streamlining conventional application design in the Design section

of this document.

(2.2.1) Font

The applications font gives it an identity. With Instagram as an example it is clear that it has a

custom font. The joined text which appears like written text gives the application a homely

feel. It starts to feel less like an application and more like a diary. And this is very effective as

that is essentially the applications goal – a memory book.

Fig. 5. Instagram Font

(2.2.2) Colour Scheme

An applications colour scheme gives the application a theme. What the application does

should reflect on the colours that were chosen in the design. The colours chosen should be

somewhat unique to give the application identity. The application Tinder has a very unique

theme. It uses very bright and bold colours – which showcase the nature of the application.

Fig. 6. Tinder’s Bright Colour Theme


(2.2.3) Ease of Navigation

Another key factor to successful applications is the ability to use the application easily. The

application must be intuitive – otherwise the user will lose interest. Most social media have

this problem in mind when the design was made and once again Instagram is a perfect

example of good application navigation.

The Instagram home screen contains the main

application feed in the middle of the application.

This section is the main application content. At

the bottom we can see navigation buttons that

have their own personalised logos. This is very

smart and intuitive. It is clear what each button

does just by looking at the icon. The “Home”

button shows the current screen. The “Compass”

button clearly means some sort of search or

exploration. The “Camera” button is to take a

picture. The “Message” button is where all user

interactions happen and finally the “ID” button

takes the user to their personal profile. Overall

this design is very intuitive.

Fig. 7. Instagram’s Navigation Menu


(2.3) Implementation Research

Now that the general GUI design has been established. The question of “How to implement

the design?” must be answered. This is hard to answer as the developers of such applications

don’t generally give away their implementations out to the public as it was their hard work.

However there are some standard things implementations that are standard practice in the

world of social media:

• Client – Server communication.

• General Android Programming

(2.3.1) Client – Server

Any social media application that has ever had some sort of profile data or user data has to

connect to a server. Data cannot be stored on client side as the application on a large user-base

would become too large for the device. Also centralized data allows for data to be updated all

the time with each request. This requires some sort of server and client communication. This

communication generally comes in the form of client requests sent to the server. The image

below shows the most basic example of server-client communication.

Fig. 8. Server – Client Communication [4]

There are several methods for implementing this communication, but the two main types are:

• TCP Sockets

TCP sockets allow for portable applications. All they require to work is an internet

connection. There is no need for extra set-up, all they require is the client’s knowledge of the

servers IP address and the port that the socket is using.


• Webserver (HTTP)

A webserver operates using URL’s. The client can request and send data depending on what

the arguments are in a URL. What a webserver essentially does is send a client a form to

programmatically fill out and then receive an adequate response that depends on the server’s

function. This requires a special webserver and is more difficult to implement than the TCP

solution but allows for an Android application to also be accessible through a computer

browser.

(2.3.1) Android Programming

Android programming during the course of this project is a new topic being learned. As a

result it is a topic that must be researched if this project is to be implemented properly, even

with the limited information. Android uses “activities” for each application screen. Each

activity contains two files. The java class file and a layout XML file. The XML file is

responsible for the GUI of the activity and the java class file is responsible for any

programming.

Firstly a launcher activity must be created which is the first screen that the application

generates. In a social media case this would be the login page. Following the launcher activity

the user is assumed to be logged in. So this becomes the “parent” activity that all “child”

activities return to when they are closed. The image below describes this implementation

process.

Fig. 9. Android Activity Implementation.


(3) Design

Once the background research was complete the design work could be done. The design work

should be completed before any implementation as then there is a clear plan to follow.

However it is possible to run into issues when implementing a certain design and hence the

design may be altered. This section describes the design choices made in FriendNav and how

they have an impact in the overall application.

The design of this application can be broken into three main topics:

• GUI Design.

• Features Design.

• Data Storage Design.

(3.1) GUI Design

The general GUI design for FriendNav can be divided into the following separate entities:

Logo, Colour Scheme / Theme and Font. These combined have a specific effect on the feel of

the application and gives the application its own identity.

(3.1.1) Logo

FriendNav’s logo was created in “Gimp 2” software.

The general aim of the logo is to encapsulate the title

“FriendNav” into an image form. The initial idea came

from a Google image search of friends and navigation.

The resultant design is shown in the image to the right.

This image shows a happy face with a modified map

marker pointing to it creating an exclamation mark,

with the letters “F” and “N” in the image to

emphasise the name.


(3.1.2) Colours

The colours of FriendNav are a mixture of green and blue. This is to represent the colours of

the earth and give the application a “global” theme. It is showcasing the idea that the

application has potential global relevance. It shows that you can use this application to

interact with your friends around the globe. Below is a screen-cap of the application GUI

showing the colours of the interface.

Fig. 10. FriendNav Colours.

The signature colour for FriendNav is the dark green visible all throughout the app. And the

blue that gets darker as it reaches the key feature of the application – Map view. This is to

emphasise this feature and encourage the user to use it.


(3.1.3) Font

FriendNav takes its inspiration from and Instagram has a joined writing font that appears like

it is hand written. This is to emphasise the homely feel of the application. It feels less formal

and more like something you would use on a personal level.

Fig. 11. FriendNav Font.

The font used is called “Alako-bold” and was taken from a free font file repository. The font

is applied programmatically when each activity launches.

Fig. 12. FriendNav Font Code.

The above code creates a Typeface object in java and creates it form an asset file titled

“Alako-Bold.ttf” and then the text box with the FriendNav text is reconstructed with the new

font that is created.


(3.2) Features Design

The features that are implemented in the application are generally standard of what you would

see in all social media applications. Except there is a few differences in them that make

FriendNav simpler than most social media today. The image below displays the features in

terms of activities and their hierarchy in the application.

Fig. 13. FriendNav Features Hierarchy.

The first activity in FriendNav titled “Main Activity” is the application login page. Once

authentication is complete the application moves onto “PostLogin”. As titled this activity

handles all the user post login features. It is the parent activity that all other activities return

to, unlike the main activity – which is only a one way system once you’ve logged in.


(3.2.1) Main Activity

The Main Activity as shown on the left is a login portal for

FriendNav. The user inputs their credentials and they are directed to

the “PostLogin” activity or the authentication fails and they are

notified.

The main activity has a built in email input filter so that the

authentication query is not sent with an invalid email. This reduces

the amount of requests that are sent to the server.

Fig. 14. Main Activity.

(3.2.2) PostLogin Activity

This activity is the central program running the application. It is responsible for gathering data

that are required for all the other features. It is the service that runs to check for notifications

and displays them accordingly. It holds the user specific data which distinguishes the client in

terms of what user is currently using the application. The screen of this activity is shown

below. Showing the main navigation screen as well as a notification displayed.

Fig. 15. FriendNav PostLogin Activity & Notification.


(3.2.3) Alerts Activity

This activity displays the notifications in a history type format, where the newest notification

is displayed at the bottom and the oldest at the top of a list. The user has the option to refresh

the list – if a new notification comes in they must refresh to reload the data. The user can also

clear their notifications to have an empty list, which refills once new notifications come in.

FriendNav displays the following types of notification:

• New Messages.

• New Friend Request.

• Accepted Friend Requests from others.

Notifications allow for the user to know how others

interact with them, as well as when these things

happen as they are immediately informed with a

notification. If a user logs in with unreported

notifications they receive them as they log in. The user

also has the option of turning off push notifications in

settings which allows them to use the application

without any alerts.

Fig. 16. FriendNav Alerts Activity.

Alerts also appear as a small exclamation mark beside the alerts button when there is unseen

notifications. This is shown below

Fig. 17. FriendNav Alert Exclamation.


(3.2.4) Friends Activity

This activity manages the most fundamental part of the application, users. All the features

associated with FriendNav operate based on a user’s friends list. This activity allows for a

user to add or delete friends. The three tabs of the Friends Activity are shown below.

Fig. 18. FriendNav Friends Activity All Tabs.

The tab labeled “Friends” shows the user their current friends in the application. The list

shows the users personally set display name and display bio, as well as a personally set image

by the user.

The tab labeled “Search” refers to the users that are on the application but currently not

friends with the user. The user can choose to send a friend request and the friend in question

receives an alert to tell them they got a friend request.

The tab labeled “Requests” refers to any received friend requests from other users. The user

may respond by accepting or declining the friend request. If the user accepts, then the friend

in question recieves a notification with this information.


(3.2.5) Settings Activity

This activity allows the user to personalise a very basic profile. The lack of a complex profile

is a method in which to encourage the users to interact. The choice of name, short bio and a

single picture as changeable data is to allow for some personalisation. It is also essential for

recognising exactly who a user might be. This activity also allows for some user specific

settings to be modified with regards to some features of the application.

Fig. 19. FriendNav Settings Activity All Tabs.

The image inside the profile tab of the activity is the FriendNav default profile image that

users have when they do no set a profile picture or remove an existing one. It is taken from

the logo and serves as the standard user picture.

The settings tab allows for users the choice to have certain features enabled or disabled.

• Push Notifications enabled – This refers to the notifications that show up even when you are

not currently using the application.

• Chat Enabled – This refers to the ability to disable chat messages to the user. They do not

become available to chat if this is turned off. The user cannot chat if this is turned off.

• Map View Enabled – This refers to the Map View feature, and this setting removes the user

from being marked on a map with their last location on Map View. The user cannot use map

view unless this feature is enabled.


(3.2.6) Events Activity

The Events activity allows for users to schedule events. Each user may schedule one event,

and this event is visible by all people on the user’s friends list. The idea of an invite list was

dumped as the idea is to meet up with people and it felt that if you have to chat someone to

invite them directly, then it is better than a simple “accept event” inside the application.

Fig. 20. FriendNav Events Activity All Tabs.

The left image shows the hosting tab as the user is creating a new event. If the user already

has an event created then the create option would not be there, instead the event would

display all the event information from the users event.

The image on the right shows the events that the user’s friends have going on. Clicking on the

event would display the event in a dialog box that’s the same as the one on the left but instead

of filling in details the box would be filled with the event information.


(3.2.7) Chat Activity

This feature is designed to allow users on FriendNav to communicate. The user is allowed to

chat with friends that have their chat enabled in settings. The message gets sent to the user’s

message box and they are time stamped. The user also gets a notification upon receiving a

new message.

Fig. 21. FriendNav Chat Activity.

The image on the left displays on the top half the message list, and on the bottom half

displays friends that are available to chat. These users only appear on the list if their chat is

enabled in settings.

The image on the right shows what happens when the user presses “Send Message”. In this

case the user is replying to Bill Gates message and the dialog that is shown is the message

sending mechanism of the application.


(3.2.8) Maps Activity

This feature is the key feature of FriendNav. This feature uses the Google maps API to get the

users current location and send the data to the server. This feature also includes a “Map View”

which creates markers for the users friends with map view enabled. The map displays where

the user’s friends are and whether they are currently online or not. With this in mind the user

can notice a friend is near and message them to meet up.

Fig. 22. FriendNav Maps Activity.

The image on the left shows the user opening the “Map View” and not yet pressing the “Find

close friends!” button. Once the user presses the button their location gets sent to the server

and the client retrieves the user’s friend’s location data.

The image on the right shows the map markers associated with friends that have map view

enabled. The image shows a user with an online status. The buttons on the bottom right allow

for navigation with a Google Map to the friends location.


(3.3) Data Storage Design

The majority of social media applications store the user data on a server. FriendNav is no

different. The reason for storing the data on a server means that the client can request only the

data it needs. This is also allows for FriendNav to be portable as the server can be moved

along with its repository of data. This section talks about the general data storage structure of

FriendNav and the profile specific data structure.

(3.3.1) General Data Storage

FriendNav uses a directory structure that starts from the source directory “FriendNavData”.

This is the parent folder and all the data is stored under this folder. Going down one more

level in the directory structure the folders we see a file “findUID.txt”, this file distinguishes

the user’s specific account identification number by matching it with a specific email address.

On this directory level we also see a “defaults” folder – which holds any default user data.

Such as the default image for a user. The “profiles” folder stores all user specific data. Inside

the profiles folder are all the user data folders labelled by the user’s account identification

number. The general structure can be seen below.

The file “userList.txt” is a file containing all the user

ID’s currently on FriendNav. This file is accessed by

the friends feature to have the non-friend user-base

available to all the users.

By comparing the users friends list to the global user

ID’s file the difference in ID’s are essentially the

people the user is not friends with.

The overall size of this data depends completely on

the amount of activity in the application and the

amount of users currently in the application. The

more the users the more buffering of data would be

required as there would be too much data for the

client to work smoothly.

Fig. 23. FriendNav General Data Structure.


(3.3.2) Profile Specific Data Storage

Each user on FriendNav has their own specific directory structure. All FriendNav features

work from these files and each profile structure is associated with a user account ID. The

profile directory structure is shown below.

Fig. 24. FriendNav User Profile Data Structure.

The image on the left shows the first level of the profile directory structure. This level stores

the users personal profile data, password, online status and friends feature data. The overall

data structure for each profile is generally never larger than 2MB in size.

The image on the right shows data separated into folders which relate to the specific feature

that they are associated with. The chat folder stores the status of the users chat setting. As

well as all the messages the user has received. The events folder holds the users event file that

stores all the information that is displayed in the events feature. The location folder stores the

data for map view. The first file is associated with the users map enabled setting in the

settings activity and the location file stores the users last updated latitude and longitude

values. The notification folders first file stores all unreported notifications that get moved to

“other.txt” once notified – which is the file that stores all notifications once reported. The last

file in this folder is a file that lets the client know that new notifications are enabled.


(4) Implementation

This section will talk about the implementation strategies associated with FriendNav. The two

main areas that will be covered form an implementation perspective are server and client side

implementations as well as the communication strategies between the two. FriendNav is

coded in java on the client side, so the choice was made to write the server also in java as to

reduce the knowledge base required to develop this project.

(4.1) Server - Client Communication

FriendNav in terms of client and server uses java. With this in mind the first attempt at server

and client communication was with Java RMI (Remote Method Invocation), which is an API

used in java to remotely call methods on a client from a server. The problem with Java RMI is

that it not compatible on Android. So with this an Android alternative was the next step.

LipeRMI is an Android implementation of the Java RMI technology [5]. Due to the difficulty

of implementing this alternative solution – all efforts were shifted towards a more

fundamental type of Java communication, TCP Sockets. LipeRMI required a java file to be

installed to the project with some further set up and it was easier to go with the TCP socket

solution but it meant that the server side parsing of requests had to be implemented.

Fig. 25. Server Side TCP Socket Code.

Fig. 26. Client Side TCP Socket Code

The above images show the code associated with setting up a connection between the server

and the client. On server side a port is specified. On the client side a port and a hostname must

be specified. This allows the socket to have a unique identity and hence the packets may

traverse the internet to reach their intended destination.


(4.2) Server Implementation

Considering the server uses TCP sockets. There is an input data stream and an output data

stream. The server side accepts Java Strings as the input stream and responds in Java Strings

back to the client or in a byte output stream if it is an image.

The server accepts the following String format for client requests:

command:target:value

• Command: This is the function that will be called on the server side.

• Target: This field refers to the user ID in question. The person who is calling the request.

• Value: This field refers to the parameters that are being sent – such as a new name value etc.

Each server client request creates a new thread on the server. This is to allow multiple

requests to be handled by the server. This feature is necessary when dealing with multiple

clients, otherwise users would have to wait for requests to complete before they can send their

own. The image below shows the start-up process of the server and the logging associated

with each request that is received.

Fig. 27. FriendNav Live Server Log.


(4.2.1) Server Commands List

Each of the requests that the client sends to the server is a method that runs on the server. A

switch-case statement reads the client request and splits the input using the colon as a

delimiter and the first result of the split is the command. The table below shows the server

side method and what they do.

Method Name Function of Method

authUser Takes email and password and checks for validity on the server.

getUID Takes email and returns the associated unique user ID.

getDisplayName Takes UID and returns users display name.

setDisplayName Takes UID and String and sets users display name.

getBio Takes UID and returns users display bio.

setBio Takes UID and String and sets users display bio.

setImage Takes UID and bitmap image and sets as user display picture.

getImage Takes UID and returns users bitmap image.

deleteImage Takes UID and sets users image to default image.

getFriends Takes UID and returns list of user’s friends from friend list.

acceptFriend Takes UID and Friend’s UID, clears requests and adds friends.

declineFriend Takes UID and Friend’s UID, clears requests.

friendRequest Takes UID and Friend’s UID, adds UID’s to request files.

addFriend Takes UID and Friend’s UID and appends them to each friend list.

getRequestsRecv Takes UID and returns received friend requests.

deleteFriend Takes UID and Friend’s UID and removes them from friend’s lists.

getLocation Takes UID and returns users location data.

updateLocation Takes UID and String and updates user’s location data.

getLocationStatus Takes UID and returns user’s online status.

updateOnlineStatus Takes UID and String and updates user’s online status.

updateMapEnable Takes UID and String and updates user’s map view setting.

getOthers Takes UID and returns user’s non-friends.

getAlertStatus Takes UID and returns user’s new notification status.

setAlertStatus Takes UID and String and updates user’s new notification status.

getCurrentAlerts Takes UID and returns users unreported alerts.

getOtherAlerts Takes UID and returns users reported alerts.

clearAlerts Takes UID and clears user’s alerts file.

setChatEnabled Takes UID and String and updates users chat setting.

sendMessage Takes UID, Friend UID and String and sends message to Friend.

getMessages Takes UID and returns users messages.

clearMessages Takes UID and clears users messages file.

getChatEnabled Takes UID and String and updates users chat setting.

createEvent Takes UID and String and creates an event.

deleteEvent Takes UID and clears user’s event file.

getEvent Takes UID and returns user’s event file contents.

sendAlert Takes UID, Friend UID and String and updates current alert file of

friend.

Fig. 28. Table of Request Commands.


(4.3) Client Implementation

The client has the ability to use the server functions as outlined in Fig. 28. There is two main

functions that all activities in the application have that handle all inbound and outbound

information. This section will explain these communication methods as well as the general

coding and logic associated with the activities implementation.

(4.3.1) Client Requesting Data

Activities in FriendNav use the method “getData” to retrieve any information needed for the

user. The image below is a code snippet of the code. This function returns a String.

Fig. 29. FriendNav Client getData() Method Code.

The above code creates a thread on the Android device to allow the activity not to break in

case of the request not completing. The thread will run in parallel to the application. This code

snippet in particular shows the outbound message that is sent to the server, following the

standard request format as discussed in the previous pages. Each request creates a new socket

connection with the server. This allows for multiple requests happening at once, composing of

different information that may be needed in an activity. This method accepts two arguments

which represent the “command” and the “target” on a standard request.


(4.3.2) Client Sending Data

Activities in FriendNav use the method “sendData” to update any user information, or to send

any data to other users. The image below is a code snippet of the code.

Fig. 30. FriendNav Client sendData() Method Code.

The above code is almost identical to the getData method call however in this case it does not

return any result. It is a void method, meaning that once it completes there is no data to be

retrieved from it. This type of method is mainly used when the client is sending a request that

does not need a response. Another difference in this method from getData is that it accepts a

third parameter in the method call as opposed to just two in the getData. The third parameter

corresponds to the “value” on the method call. This is a String and is used as the data

parameter transfer in the socket. This field is generally where the client places its new data

that is passed onto the server. Such as the user’s name or a new user bio etc.


(4.3.3) Activities Implementation Logic

The two functions mentioned previously are the fundamental methods that allow for

communication between the application and the server. With this in mind a process of

creating the features within the app was developed with the logic described in the image

below.

Fig. 31. FriendNav Activity Coding Logic.

The above image shows the general coding logic behind each activity. Initially data is

requested from the server. This data depends on the activity that is being currently run on the

device. Most activities require the user’s friends list to operate so initially the client will

request this. Once this is received then the client will request other data such as the names

associated with the people in the friends list or the user’s current location etc. After the data is

gathered the layout for the activity is created and set up. The data then is appended to specific

fields in the layout file. From this point the user may decide to send some data to the server in

the form of accepting another user’s friend request. The request is sent via a method call and

the activity is reloaded including the data, as it may have changed by the request that is sent to

the server. This logic is used throughout all the activities in the app that require up to date

information. Below is an image showing code of a method call and an activity reloading.

Fig. 32. FriendNav Reloading Activity Logic.


(4.3.4) Communications Diagram

The image below describes how FriendNav communicates with the server and GPS service

provider.

Fig. 33. FriendNav Communication Diagram.

The above communication diagram shows how FriendNav communicates to the different

services and components. The GPS service returns GPS Coordinates in the form of java type

“Double” from an API Call. In the case of FriendNav the GPS provider is Google, using the

Google maps API. The clients then send this information to the server, which stores it under

the specific users file directory. The communication between the server and the clients as

mentioned in the previous sections is TCP socket communication. The code snipped below

shows the API call for requesting current location.

Fig. 34. FriendNav Google Maps API Location Call.


(5) Testing

The initial plan for testing FriendNav was to set up a beta test for some friends and family to

use the application. Unfortunately it proved too difficult for this to work as a server with a

static public IP address was required. This section will talk about testing the application with

regards to the testing environment as well as the application and server performance.

(5.1) Testing Environment

The FriendNav server during the testing phase of the project was running on a Windows 10

PC. The server was ran directly as a project in NetBeans, which is the IDE that the server was

developed on. In parallel to this server project, there was a client project which simulated

requests that the application would create, giving the ability to test new functionality as it was

being implemented.

Fig. 35. FriendNav NetBeans Projects.

The FriendNav application was developed on a local network. This means that any device that

wanted to connect to the FriendNav server needed to be connected to the same router. There

was a static local IP created for the PC that the server ran on. The reason for this is that the

application would not need to change the hostname of the socket that it was connecting to.

Each device on a local network gets assigned an address with the following prefix:

192.168.1.X , where X is any number from 2 to 254. This is why the server log shows devices

with such a prefix and a specific suffix. This is shown below.

Fig. 36. FriendNav Server Log Client IP.


The application however could not be tested fully from simulated FriendNav method calls. To

make sure that there was an adequate testing platform several Android devices were used and

tested the application functionality. With this in mind the main basis of testing revolved

around two android devices on the local network using the server functions and ironing out

any bugs in the meantime.

(5.2) Performance Testing

This kind of application has a high priority on speed and performance. Users will not

download an application that does not run well or slows down their device. The main reason

why FriendNav was developed with the server completing all the computations was to

remove that processing from the client and hence improve overall performance of the app.

This as a result does not use much battery life as some mainstream applications are known to

do. There were two main tests carried out to determine performance of the project as a whole.

(5.2.1) Application Performance

The application was tested to check for general usage performance as well as system

performance. The image below shows both RAM usage of the application as it is running and

the amount of internal memory the application takes when installed.

FriendNav uses 40.74 MB of memory to be installed

on the device. This in the context of other social

media is quite small, however most other social

media have quite a lot more functionalty.

FriendNav during runtime uses 37.2 MB of RAM on

the device. This is not a huge number comparing

once again to other social media applications which

can hit 100’s of MB. FriendNav uses less RAM as it

does not cache data. FriendNav requests data as

fresh data everytime an activity is loaded. This

improves overall performance but mean s that the

user must request data regularly.

Fig. 37. FriendNav Memory and Size Usage.


(5.2.2) Server Performance

Testing the server performance was quite difficult. The idea was to try and simulate a huge

amount of client requests to really try and stress the server. It was impossible to gather

enough Android devices and log into FriendNav with all of them so instead the client project

from NetBeans was used to create a while loop with many requests. This code snipped is

shown below.

Fig. 38. FriendNav Server Performance Test Code.

The above code shows a while loop with a sleep function on it. The loop every tenth of a

second creates a client object which uses the most computational power which is the

“getImage” call. Even with ten of these requests per second the performance is quite good.

The task manager result is shown below.

Fig. 39. FriendNav Server Performance.

The above image shows a total of 2.3% CPU usage during the stress test. This shows that the

server functions aren’t too demanding for the server. The RAM usage in this case is not

accurate due to the IDE being used as an editor, hence already reserving a bit of ram for

temporary files etc.


(6) Results

This section talks about the overall results that have been gathered from the project and what

areas could have been improved and explored throughout the development of this application.

(6.1) General Results

The end result of this project allows for a functional application of which the features

included are complimentary to the idea of friends meeting up. The map view is a great feature

to use to figure out who is available and where. All the other features are complimentary to

this fundamental knowledge of where your friends are. The events feature allows the user to

schedule an event and ask his friends to attend. An event creates an incentive to meet up and

this is following the function of the application. The chat feature allows the user to talk

directly about the idea of meeting up to another user, and hence they can elaborate on the

details of the meet up. The lack of profile allows for less information to be send to the client

and also does not clutter the application with information, as that is not the function of the

app. The idea that the user has a choice in the matter of what features they are included in is

important too. Not every user will want push notifications or want to be available on specific

features of the application all the time, so the settings feature gives the user the power of

choice. Overall the features of FriendNav work well together but not perfectly. It’s a big

project and there is always some difficulties when working on your own. The next section

highlights some problems with potential solutions.

(6.2) Potential Improvements

This section will talk about specific areas where the results shown could have been modified

or improved in a way that would make the application work better and be more robust. The

following topics will be covered.

• Buffering Results.

• More Feature Options & Security.

• Optimisation.

• Client Request Communication Format Improvements.

• Compressing Images.


(6.2.1) Result Buffering

FriendNav works well when the user-base is small. Once the “Search” tab in the Friends

Activity grows larger, the longer it will take for this activity to load. The current

implementation loads all the information needed in one go, this would take a long time if

there is a lot of users in the user-base as all of them would be displayed. The solution would

be to buffer these results. Limit the results to a certain amount at a time or else allow the user

to search with a string, limiting the results to the search criteria.

(6.2.2) More Feature Options

Currently FriendNav includes settings that allow users to be included or excluded from

certain features in the app. However, FriendNav should include more feature specific options.

These options should be specific to users in the user-base or specific in terms of values.

Examples include setting a maximum distance proximity for users to show up on the Map

View. It would make sense to limit your search of friends on the map to a self-defined

distance specified by the user. Another option potentially would be to allow the user to be

invisible to specific user in the user-base in the chat feature. Currently the user is either

completely available to their friends list to chat or not available at all. The ability to enable

these very specific options add a greater level of customization to the user experience and the

users would appreciate such freedom.

(6.2.3) Optimisation

FriendNav has plenty of room for improvement when it comes to optimising the application.

The current client request implementation allows only for very fundamental information

retrieval. As a result any single activity that is being called, creates many single client request

to the server. An improvement that could be made is to have activity specific server

commands to be created to return all the information required for the activity in question in

one go, rather than first request the friends list followed by the getting each individual display

name for the people in the friends list. The server should already return just the list of the

users friends in name format rather than their user ID’s followed by retrieving the name

afterwards. The fundamental client commands could still be used in this process, but

internally by the server as the main feature specific commands are being called.


(6.2.4) Client Request

FriendNav uses TCP sockets to contact the FriendNav server. The server receives a String

with certain format delimited by a colon “:”. The problem with using this character as the

delimiter is that if the user has any input which contains a colon, then the information could

be lost as FriendNav keeps only the first three delimited entries. There is checks in place in

place for where the user may input a colon that stop the user from doing so. However it is not

optimal to not allow a user to use commonly used characters. The solution, in hindsight is

very simple, but was realised too late to fix. The delimiter can be more than just one

character, it could be for example two colons “::” , which would allow for the user to use the

single colon and not be affected, with a check in place for the double colon. Unfortunately

this fix was only realised too late and hence not implemented due to the time constraints of

the project.

(6.2.5) Compressing Images

FriendNav in its current implementation has a small flaw. The images that are uploaded by

the client are the original size and dimensions. Considering that FriendNav fits them to a

square image box no matter what size they are, they maintain the their original data size. This

makes the loading of users with such images longer because the images are bigger in data

than they need to be. A solution to this would be implementing a client side compression on

the images as they are chosen and before they are uploaded to FriendNav. The image picker

would allow the user to hover their image over a square grid to set the image up for the

correct resolution as well as compress the image once chosen to allow for smaller amounts of

data to be sent. This would reduce the length of time that the app would need to load certain

activities as well as decrease the amount of data that is being transferred with each image

request.

(6.2.6) Security

FriendNav does not currently have any security as implementing this feature would take too

long and the project would be incomplete before the deadline. In the scenario where there was

more time to complete the project, data encryption would have been used server side. Some

secure telecommunications protocols such as AES would have been used to encrypt

passwords, location and other sensitive data [6]


(7) Conclusions

FriendNav overall has been a success. The app was developed in a modular fashion with all

the components working together. The focus on simplicity was maintained. There was no

overly ambitious ideas that led to an incomplete project.

The key was simplicity. The application has simple features that work. This shows that the

aim of the project has been met in that aspect.

The application was trying to be a gateway for friends to meet up. The addition of the Map

View feature along with its complimentary chat and events features all contribute to the idea

of meeting up. Therefore the theme of the application was consistent.

Overall for one person to create a server side implementation from scratch to serve an android

application with handling for multiple requests is a lot of work. And for everything to work as

intended in a relatively short space of time, is an achievement in itself. Therefore overall the

project was a success. It has been a great learning experience as well as a major test of talent

and to have a complete project in the end feels uplifting.


(8) References

This section references any material used in the development of this project. Considering

developers do not readily give out solutions to their projects in the social media world, the

references are limited to research. The development and ideas used in FriendNav were all

thought of and implemented through trial and error with very little to no reference or help.

1. Daniel O’Neill. (2015) ‘Strawpoll Survey - What smartphone operating system do you

mainly use?’ [online] http://strawpoll.me/5609499/r (Accessed 26-MAR-16)

2. adappt.co.uk ‘MARKET DIVERSITY AND VARIANCE’ [online]

http://www.adappt.co.uk/ios-blackberry-symbian-and-microsoft-vs-android-fair-fight

(Accessed 26-MAR-16)

3. Stacey Rudolph. (2015) ‘Mobile Apps Usage – Statistics and Trends’ [online]

http://www.business2community.com/infographics/mobile-apps-usage-statistics-trends-

infographic-01248837#vkCb7CvZhVMo2ie7.97 (Accessed 26-MAR-16)

4. Computer Science Trends. ‘Web Technology’ [online]

http://www.cstrends.com/?q=node/23 (Accessed 26-MAR-16)

5. SourceForge. "LipeRMI" [online] http://lipermi.sourceforge.net (Accessed 26-MAR-16)

6. Adam Berent “AES”. http://www.adamberent.com/documents/AESbyExample.pdf

(Accessed 26-MAR-16)

http://strawpoll.me/5609499/r

http://www.adappt.co.uk/ios-blackberry-symbian-and-microsoft-vs-android-fair-fight

http://www.business2community.com/infographics/mobile-apps-usage-statistics-trends-infographic-01248837#vkCb7CvZhVMo2ie7.97

http://www.business2community.com/infographics/mobile-apps-usage-statistics-trends-infographic-01248837#vkCb7CvZhVMo2ie7.97

http://www.cstrends.com/?q=node/23

http://lipermi.sourceforge.net/

http://www.adamberent.com/documents/AESbyExample.pdf


(9) Acknowledgements

In this section I would like to give credit to the people who have helped in the development of

FriendNav. I would like to thank the following people for their help and contribution to the

project. Their help and guidance propelled the project forward.

• Supervisor: Dr. Máirtín Ó Droma:

Guidance in general regarding the project. Help with written documents and contribution of

suggestions and ideas with all aspects of the project. Providing help in writing documents

associated with the project.

• Dr. Reiner Dojen:

Providing help with Java related questions. Suggesting certain solutions to problems

associated with the early server – client communications implementation.

• Dr. Eoin O’Connell:

Providing a virtual machine server for testing the projects network capabilities. Answering

networking related questions and general guidance with network connectivity within the

project.


(10) Poster

Documents

FYP_12130648_FriendNav