Licentabogdanmuresan [608202]

FACULTY OF AUTOMATION AND COMPUTER SCIENCE
COMPUTER SCIENCE DEPARTMENT

LICENSE THESIS TITLE

LICENSE THESIS

Graduate : Firstname LASTNAME

Supervisor : scientific title Firstname LASTNAME

2016

FACULTY OF AUTOMATION AND COMPUTER SCIENCE
COMPUTER SCIENCE DEPARTMENT

DEAN, HEAD OF DEPARTMENT ,
Prof. dr. eng. Liviu MICLEA Prof. dr. eng. Rodica POTOLEA

Graduate: Firstname LASTNAME

LICENSE THESIS TITLE

1. Project proposal: Short description of the license thesis and initial data

2. Project contents: (enumerate the main component parts) Presentation page,
advisor's evaluation, title of chapter 1, title of chapter 2, …, title of chapter n,
bibliography, appendices.

3. Place of documentation : Example : Technical University of Cluj -Napoca,
Computer Science Department

4. Consultants :

5. Date of issue of the proposal : November 1, 201 5

6. Date of delivery : June 30th, 2016 (the date when the document is submitted )

Graduate : ____________________________

Supervisor : ____________________________

FACULTY OF AUTOMATION AND COMPUTER SCIENCE
COMPUTER SCIENCE DEPARTMENT

Declarație pe proprie răspundere privind
autenticitatea lucrării de licență

Subsemnatul(a) _______________________________________________________
_________________________________________________________________ ,
legitimat(ă) cu _______________ seria _______ nr. ___________________________
CNP _______________________________________________ , au torul lucrării
________________________________________________________________________
________________________________________________________________________
____________________________________________elaborată în vederea susținerii
examenului de finaliz are a studiilor de licență la Facultatea de Automatică și Calculatoare,
Specializarea ________________________________________ din cadrul Universității
Tehnice din Cluj -Napoca, sesiunea _________________ a anului universitar __________,
declar pe proprie r ăspundere, că această lucrare este rezultatul propriei activități
intelectuale, pe baza cercetărilor mele și pe baza informațiilor obținute din surse care au
fost citate, în textul lucrării, și în bibliografie.
Declar, că această lucrare nu conține porțiun i plagiate, iar sursele bibliografice au fost
folosite cu respectarea legislației române și a convențiilor internaționale privind drepturile
de autor.
Declar, de asemenea, că această lucrare nu a mai fost prezentată în fața unei alte
comisii de examen de l icență.
In cazul constatării ulterioare a unor declarații false, voi suporta sancțiunile
administrative, respectiv, anularea examenului de licență .

Data

_____________________ Nume, Prenume

_______________________________

Semnătura

Instrucțiuni generale
De citit înainte (această pagină se va elimina din versiunea finală) :

1. Cele trei pagini anterioare (foaie de capăt, foaie sumar, declarație) se vor lista pe foi
separate (nu față -verso), fiind incluse în lucrarea listată. Foaia de sumar (a doua)
necesită semnătura absolvent: [anonimizat], respectiv a coordonatorului. Pe declarație se trece
data când se predă lucrarea la secretarii de comisie.
2. Pe foaia de capăt, se va trece corect ti tulatura cadrului didactic îndrumător, în engleză
(consultați pagina de unde ați descărcat acest document pentru lista cadrelor didactice
cu titulaturile lor).
3. Documentul curent a fost creat în MS Office 2007. Dacă folosiți alte versiuni e posibil
sa fie m ici diferențe de formatare, care se corectează (textul conține descrieri privind
fonturi, dimensiuni etc.).
4. Cuprinsul începe pe pagina nouă, impară (dacă se face listare față -verso), prima pagina
din capitolul Introducere tot așa, fiind numerotată cu 1. Pe ntru actualizarea
cuprinsului, click dreapta pe cuprins (zona cuprinsului va apare cu gri), Update field –
>Update entire table.
5. Vizualizați (recomandabil și în timpul editării) acest document după ce activați
vizualizarea simbolurilor ascunse de formatare ( apăsați simbolul  din
Home/Paragraph ).
6. Fiecare capitol începe pe pagină nouă, datorită simbolului ascuns Section Break (Next
Page) care este deja introdus la capitolul precedent. Dacă ștergeți din greșeală simbolul,
se reintroduce ( Page Layout -> Breaks ).
7. Folosiți stilurile predefinite (Headings, Figure, Table, Normal, etc.)
8. Marginile la pagini nu se modifică ( Office 2003 default ).
9. Respectați restul instrucțiunilor din fiecare capitol.

