Atlas: Milestone 1 Report

Group 10
October 27, 2017

Web: http://54.235.57.209/
Android: https://www.dropbox.com/s/3z0pxmpip75gqfl/atlas-debug.apk?dl=0

1 Executive Summary
1.1 Summary of Project Status
This milestone was about getting the main infrastructure up and running, and having our core
features implemented in a somewhat basic fashion to really show to our customers the actual
functionality. We havent addressed design issues in this milestone as much as we have worked on
functionality according to a consensus that building our core functionality was a higher priority
than having a good design. We plan to improve frontend and android designs in later milestones.
On a very high level, it can be said that the current status of Atlas project is quite good. We
were able to deliver all the features that we have planned to deliver in this milestone, and are
looking forward to start working on more exciting ones. Main features in this milestone are:
Safe authentication system
Content creation and viewing
Navigation
Basic user feed

1.2 Changes Planned

API documentation will always be up to date with backend.
Design and UI for frontend and android will be created before the implementation.
Standard annotation models will be studied before the implementation of the mechanism.
A separate API instance on a different port will be used for test requests to prevent lots of
meaningless content on our production environment.

2 Status of Deliverables
1. Secure Authentication Mechanism Done
Authentication mechanism is completed by the implementation and inte-
gration of JSON Web Tokens to our API. Users passwords are hashed and
stored in the database for security and privacy. After successful login the
user is responded with a JWT Token to keep the user and authentication
information in the sessions. After expire or log out, the user is provided
another fresh token after the next log in.
2. Content Creation and View In Progress
Content creation from Rest API, frontend and Android has been imple-
mented and properly working. Image upload is also working and the
contents created can be viewed by both our web and android apps. Con-
tent creation is working and but we are going to implement more detailed

1
 functionalities (Tags, Location, Date, Different Kind of media Items) on
out next milestones. All the requirements for the first milestone is satis-
fied.
3. Searching Future
A Semantic Search mechanism shall be implemented for more extensive
access to the Cultural Heritage Items in the future. This will be com-
pleted by the second milestone deadline of the customer. This mechanism
shall allow the user to search items based on multiple features and will
be responsive.
4. Recommendation Mechanism Future
Recommendation Mechanism is yet to be implemented. This will be com-
pleted by the second milestone deadline. This mechanism will allow the
user to view recommendations based on their search history and interests
and also their locations.
5. Annotations Future
Every content on the Cultural Heritage Item pages will be annotatable.
All kinds of content shall be targetable by annotations on the Cultural
Heritage Item page. The annotation body will have different kind of
types(text, media, etc). This function will be implemented by referring
to the standart annotation model.
6. Media Item Support In Progress
Support for image items(uploading, viewing and scrolling) is completed
in the first milestone. For the second milestone video item support will
also be completed. And also annotation will be available. Adding and
viewing multiple media items will be functional.
7. Commenting Future
Commenting feature is not yet implemented in the project. This feature
will be implemented before the second milestone and will be available for
all the signed up users.
8. Fully functional API In Progress
Currently all the API endpoint for first milestone is implemented, de-
ployed and working(Authentication and Content Creation). Our REST
API is implemented by Django and DjangoRestFramework and is being
tested in every iteration. It has a api blueprint documentation in the
repo. The backend also has the Swagger app for Django to test and try
out the API endpoints with a nice and easy UI.
9. Working Web App In Progress
All the requirements are matched for the first milestone in our web app.
The web app has been already deployed and live. All the changes and
deliverables is going to be implemented by the frontend with the API
before the release.
10. Working Android App In Progress
All the requirements are matched for the first milestone in our Android
app. The Android app has been already built and packaged. All the
changes and deliverables is going to be implemented by the Android app
with the API before the release.

3 Evaluation of the Status of Deliverables

