View
55
Download
2
Category
Preview:
Citation preview
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
Final Year Project 2016 2
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.
Final Year Project 2016 3
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.
Final Year Project 2016 4
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
Final Year Project 2016 5
(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
Final Year Project 2016 6
(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
Final Year Project 2016 7
(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”.
Final Year Project 2016 8
(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.
Final Year Project 2016 9
(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.
Final Year Project 2016 10
(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].
Final Year Project 2016 11
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
Final Year Project 2016 12
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.
Final Year Project 2016 13
(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
Final Year Project 2016 14
(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
Final Year Project 2016 15
(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.
Final Year Project 2016 16
• 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.
Final Year Project 2016 17
(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.
Final Year Project 2016 18
(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.
Final Year Project 2016 19
(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.
Final Year Project 2016 20
(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.
Final Year Project 2016 21
(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.
Final Year Project 2016 22
(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.
Final Year Project 2016 23
(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.
Final Year Project 2016 24
(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.
Final Year Project 2016 25
(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.
Final Year Project 2016 26
(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.
Final Year Project 2016 27
(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.
Final Year Project 2016 28
(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.
Final Year Project 2016 29
(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.
Final Year Project 2016 30
(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.
Final Year Project 2016 31
(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.
Final Year Project 2016 32
(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.
Final Year Project 2016 33
(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.
Final Year Project 2016 34
(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.
Final Year Project 2016 35
(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.
Final Year Project 2016 36
(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.
Final Year Project 2016 37
(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.
Final Year Project 2016 38
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.
Final Year Project 2016 39
(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.
Final Year Project 2016 40
(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.
Final Year Project 2016 41
(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.
Final Year Project 2016 42
(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]
Final Year Project 2016 43
(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.
Final Year Project 2016 44
(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)
Final Year Project 2016 45
(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.
Final Year Project 2016 46
(10) Poster
Recommended