1
Table of Contents

Chapter 1. Introduction (Heading 1 style) ………………………….. …………….. 1
1.1. Project context (Heading 2 style) …………………… Error! Bookmark not defined.
1.1.1. (Heading 3 style) ………………………….. ………. Error! Bookmark not defined.
Chapter 2. Project Objectives ………………………….. ………………………….. …… 3
Chapter 3. Bibliographic Research ………………………….. ……………………….. 5
Chapter 4. Analysis and Theoretical Foundation ………………………….. …… 6
Chapter 5. Detailed Design and Implementation ………………………….. …… 8
Chapter 6. Testing and Validation ………………………….. ………………………… 9
Chapter 7. User’s manual ………………………….. ………………………….. ………. 10
Chapter 8. Conclusions ………………………….. ………………………….. …………… 11
Biblio graphy ………………………….. ………………………….. ………………………….. 12
Appendix 1 (only if needed) ………………………….. ………………………….. ……. 13

Chapter 1
1
Chapter 1. Introduction (Heading 1 style)
This work tries to improve the way people communicate and share various
responsibilities and tasks. It takes an existing concept, the one of sharing tasks between
individuals and makes it easier, faster and better. While sharing a task with another
smartphone user i s not a new concept, the capability of connecting to the location service
of the device and provide location based task triggers is something which i s not explored
enough. Also, a special emphasis is placed on the use of modern mobile and web
technologies in achieving scalability and the best use of resources.
Usually a smartphone user would have to go through a series of long steps, usually
switching to different apps to achieve the simple goal of sharing a task with someone and
track the progress made on it. The existent mobile solutions do not allow you to combine
more ways of defining the right moment when the said task would be activated and become
the subject of the user attention. This appl ication seamlessly combines both a time based
triggering syst em with a performant and reliable location monitoring one. Geofencing is
employed to solve the above problem in a battery efficient and privacy oriented fashion.
The smartphone device has two levels of accuracy for location detection and the app
switches b etween them automatically. A moderate accuracy level is employed to monitor
the user location with respect to the defined points of interest until the user enters in a close
range and then a more precise system is engaged. This second way of monitoring the
location has better precision but it’s costlier to use with respect of battery and network use.
It can trigger application events when the user enters in a customizable range from the
specified point of interest. Because both the time and the location dim ensions are
monitored by the application the user is smartly notified only once.
These notifications are propagated by the use of a cloud based informational
system. Third party mechanisms of delivering sensitive notifications in a timely manner
are used. A scalable system has been built for the storage of data. To avoid over
accumulation of old data a hybrid system is used. Data is kept on the cloud for the time it
takes for the user to be notified of the shared task, moment in which the data gets cloned
in a local smartphone side database and erased from the cloud. This step is taken from
multiple considerations. The very first and most important is to transform the cloud side of
the product in a highly scalable system. Keeping expired resources in a datab ase would
quickly load the servers. Instead the decision to move the data to a distributed storage space
was taken. Each smartphone has the capability of storing millions of records locally if
needed. For further scalability the physical distance to the se rvers was also considered, so
the back -end data storage has built -in replication of data for servers hosted in different
geographical locations. These servers will serve the same data for users from different parts
of the world to ensure that the network c ommunication channel has minimal delays. Data
replication is ensured by the 3’rd party storage solution that was chosen. Almost all user
data is stored in a 3’rd party real -time database called Firebase. It is hosted on Google
servers providing near 100% u ptime. The back -end is a multiple component environment:
The main part is a real -time NoSQL database hosted in the cloud service called Firebase.
It hosts all the user data, accounts and logs. It communicates with the Android client via a
3’rd party SDK wh ich is written in native code. This allows for the fastest data transfer
speeds and the shortest possible query times. Without a server intermediating in the
exchange of data, the user has access to a large quantity of data very fast. To ensure that