Overall, we believe that the current status of deliverables are satisfactory. We have managed to
present all the deliverable we have promised to our customer. We evaluate our status on each
deliverable that was promised on this milestone and the ones that we have started to work on.
1. Authentication Done
We have finished the main work on authentication system. The remaining

2
 work to do on authentication system is implementing token refreshing on
Android, and having a guest user mechanism. These features are thought
to be included in our second milestone.
2. Content Creation and View In Progress
We have finished an important part of content creation and viewing fea-
ture; yet, there is still a lot of work to be done to fully implement this
feature. Currently, Android design for content creation and viewing is
rather poor and needs to be enhanced quite a bit. Furthermore, we have
undecided thoughts about how to store our media items, how to upload
them. etc. Since content creation and viewing is the absolute core of our
project and since it will significantly change as we implement recommen-
dation, location, and search systems, there still seems to be a lot of work
to do on this side.
3. Media Support In Progress
Regarding media item support, our server currently stores only URLs and
doesnt have a media uploading feature. We have overcome this problem
by using a 3rd party service to store our media items; however, this is
subject to change as there is still ongoing discussions about where to store
our media items and which way would be the most efficient and robust
one.
4. Fully functional API In Progress
As for our current API, we try to follow the best practices and have
an API documentation. Currently, our API documentation is manually
written in a markdown file; in later stages, we may use Swagger to au-
tomatically generate an API reference. However, we believe that having
a good documentation with insightful comments is really important to
make our users aware possible pitfalls. Apart from documentation, we
still havent decided fully on some of currently working API endpoints
5. Working Web App In Progress
We were satisfied with our progress in our Web app design and function-
ality so far. The web app is deployed and fully connected to our Rest
API. There seems to be no errors on our web app for the implementation
so far. We have created all the necessary components and hierarchy for
this milestone. For the next milestones there will be more components
and design refactoring.
6. Working Android App In Progress
We can say that we are quite pleased with our progress in Android app
functionality. We were able to fully connect our app to backend and sup-
port all the planned deliverables in this milestone. However, we have to
say that our current design is very poor and ugly. In upcoming milestones,
we plan our app on this side as well with the help of our designers.

3
4 Coding Done
Coding done by members
Group Member Work Done
Backend Swagger Api endpoint explorer integration.
Backend tutorial, also sample app, models and views for kistart.
Backend integration of psql and static file serving via insecure.
Frontend Cloudinary image uploading and storing API integration.
A. Emirhan Karagl
Frontend Refactoring the design and also integrating redux.
Frontend Creation of redux stores for the components
Frontend Added redirecting functions and fixed errors and warnings
Frontend Add the necessary node modules and middlewares for components
Android bug that misleading of sign-up page after successful sign up fixed.
M. Taha Srmeli Android implementation of item detail page and its links with other activities.
Android bug that recreating items in feed page fixed.
Backend API Documentation with using API Blueprint language
Kutay Candan
Backend creating API Documentation environment in Apiary for visuality concern
Android implementation of profile page
Android get user profiles from server and implementation of navigation drawer
Ramazan K. Trkmen
Android implementation of some signup functions , and show error messages
Android bug that to return to the auth page from the main page when pressed back
Android logout implementation
Android initial project structure
Android request/response classes integrated with Gson and retrofit2 libraries
Android project API structure
Android code refactoring and project structuring to have a modular Android project
Android login and signup activity layout and functionality
Android content creation layout and functionality
Eref zdemir Android token handling via SharedPreferences
Android error handling functions and general error handling logic
Android home activity layout and functionality
Android fragment layout and implementations for feed
Android list adapters for various ListViews
Android photo and gallery image uploading via Cloudinary integration
Android unit and instrumentation tests
Android navigation using Fragments and PagerAdapters
Android part of Travis configuration script
Travis integration

4
 Coding done by members
Group Member Work Done
Login and signup components creation in React(without API connection) framework
Router creation in React
Aykut Bozkurt
Backend Django setup tutorial in Linux
A. Kaan Gndz Frontend Design
Infrastructure setting up AWS EC2 for server provider
Infrastructure installing gunicorn service for serving Django application
Infrastructure configuring nginx for webserver
Infrastructure configuring firewall & EC2 port protection for security
Infrastructure setting up initial Jenkins on port :8080
Infrastructure configuring Jenkins for running automated tests before deployment
Infrastructure configuring Jenkins build script for deploying backend & frontend apps
Yiit zkavc Frontend setting up initial architecture with React
Frontend setting up Redux for global state management
Frontend tutorial for initial project setup
Frontend business logic for login, signup and redirecting user
Frontend error alerts on unexpected user behaviors
Frontend cultural heritage creation with title and description
Frontend content viewing
Frontend navigation with react-router library
Backend research about media storage in postgres using django framework
Muhammed Nursoy
Backend set up development environment for windows
Backend login, signup, logout features with jwt
Backend cultural heritage, image, user, tag models
Backend endpoint to create or get cultural heritage items(POST,GET)
Backend serializers and views for cultural heritage, image and users
Backend adding multiple images, tags in one request feature
Backend linux tutorial for setting up the development environment
S. Talha Nianc
Backend endpoint to create or get images
Backend endpoint to create or get tags
Backend handling exceptions in general
Backend extensive tests for authentication
Backend extensive tests for cultural heritage items
Backend extensive tests for images
Backend tests coverage is kept really high since it is the basic structure for the project

5
5 Requirements
1 User Requirements
1.1 User Interface
1.1.1 Users shall be able to update their personal information including their password.
1.2 Sign-up
1.2.1 User should have two signup options
1.2.1.1 Facebook login shall be available for registering and shall access necessary
profile data.
1.2.1.2 Sign-up form shall be available for users that are going to register without
Facebook login.
1.2.2 Users shall choose a unique and valid username while registering(Optional for
facebook).
1.2.3 Non-Facebook users shall choose a valid password for login.
1.3 Log-in
1.3.1 Facebook registered users shall be able to login via Facebook.
1.3.2 Non-Facebook users shall be able to login with their usernames or e-mails and
passwords.
1.4 User Profile
1.4.1 Users shall be able to update their personal information.
1.4.2 Users shall be able to choose their interest for different type of items.
1.4.3 Users should be able to invite their friends via e-mail, whatsapp and facebook.
1.5 User Types
1.5.1 Unregistered users shall only be able to view items.
1.5.2 Registered users shall be able to view items, add new items, comment on and
upload media items.
1.6 User Contribution
1.6.1 Users shall be able to comment on Cultural Heritage Items and Media Items.
1.6.2 Users shall be able to comment on comments.
1.6.3 Users shall be able to upload media items.
1.6.4 Users shall be able to create Cultural Heritage Items.
1.6.5 Users shall be able to report Cultural Heritage Items, media items, comments and
annotations.
1.7 Content
1.7.1 Feed
1.7.1.1 Users shall be able to view the popular and recommended items on their
feed.
1.7.2 Recommendation
1.7.2.1 Users shall be able to get recommendations on their search, visit, like
and comment history.
1.8 Search
1.8.1 Users shall be able to search for Cultural Heritage Items.
1.8.2 Registered and guest users shall be able to search according to labels and cultural
heritage items name and location.
1.9 Cultural Heritage Item
1.9.1 Users shall be able to add comments to each item separately such as adding com-
ments to cultural heritage items, adding comments to media items and adding
comments to annotations.
1.9.2 Guest users shall be able to view available cultural heritage items, its media items,
and its annotations and its comments.
1.9.3 Registered users shall be able to view and add cultural heritage items, media items,
annotations and comments.
1.9.4 Registered users shall be able to report cultural heritage items.
1.10 Annotations
1.10.1 Registered users shall be able to add annotations on media items.
1.10.2 Registered users shall be able to add multiple annotations on the same area of the
media item.