Chapter 1
2
the cl ient has also performant write times, Firebase allows for transactional writes that
allows the client to batch multiple insert/update queries in a single operation.
While the battery and storage efficiency of the system was discussed, the modern
devices a nd users are heavy users of mobile internet connections. So this resource has to
be protected more than the others. Multiple proven techniques were employed to save data
traffic. The one that yields the most results is the use of push notifications instead of
continuously polling the server for new data. A classic system would continuously try to
fetch new resources from the server component in an attempt to minimize the time delay
between the moment fresh data is made available on server and when this data is visible to
the concerned actors. This pooling would create a lot of overhead because most of the time
no new data would be available for a specific user. So, to solve this performance issue ,
push notifications were used as a mean of notifying the clien t device that new data is
available on the back -end. While this process would be described in more detail further in
this thesis, it was able to cut the data traffic with almost an order of magnitude.
For having a hermetically secured environment, all inte rnet traffic is done via
HTTPS. To get access to the data stored on the servers, the client is required to provide a
token which is obtained in a login process. Those tokens can be obtained by means of
logging in with email and password or with 3’rd party authentication providers like Google
and Facebook. One advantage of logging in with a 3’rd party provider is that you don’t
have to create a new account and password. Security is ensured by the 3’rd party provider,
many of them having a 2 factor authentica tion system. A security code is transmitted via
sms to the user’s device in order to account for the possibility of stolen passwords. On the
back -end all the data is also stored securely, with all the passwords encrypted.
One aspect that creates a unique opportunity for the described application is that,
opposed to the competition, it allows the user to establish relationships with other users on
multiple levels of trust. Other applications will require users to accept all incoming tasks
for security reas ons. This application basically allows users to add tasks with alarms and
geolocation to 3’rd parties with or without their confirmation. To eliminate the friction of
having to confirm every received task like in other apps, this paper will describe in mor e
detail in further sections the techniques employed to escalate the level of confidence in
select users and accept database inserts from other users, not necessarily from our own.
This requires a one -time approval from the logged in user, all subsequent d ata exchanged
with that specific 3’rd party will be done without any user confirmation. This makes for a
smoother user experience and it doesn’t violate the privacy because at any time the user
can reduce the communication channel with that party to the no rmal level, having all
transactioned data run through a rigorous approval process.

Chapter 3
3
Chapter 2. Project Objectives
The described project – Delegate , takes care of the fundamental need of delegating
tasks to other persons. Its main objective is to make it as easy as possible, taking the
unnecessary complexity out of the picture. It also extends the solutions that are already
available on the market by a lso adding location centered tasks along ones based on time. It
allows users to exchange tasks under a completely secured environment. Scalability is
another main objective of this project, the system was architected with multi -million user
figure in mind, leveraging proven existing 3’rd party technologies and systems to achieve
this.
One of the first objectiv es for Delegate is to get users to register . This is essential
for the grow th and value of the project. To make it as easy as possible for users to create
new accounts, several third party authentication providers were integr ated alongside the
classic email and password one. Using a third party a uthentication provider creates several
opportunities. The users can sign up faster, the system would be able to collect more data
about the user (almost all 3 ’rd party integrations offer at least a full name and a picture)
and the complexity of storing username and passwords would be completely avoided .
To be able to distribute the application to as many users as possible the official
distribution channel: Google ’s Play Store was chosen. It has the advantage s of built -in
security, seaml ess updates and others. The procedure of publishing the application to the
Play Store will be described in a future chapter, along with the entire proc ess of signing
the release build with a custom keystore using the versatile Gradle build system.
Once the user is logged in, the next very important objective is to allow him to
make connecti ons with other users of this project. To make it an easy process, Delegate
has integrated two main ways of facilitating growth: invites over email and sms. Once the
user gets into the application, it is made very clear how to establish a connection with an
existing contact. Via the 3 ’rd party invite mechanism that Google provides, emails and sms
messages can be sent to other users from the native integration with the phone messaging
capabili ties. After the invited users have installed the application, with the user of
deeplinks, Delegate is able to establish a connection b etween the user that sent the
invitation with the invitee.
The true objective of the project is to facilitate sharing of tasks with other users, so
after the connections are done between users, one would be able to quickly create a task ,
set either a location, alarm , or both to it and share it with his contacts. For choosing a
locatio n, Delegate integrated Google Maps Places API , which allows a registered user to
pick a place using either it s name or location . If Delegate manages to acquire location
details, it will create a geofence with the respective location on the receiving side. For
establishing geofences, Dele gate has to request permission from the user to obtain real –
time location updates. When setting up an alarm, the task will use the native AlarmManager
API to schedule an event in the future.
Tasks are kept in JSON format, being exchanged and stored upon sending in
Google ’s Firebase real -time database. To accommodate the structure of shared tasks, the
data model was architected in such a way t o facilitate storage in a NoSQL database . It has
the advantage of scalability and if architected correctly it provides fast access, without data
duplication.