6
 1.10.3 Registered users shall be able to add references to other media items in text anno-
tations.
1.10.4 Registered users shall be able to add comments to annotations.
1.10.5 Registered users shall be able to view annotation comments when they click to the
annotation.
1.10.6 Registered users shall be able to report inappropriate annotations.

2 System Requirements
2.1 Functional Requirements
2.1.1 User Interface
2.1.1.1 It shall be in English. It does not have to give service in any other
language.
2.1.1.2 It shall be able to accept the inputs consisting of latin characters which is
represented in ASCII table. The characters which do not exist in ASCII
table shall not be accepted.
2.1.1.3 It shall be able to be opened via Chrome and Firefox web browsers. The
other browsers will not be in consideration.
2.1.2 Sign-Up
2.1.2.1 The system shall support registering via Facebook and e-mail.
2.1.2.2 The system shall ask for a valid e-mail address, a valid password and a
valid username for the users registered via e-mail.
2.1.2.3 The system shall be able to support entering username for the users
registered via Facebook account for the ones who do not want to use
Facebook username.
2.1.3 Log-in
2.1.3.1 If a user who is registered via e-mail enters his/her password that matches
with his/her e-mail address, the system shall log the user in.
2.1.3.2 If a user registers via Facebook, the system shall log the user in directly.
2.1.3.3 System shall not display log-in page on a machine the user has already
logged in until the user logs out.
2.1.4 Search
2.1.4.1 System shall support autocomplete feature.
2.1.5 Cultural Heritage Item
2.1.5.1 System shall determine the hierarchy of items, cultural heritage items,
media items, annotations and comments respectively.
2.1.6 Annotations
2.1.6.1 System shall support only text input as annotations.
2.1.7 Recommendations
2.1.7.1 Recommendations on users feed
2.1.7.1.1 System shall generate recommendations based on the users for-
mer visited items.
2.1.7.1.2 System shall generate recommendations based on the users and
similar users liked items.
2.1.7.1.3 System shall generate recommendations based on the users and
similar users commented items.
2.1.7.2 Recommendations on Heritage Items page
2.1.7.2.1 System shall give recommendations on a Cultural Heritage Items
page according to its tags.
2.1.8 Android Application
2.1.8.1 Android application shall allow users to download cultural heritage items
for offline viewing.
2.2 Non-Functional Requirements
2.2.1 Front-End Development
2.2.1.1 Android Application
2.2.1.1.1 Android application shall be aware and make use of users loca-
tion

7
 2.2.1.1.2 Facebook Login should be available for users, and necessary in-
formation should be retrieved from Facebook Facebook Login
Android
2.2.1.1.3 Android application shall conform to the official Android Best
Practices guidelines.
2.2.1.1.4 Android application shall be lightweight and shall not consume
battery power unnecessarily.
2.2.1.1.4.1 Android application shall not perform any background
tasks.
2.2.1.1.4.2 Android application shall not do any expensive compu-
tation that can be done on the server.
2.2.1.1.5 Android application shall be downloadable on at least 95% of
the Android devices that are active on Google Play Store.
2.2.1.1.6 Android application shall provide all of its functionality not re-
quiring internet connection when the device is not connected to
the internet.
2.2.1.1.7 Android application shall automatically log a user in following
a successful sign up for a better user experience.
2.2.1.2 Web Application
2.2.1.2.1 Web application shall be aware and make use of users location
2.2.1.2.2 Facebook Login should be available for users, and necessary in-
formation should be retrieved from Facebook Facebook Login
Web
2.2.2 Back-End Development
2.2.2.1 Database
2.2.2.1.1 Validations(ie. constraints) shall be made both in database and
application layer.
2.2.2.2 Security
2.2.2.2.1 Both application and back-end protection shall be implemented
for permission system (see 2.1.3).
2.2.2.2.2 SQLi and Xss injection attacks shall be prevented for both web
application(see 2.2.1.2) and web services (see 2.2.2.4).
2.2.2.3 Annotations
2.2.2.3.1 Server shall represent Annotations in annotation containers.
2.2.2.3.2 Server should allow suggestion of annotation urls while creating
an annotation.
2.2.2.3.3 Server shall allow retrieving annotations for all users.
2.2.2.3.4 Server shall allow creating annotations for only registered users.
2.2.2.3.5 Server shall allow updating and deleting annotations only if the
logon user is the owner of the annotation.
2.2.2.3.6 Annotations can be flagged as spam (too much report can cause
annotation to be removed).
2.2.2.4 Web Service
2.2.2.4.1 Web services shall serve data via endpoints for both Android
and Web applications.
2.2.2.5 Back-End Application
2.2.2.5.1 Back-end application shall contain all the business logic includ-
ing annotations (see 2.2.2.3).
2.2.2.6 Availability
2.2.2.6.1 System should be available 99.9% of the time.
2.2.2.6.2 In the case of a failure, system should recover in at most 1 hour.
2.2.2.7 Reliability
2.2.2.7.1 Systems test coverage should be over 96.0% all the time.
2.2.2.7.2 Unit, integration and behaviour tests shall be written to ensure
reliability.

8
 Figure 1:

6 Design
Both the frontend and android teams worked with mockups while the concept design is to be
finished after the first milestone. The front end is using React + Html + Css. The designs are
made with photoshop and will be implemented with the help of .psd files. The will also be provided
in invision in order to give a better understanding for devs.

7 Project Plan
Project Plan
Task Start Date End Date
Project Investigation 2.14.2017 2.19.2017
Communication Planning 2.22.2017 2.23.2017
Software Requirements 2.28.2017 3.06.2017
Use-cases 2.28.2017 3.06.2017
Use-case Scenarios 2.28.2017 3.06.2017
Web Mockup Design 2.28.2017 3.09.2017
Android Mockup Design 2.28.2017 3.09.2017
Use-case Diagram 2.28.2017 3.06.2017
Class Diagram 2.28.2017 3.12.2017
Sequence Diagram 2.28.2017 3.22.2017
Initial Planning 3.14.2017 3.22.2017
Learn more about Android Application Development 3.23.2017 9.17.2017
Learn more about Web Application Development 3.23.2017 9.17.2017
Learn more about Backend Development 3.23.2017 9.17.2017
Implementation of Autenthication(Login and Signup) 9.23.2017 10.07.2017
Implementation of Profile page 9.23.2017 10.07.2017
Implementation of Navigation 9.23.2017 10.07.2017
Implementation of Cultural Heritage Item Creation 10.08.2017 10.22.2017
Implementation of Basic User Feed 10.08.2017 10.22.2017
First Milestone Deadline 10.26.2017 10.26.2017
Content Creation with Location, Date, Tags and Different Kinds of Media Items 10.27.2017 11.10.2017
Adding Video Media Item Support for Cultural Heritage Item 10.27.2017 11.10.2017
Implementation of Semantic Search System 10.27.2017 11.22.2017
Implementation of Recommendation System 10.27.2017 12.03.2017
Second Milestone Deadline 12.07.2017 12.07.2017
Implementation of Annotation Mechanism 12.08.2017 1.01.2018
Final Milestone Deadline 1.04.2017 1.04.2017

9
8 Code Structure
8.1 Backend
We are using django in backend, which has a lot of built in classes and functions. Therefore when
we wanted to change some functionality of a class it was enough to override the corresponding
method of the class. We can classify backend code structure under the followings:

1. Urls
Django has a url.py file which basically maps endpoints to views. It uses regex so it is easy
to write generic endpoints. We can also use some parameters to specify more detailed things
for views for. If no endpoint matches the entered url it will return a 404 not found response.