Chapter 3
4
Another objective is to define certain metrics by wh ich to measure user engagement
and system overall performance. Some 3 ’rd party tools will be used to acquire these kind
of metrics: Firebase Analytics, New Relic, Fabric. They will allow to measure Delegate
user retention, server response time with the clear objective of continuously improving
Android client application reliability and server performance. Data regarding reliability
will be collected by Fabric, a 3 ’rd part y SDK that will be integrated into Delegate system
to allow for crash log collection along with some other useful information to facilitate issue
debugging and fixing.
An equal ly important objective is user engagement . A key metric that drives
engagement is the number of times the user will interact with the system. T hat means to
open the application and preferably even read or write a task. There is nothing that
participates to engagement more than notifications. Notifications are key to keeping users
engaged and they are buil t on top of accurate real time data. If there would be a delay of
days, hours or even minutes between the time a task is shared and received on the other
side, the feeling of responsiveness wou ld be lost. But on the other hand if users are
receiving new tasks and status updates for existing tasks in the very moment they are saved
on the server, this would drive user engagement and encourage users to become frequent
users, which is key to every application success. To achieve fast transmission of data,
without sacrificing too much battery and network consum ption, push notifications were
chosen. While this notification system is described in a future section, it basically allows a
server module to observe the d atabase for changes to the tasks and if a change is noticed to
identify the owner and receiver of that task, and notify the devices they run the app on by
means of Firebase Cloud Mes saging . It is a very fast and reliable mechanism o f getting
fresh data when it is available as opposed to pooling a server for new data every predefined
number of seconds/minutes.
One other objective very important for Delegate is to make the application work in
an offline mode . The lack of a working internet connection will block any data from being
actually transferred to the other party, but local caches will be created on the sender side
that will start syncing the next time when an internet connection will be available. This is
important because a lot of users will find themselves in the situation where their internet
connection is non -existent or not very re liable. How this is achieved is to store a copy of
the new data that is to be written, present it to the user in the same way a s data that is
synced is presented and observe the Connectivity API when there is a state change from
not connected to active connection and retry the sync.
Making the applic ation work on as many devices as possible is a very important
achievement . When planning to do just so, Delegate includes in the list of supported
devices all Android devices running OS 4.1 and above, including tablets. To gra cefully
render the user interface on as many devices possible a practice known as Responsive User
Interfaces is employed, defining all the visual elements relative to one another in such a
way that the proportions are kept when switching from a low to a high resolution phone.