2. Views
In views.py file you determine the content of the response. In views you specify which
serializer class and queryset will be used. Serializer class is a serializer that will serialize and
deserialize responses and request. Queryset will be used for queries such as creating a new
item, getting an item etc. In views if needed, you can also override methods such as create
which will determine the way objects are created. For requests like getting a specific item
you need to extract the id information in views.
3. Serializers
Conventionally we use serializers.py file to specify our serializers. In serializers we determine
how our models will be serialized or deserialized. Djangos serializers have a lot of nice
features. For example you can specify which fields will be readonly or writeonly. For example
you would want to make password write only field because otherwise people can see the
password when they send a GET request. So we made use of these things in our serializers.
They are modular so you can use them anywhere you want to. Also it is possible to do
nested serializations which is necessary for models with foreignkeys or some other relations
that require serializing or deserializing nested JSON.

4. Models
In models.py you specify your models and django will take care of creating and migrating
them. You just specify the fields with parameters such as unique,required etc.
5. Tests
In tests.py you write your tests. Here to test APIs we used API client which took care of
tokens etc.

In backend we currently have two apps, authentication and atlas. They both have the above-
mentioned structure. The main app is atlas app and it redirects the urls related to authentication
to the authentication app. We also have a settings.py in atlas application which basically has all
apps settings such as allowed hosts, expiration time.

8.2 Frontend
We are making use of React as UI library, and Redux for state management on frontend codebase.
We can say that frontend has two distinct sides of it: business logic and UI.
With react and redux we tried to keep the frontend nice, modular, structured and easy to refactor.
Frontend code structure can be evaluated in the following items that are abstract concepts coming
from pure functional state management in the world of Redux:
Routers
Routers are the deciders that decide which container/component user should see based on
the URL and the global state of the application.

Containers
Containers are the "smart" wrappers around one or more components. The only purpose of
container is to implement a business logic to be used inside components. Containers have
nothing to with what user shall see, they only provide privileged state data and actions to
dispatch to components.

10
 Components
Components are the least smart element of the web application. They receive state and
actions to dispatch from their containers and render the view in html-like structure called
JSX, which allows us to embed javascript business logic into our view easily.
For instance, a login component doesnt have any idea how many cultural heritages are
living in the state right now. Because its container didnt provide that information, instead,
container provided a function called "login()" and the only thing this component knows is
that it should call this function when user wants to login.

Actions
Actions are structured event calls that every state mutation should be done with. In other
words, if someone wants to change the global state (adding a cultural heritage, updating
profile information etc.), they should create an action like the following:
1 {
2 " type " : " A D D _ C U L T U R A L _ H E R I T A G E " ,
3 " data " : {
4 " title " : " Nemrut Dagi " ,
5 " description " : " Description for Nemrut Dagi "
6 }
7 }

Reducers

With actions, we have our well-formatted action descriptions, and we are ready to dispatch
them. What we do is that we describe how which action mutates the state (mutation is here
is litte bit misleading, actually. Redux never mutates the state, but rather returns a plain
new state. This is a pattern coming from the world of pure functional languages).
In order to update the state with a new one, we make use of the dispatch() function.
So, why are all this complexity exists? Because as UI applications get more complex, its
also getting hard to keep track of the state. When Redux managing state for us in a purely
functional manner, it also creates a timeline of transactions, in other words, we exactly know
what happened to state in which order. We can literally go back in time in a Redux-powered
web application, in fact, currently, chrome plugin for Redux has this capability.

Packages

Package management is very important when it comes to application that makes heavy use of
different kind of libraries. Libraries exist to make our lives easier, so managing them should
be easy too. This is where NPM comes into play.
We describe every package that should exist in our project in package.json file, versioned
with semantic versioning. Semantic versioning is a standard in versioning libraries, packages,
frameworks and many more. It has the following format: M AJOR.M IN OR.P AT CH. This
allows us to know how how much effort its required to update that package from version a
to version b, depending on its criticality.