Chapter 3
5
Chapter 3. Bibliographic Research
Bibliographic research has as an objective the establishment of the references for
the project, within the projec t domain/thematic . While writing this chapter (in general the
whole document), the author will consider the knowledge accumulated from several
dedicated disciplines in the second semester, 4th year ( Project Elaboration Methodology ,
etc.), and other disciplines that are relevant to the project theme.
Some more text
Represents about 15% of the paper.
References will be included in the Bibliography section. The reference format must
be IEEE, or similar. The introduction of new references in the Bibliography section, a nd
their citation within the document text can be done manually (by obeying the format), but
it is less recommended, or by using the tools mentioned in the last paragraphs of this
chapter.
In the Bibliography section, there are examples of references to c onferences or
workshops articles [1], journal articles [2], and books [3]. References to applications or
online resources (web pages) must include at least a short relevant description in addition
to the link [4], and other information is available (author s, year, etc.). References that
contain only the link to the online resource will be placed in the page footer.
Each reference must be cited within the document text, see example below
(depending on the project theme, the presentation of a method/applica tion can vary).
In paper [1] the authors present a detection system for moving obstacles based on
stereovision and ego motion estimation. The method is … discus the algorithms, data
structures, functionality, specific aspects related to the project theme, etc…. Discussion:
pros and cons .
In chapter 4 of [3], the similar -to-my-project -theme algorithm is presented, with the
following features…
Software and other tools managing bibliography for MS Word 2003 , and usage
instructions can be found at:
How to use JabRef (BibTeX) with Microsoft Word 2003
Bibtex4Word
BibWord makes it easier to create and manipulate Microsoft Word citation and
bibliography styles
For MS Word 2007 and MS Word 2010 , the integrated bibliography management
system should be used , References, Citations & Bibliography. More information can be
found in the online documentation of MS Office.

Chapter 4
6
Chapter 4. Analysis and Theoretical Foundation

4.1. Use cases
In figure 4.1 all the major use cases of the proposed sys tem are displayed. Some of
them are described in more detail.

Figure 4.1 Use case diagram of the Delegate system

Chapter 4
7

– Important use c ases (with diagram s)
– Firebase real time db (obsevers, receivers)
– Firebase security rules
– FCM
– Data refresh procedures
– Android loaders
– Geofencing
– Eventbus
–

 used or proposed algorithms ,
 used protocols ,
 abstract models ,
 logic explana tions/arguments concerning the chosen solution ,
 logic and functional structure of the application, etc.
YOU DO NOT write about implementation.
YOU DO NOT copy/paste info on technologies from various sources and others
alike, which d o not pertain to your pr oject (no fillers, please!).

Chapter 5
8
Chapter 5. Detailed Design and Implementation
Together with the previous chapter takes about 60 % of the paper.
The purpose of this chapter is to document the developed application such a way
that it can be maintained and developed later. A reader should be able (from what you have
written here) to identify the main functions of the application.
The chapter should contain (but not limited to) :
 a general application sketch/scheme,
 a description of every compon ent implemented, at module level,
 class diagrams, important classes and methods from key classes.

Chapter 6
9
Chapter 6. Testing and Validation
About 5% of the paper.

Chapter 7
10
Chapter 7. User’s manual
In the installation description section your should detail the hardware and software
resources needed for installing and running the application, and a step by step description
of how your application can be deployed/installed. An administrator should be able to
perform the installation/deployment ba sed on your instructions.
In the user manual section you describe how to use the application from the point
of view of a user with no inside technical information; this should be adorned with screen
shots and a stepwise explanation of the interaction. Base d on user's manual, a person should
be able to use your product.

Chapter 8
11
Chapter 8. Conclusions
About. 5% of the whole.
In this chapter you present:
 A summary of your contributions/achievements,
 A critical analysis of the results achieved ,
 A description of the possibi lities of improv ements /further development .

Bibliography
12
Bibliography

[1] A. Bak, S. Bouchafa, and D. Aubert, "Detection of independently moving objects
through stereo vision and ego -motion extraction," in IEEE Intelligent Vehicles
Symposium (IV) , San Diego, USA, 2010, pp. 863 -870.
[2] A. Chambolle and T. Pock, "A First -Order Primal -Dual Algorithm for Convex
Problems with Applications to Imaging," Journal of Mathematical Imaging and
Vision, vol. 40, pp. 120 -145, 2011.
[3] R. C. Gonzalez and R. E. Woods, Digital Image Processing. Second Edition. :
Addison -Wesley Longman Publishing Co., Inc., 2001.
[4] Ajax Tutorial, http://www.tutorialspoint.com/ajax/ .

Appendix 1
13
Appendix 1 (only if needed )
…
Relevant code sections
…
Other relevant info (proofs etc.)
…
Published papers (if any)
etc.