8.3 Android
On Android side, we have tried to keep our project modular. Towards this end, firstly we tried
to keep classes together that have a single functionality or responsibility together in their separate
package. Accordingly, at the moment of writing this report, we have packages such as auth, home,
remote, adapter, response, utils, and so on. Secondly, we have tried to write classes that implement
retrofit2 response callback interface in a separate package instead of keeping them as anonymous
classes under other classes. This allowed us to write tests for these response handlers easier and
also made our code more readable.
We have tried to write doxygen comments for functions that are and will be used by several
other classes and which will serve core functionalities or utilities, as for example, functions defined

11
in Utils.java. We consider our current comments as an initial stepping stone towards a well docu-
mented Android project which will be relatively easy to get into and understand. To achieve this,
we will try to write comments on every function and class as time progresses.
To ensure that our code works as expected, we have written several unit and instrumentation
tests to test both core utility and Android related functionalities. We have tried to test utility
functions and have also written instrumentation tests for login and signup fragments. Yet, we
regret to say that our current test coverage is quite low; test coverage is an area that we need
to improve ourselves by a large margin. Furthermore, we werent successful in integrating our
instrumentation tests with Travis emulators to run them automatically.
We have tried to follow Android coding guidelines wherever possible. We havent stored any
string that is shown to users inside java codes; but, instead kept them in strings.xml file so that it
would be very easy to implement different localizations. When designing our layouts, we have tried
to refrain from giving hardcoded height and width values for our buttons, image views, etc. to make
our app easily portable to other devices; later, we witnessed that this was indeed a good idea when
we tried our app in landscape mode and saw that it looked quite nice. Additionally, as suggested
by one of presenters about mobile design during class time and our online research, we have tried to
use fragments wherever possible to make our user interface components easily portable and more
performant. In our current Android project design, we use a collection of fragments together with
a single activity to represent a collection of view items that together represent an idea, such as
content viewing and creating.

9 Evaluation of Tools and Management

9.1 Tools
9.1.1 Deployment
We are utilising Jenkins, an open source build automation tool to continuously integrate our ap-
plication.
Jenkins is a self-hosted service that runs on our server, and in fact it is currently accessible by
public address http://54.235.57.209:8080/.

We configured jenkins to take the following actions sequentially, and if any of them fails, notify us
and reject to deploy the application:

Fetch our application from the latest commit hash on branch master.

Go to backend application directory and install the required Django packages described in
manifest file requirements.txt.
Migrate the backend changes into production database.
Run the backend unit tests.

Go to frontend application directory and install the required node packages described in
package.json.
Build the frontend app and create necessary build files in dist/ folder.
Restart nginx webserver to serve from the fresh new atlas.sock file.

Restart gunicorn service for applying changes in the Django application

9.1.2 Testing
For testing our pushes and pull requests, we have integrated Travis to automatically run our
frontent, backend, and android tests. We have also enabled an option on github to disable merging
a pull request that doesnt pass travis checks. We have connected backend and android unit tests
to travis; integrating android instrumentation tests using a travis android emulator is work in
progress.

12
9.1.3 Android
On Android, we use Android Studio to develop, test, and profile our app. Android Studio is the
official Android app development platform and offers the best deal when it comes to how easy it is
to use new libraries, generate boilerplate code, do unit testing and get test coverage reports, and
many other things. Android Studio has a very neat monitoring feature that allows us to monitor
our apps network, CPU, memory usage and all the requests it does and the responses it receives;
thus, it makes our job as Android developers relatively easy.
Regarding libraries, we use
Retrofit2, Okhttp and Gson trio to handle HTTP requests and responses. We know from
experience that these three libraries work very well together and it is simple to set them up
and start implementing the actual request/response logic.
Glide for downloading images from the web and showing them on various image viewers.
When it comes to picking a library for image downloading on Android, we have two big
choices: Glide and Picasso. We have chosen to pick Glide simply to learn how to use it and
to be able to compare it with Picasso with which we already have some experince.
Cloudinary SDK to upload our images from local device storage. In our first milestone, we
have decided to use a 3rd party to keep our images; later, we may implement our own image
server.
Mockito and Espresso libraries to help us mock and test Android classes during instrumen-
tation tests.
Various Android support libraries for design and testing.

9.1.4 Frontend
For the deployed live version of our web app go to:
For our Web Application we use the node package manager NPM for Node.js It makes development
building and producing very easy for us. Using an IDE for developing in our frontend project is
not necessary. By installing npm and selecting a favourite text editor one is good to go.
WebStorm:
Although it is not necessary to develop frontend in WebStorm, this IDE provides a lot of
ease of use; smart completion, code and directory tracking, it is also integrated with git

React:
React is a very useful library for building UI and view layers of the web app. It provides a
lot of flexibility in writing code and a very tidy environment compared to good old html , js
, css. React provides the content of the web app without the need of reloading the pages.
Redux:
Redux provides a huge and pure JS state to track the changes and actions made on the
web app. It also provides consistency, debugging opportunities and also a great component
hierarchy in the app.
Chrome Redux-Dev Tools:
This is a very nice tool to track the state changes on chrome. Every code and every dispatch
and state in redux is reported by this tool. Helpful for debugging.
Sass:
Syntactically Awesome Style Sheets. Sass is a CSS extension which provides a lot of ease
of use compared to writing regular CSS. All the scss files are translated to regular CSS files
without the need of writing long and unstructured Css style files.

Npm :
Npm is a very useful JS package manager. It helps us to keep our used Js packages in
a manifest like file and installs all the dependancies and runs the project in one line of
command. It also unpack

13
9.1.5 Backend
PyCharm Since we used python we chose pycharm as our idea. It has a lot of shortcuts and
you can go to declaration of methods etc which made everything easier.
DjangoRestFrameWork Django rest framework has generics so we used them for our APIs
instead of writing them from scratch. To change a functionality of a generic we overrode its
corresponding method.
PSQL This is the database that we are using for our project. It does not store the tables in
projects folder.

9.1.6 Misc
Cloudinary:
This site provides 20 GB of free media storage and a very useful API to upload and view
media content. Our application currently uses this service of cloudinary on android and
frontend.
Swagger:
This is open source API framework which automatically design, build, document, and con-
sume RESTful Web Services. We use this framework for seeing how our API end points
works. This service is used
API Blueprint:
This is high level open source API description language which can be used with other visual
sites for API documentation design like Apiary. API Blueprint also supports github mark-
down so contrubuters can easily see API documentation clearly in github. Our application
uses this language for API Documentation.

9.2 Management
9.2.1 Issues
To manage our TODOs, bug reports, feature requests and discussions, we use the github issue
system. We have found the issue system easy to use and also handy to reference certain commits,
pull requests, etc.

9.2.2 Pull Requests

We use github pull requests to merge code into our default branch (master). We have enabled
status and review checks on our pull requests so that no pull request can be merged into master
without at least a single approved review and passed status checks. Working with pull requests
has proved to be a very good idea since we are able to see what other people are proposing to
change in the repository and can also give feedback. Furthermore, this system has pushed us to
structure our work and submit it in logical chunks that address a single problem.

9.2.3 Meetings
We have tried to meet weekly to discuss the work we have done and future possibilities. We tried
to keep our meetings as minimal, descriptive and informative as possible. We had no problems in
our task distribution since every single one of us was eager to get things done.

9.2.4 Communication
Communication is made over Slack, Whatsapp, Github. Our github account is synched to our
slack so all new pull requests, issues and branch modifications are triggering notifications for our
slack account. For momentary decisions and meet-ups we generally use Whatsapp to stay in touch.

14