(numele și prenumele studentului) [611194]

Universitatea Tehnică a Moldovei

MOLDOVA SHOPPING ENG INE

Student: [anonimizat]: Conf. univ. dr. Beșliu Victor

Chișinău 20 18

Universitatea Tehnică a Moldovei
Facultatea Calculatoare, Informatică și Microelectronică
Departamentul Ingineria Software și Automatică
Programul de studiu Tehnologii Informaționale

Aprob
dr.conf.univ. Dumitru Ciorbă
șef departament
____________________
„__”_____________ 2017

CAIET DE SARCINI
pentru proiectul de licență al student: [anonimizat]

1. Tema proiectului de licență „Motor de căutare produse în Republica Moldova”

confirmată prin hotărârea Consiliului facultății de la „ 3” noiembrie 2017
2. Termenul limită de prezentare a proiectului 19.05.2018

3. Date inițiale pentru elaborarea proiectului Sarcina pentru elaborarea
proiectului de diplomă .

4. Conținutul memoriului explicativ
Introducere
1. Analiza domeniului de studiu
2. Proiectarea sistemului
3. Realizarea sistemului
4. Documentarea produsului realizat
5. Argumentarea economică
Concluzii
5. Conținutul părții grafice a proiectului
Diagramele UML ale sistemului, Interfața principală a programului .

6. Lista consultanților:
Consultant Capitol Confirmarea realizării activității
Semnătura
consultantului (data) Semnătura
student: [anonimizat]

7. Data înmânării caietului de sarcini 01.09.2017

Conducător
semnătura

Sarcina a fost luată pentru a fi executată

de către student: [anonimizat] 01.09.2017
semnătura, data

PLAN CALENDARISTIC

Nr.
crt. Denumirea etapelor de proiectare Termenul de
realizare a etapelor Nota
1 Elaborarea sarcinii, primirea datelor pentru sarcină 01.09.17 – 30.09.17 10%
2 Studierea literaturii de domeniu 01.10.17 – 30.11.17 20%
3 Alegerea și pregătirea de lucru a softului 01.12.17 – 25.12.17 20%
4 Realizarea programului 16.01.18 – 30.04.18 25%
5 Descrierea programului, diagramele UML 01.05.18 – 11.05.18 10%
6 Testarea aplicației 12.05.18 – 14.05.18 10%
7 Finisarea proiectului 15.05.18 – 18.05.18 5%

Student: [anonimizat], declar pe proprie răspundere că
lucrarea de față este rezultatul muncii mele, pe baza propriilor cercetări și pe
baza informațiilor obținute din surse care au fost citate și indicate, conform
normelor etice, în note și în bibliografie. Declar că lucrarea nu a mai fost
prezentată sub această formă la nici o instituție de învățământ superior în
vederea obținerii unui grad sau titlu științific ori didactic .

Diplomant __________ _________ __ V. Cristea

Confirm
Conducătorul tezei de licență V. Beșliu

Universitatea Tehnică a Moldovei
Facultatea Calculatoare, Informatică și Microelectronică
Departamentul Ingineria Software și Automatică
Programul de studiu Tehnologii Informaționale

AVIZ
la teza de licență

Tema: Motor de căutare produse în Moldova
Studentul Cristea Victor gr. FAF-141
1. Actualitatea temei: Astăzi a putea alege o cumpărătură , altfel a face o cumpărătură reușită , a
devenit o problemă, or atât pe piața autohtonă , dar în mod special pe cea străină , există o mulțime
de produse care par a fi calitative, dar ulterior se descoperă că nu -i chiar așa. Din aceste
considerente, problema este de o actualitate evidentă, dar și cu mare importanță practică.
2. Caracteristica tezei de licență : Aplicația a fost creată pentru facilit area găsirii un or produs
calitative pe piața moldovenească prin intermediul unei simple căutări.
3. 3.Analiza aplicației: Aplicația data este formată pentru a oferi o posibilitate de a ale ge din gama
largă de produse oferite de diferite magazine în dependență de preț, calitate, păreri și
disponibilitate.
4. Estimarea rezultatelor obținute: Aplicația va permite cre area unui catalog real de produse . Este
un produs program simplu în utilizare și intuitiv pentru or ice persoană cu cunoștințe minime în TI .
5. Corectitudinea materialului expus: . Materialul expus este p rezentat prin referințe la surse
relevante, ale unor autori cu experienț ă vastă în domeniul Tehnologi ei Informație i.
6. Calitatea materialului grafic: . Proiectul este prezentat prin: diagrame, tabele, interfețe ale
aplicației și corespunde cerințelor școlii superioare.
7. Valoarea practică a tezei: Aplicația r ste destinat ă utilizatorilor ce dețin telefoane mobile sau
tablete care ruleaz ă sistemul de operare Android . Aceasta program poate f i folosit de persoane
toate v ârstele .
8. Observații și recomandări: Cerințele față de teza de licență au fost îndeplinite în totalitate.
Observații nu sunt. Recomand participarea în concursul organizat de WSIS, inițiativa ONU World
Summit Awards.
9. Caracteristica studentului și titlul conferit : Studentul Cristea Victor a dat dovadă de
profesionalism în elaborarea lucrării, a respectat cerințele impuse , a manifestat exigență în
elaborarea și calitatea tezei d e licență. Din cele relatate, urmează că lucrarea de licență poate fi
admisă spre susținere și notată cu 10, iar diplomantului să -i fie conferită calificarea licențiat în
Tehnologia Informației.

Conducătorul tezei de licență conf. univ., dr. Beșliu Victor

Rezumat
Teza de licent , a cu numele "Motor de c autare produse ^ n Moldova" a fost dezvoltat a ^ n cadrul
Universit at ,ii Tehnice din Republica Moldova. Aceasta este scris a ^ n limba englez a s ,i cont ,ine 110
pagini, 30 guri, 23 list ari de cod, 11 tabele s ,i 7 referint ,e. Teza consist a dintr-o list a de guri, o list a
de tabele, introducere, cinci capitole, concluzie, bibliograe, s ,i anexe.
Obiectivul principal al tezei este de a rezolva o problem a real a care apare ^ n timpul c aut arii
unui produs pe piat ,a online a Republicii Moldova, dicultatea de a alege cel mai bun produs. Aceasta
implic a crearea unui motor de c autare prin compararea produselor existente pe piat , a. Exist a dou a
tipuri de utilizatori denit ,i ^ n aplicat ,ie: utilizatori ne^ nregistrat ,i, utilizatori ^ nregistrat ,i. Activit at ,ile
pentru ecare dintre aces ,tia sunt denite dup a cum urmeaz a: utilizatorii ne^ nregistrat ,i au dreptul
de a vizualiza tot contentul disponibil s ,i de a face c aut ari ^ n timp real din catalogul disponibil;
utilizatorii ^ nregistrat ,i au acelas ,i drept de a vizualiza tot contentul disponibil s ,i de a face c aut ari ^ n
timp real din catalogul disponibil c^ t s ,i de a ad auga un magazin cu toate produsele pe care acesta ^ l
presteaz a.
Aplicat ,ia propriu-zis a are scopul de a permite utilizatorilor ^ n timpul unei c aut ari s a vad a
diferent ,a de pret ,, calitate, p areri s ,i
uctuat ,ii a pret ,urilor la produsul c autat, la fel va  disponibil a
c autarea pe diferite categorii de produse pentru a face procesul mai intuitiv. O alt a funct ,ionalitate
va  ad augarea unor noi produse prin intermediul ^ nregistr arii magazinului la care acestea gureaz a,
plus ca scop de viitor este introducerea magazinelor cu opt ,iunea de Tax Free din Romania s ,i a celor
cu livrare rapid a spre Republica Moldova.
Ideea principal a a aplicat ,iei este s a fac a utilizatorii care au nevoie s a procure ceva pe internet
c^ t mai siguri ^ n alegerea pe care o fac, s a le ofere rating-uri si recenzii la produse, astfel un client de
r^ nd va avea posibilitatea s a g aseasc a un produs bun la un pret ,minim ^ n timp rapid.
Cele patru capitole care compun raportul curent includ analiza problemei ^ nt^ mpinate, solut ,ii
posibile pentru aceasta s ,i c^ teva sugestii adit ,ionale pentru implementarea unor noi caracteristici ale
aplicat ,iei.
Pentru a asigura un viitor real pentru lansarea aplicat ,iei a fost efectuat a o analiz a a tendint ,elor
economice pe piat , a. Analiz^ nd produsul din punct de vedere economic, a fost posibil a structurarea
unei idei generale asupra c^ torva indicatori nanciari, care sunt cruciali pentru durata de viat , a a
proiectului.

Abstract
The license thesis "Moldova Shopping Engine" was developed within the Technical University
of Moldova. It is written in English and contains 110 pages, 30 gures, 23 code listings, 11 tables
and 7 references. The thesis consists of a list of gures, a list of tables, introduction, ve chapters,
conclusion, bibliography, and annexes.
The main objective of the thesis is to solve a real problem that occurs during the search of a
product on the Moldovan online market, the diculty of choosing the best product. This involves
creating a search engine by comparing existing products on the market. There are two types of users
dened in the application: unregistered users, registered users. The activities for each of these are
dened as follows: Unregistered users have the right to view all available content and to make real-
time searches from the available catalog; registered users have the same right to view all available
content and make real-time searches from the available catalog and add a store with all the products
it provides.
The application itself is designed to allow users during a search to see the dierence in price,
quality, views and price
uctuations to the desired product, as search will be available in dierent
product categories to make the process more intuitive. Another feature will be adding new products
through record store where they are mentioned, plus future aim is to introduce the option of Tax
Free shops from Romania and those with fast delivery to Moldova.
The main idea of the program is to allow users who need to buy something on the internet as
more condent in the choices they do, give them ratings and product reviews, so a client will be able
to nd a good product at a minimum price in quick time.
The four chapters presenting the current report include the analysis of the problem encoun-
tered, possible solutions for it, and some additional suggestions for implementing new features of the
application.
In order to ensure a real future for the launch of the application, an analysis of economic trends
on the market was carried out. By analyzing the product from an economic point of view, it was
possible to structure a general idea of several nancial indicators that are crucial to the life of the
project.

8

UTM 526.2 .779 ME
Mod. Coala Nr. document Semnăt. Data
Elaborat CristeaV.
Motor de căutare
produse în Moldova Litera Coala Coli
Conducător Beșliu V. 8 110
Consultant Melnic R.
UTM FCIM
FAF– 141
Aprobat Ciorbă D .

9

UTM 526.2 .779 ME Coala

9 Mod. Coala Nr. document Semnăt. Data

List of Figures
2.1 Use case diagram for account management . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Use case diagram for the main screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Online Shopping – Checkout, Authentication and Payment . . . . . . . . . . . . . . . 30
2.4 Activity diagram for online browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5 Activity diagram for adding a product . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 Adding products by adding the store . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7 Sequence diagram for selecting a product . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.8 Search bar with category implementation . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9 Database diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.10 Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1 Android Studio welcoming screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Creating a new activity menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Example Android application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Activity map of the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5 Activity state paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Class diagram for online shopping domain . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7 State machine diagram user account protocol . . . . . . . . . . . . . . . . . . . . . . 43
3.8 Interaction overview diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Business
ow activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.10 User login controller object diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.11 Component diagram example with three related subsystems . . . . . . . . . . . . . . 46
3.12 Manifestation diagram for web application . . . . . . . . . . . . . . . . . . . . . . . . 47
3.13 Deployment diagram for J2EE web application . . . . . . . . . . . . . . . . . . . . . . 48
4.1 Login pop-up window process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Categories window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Adding a product by adding a store with . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Products ltering after a seach request has occured . . . . . . . . . . . . . . . . . . . 60
4.5 Multiple oers view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Specications view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7 Price
uctuations view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
10

Listings
1 LoginActivity – implementing onCreate method . . . . . . . . . . . . . . . . . . . . . 50
2 LoginActivity – nding views and setting listeners . . . . . . . . . . . . . . . . . . . . 50
3 LoginActivity – logging in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 MainActivity – tabs and fragments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 QuestionListFragment – onCreateView . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6 QuestionListFragment – onViewCreated . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7 Activity login – tree structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8 Activity main – creating tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9 Questions fragment – generating a list . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10 List item – presenting the products . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11 API controller – getQuestionsAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12 API Entity – Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
13 MainActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
14 MainScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
15 SplashScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
16 RegistrationActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
17 NoticationDealActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
18 NavigationDrawerFragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
19 KeywordDealActivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
20 FragmentTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
21 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
22 BackgroundLocationService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
23 ApplicationInstance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
11

List of Tables
3.1 Auto-generated les in an Android Studio project . . . . . . . . . . . . . . . . . . . . 38
4.1 API paths and their actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1 SWOT analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Time schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3 Tangible assets expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4 Intangible assets expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5 Direct expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 Direct expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.7 Indirect expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.8 Sinking fund calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.9 Total Product Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
12

Introduction
Topic
Comparison-shopping engines are also called shopping search engines, CSEs or shopping feeds.
As the name suggests comparison-shopping engines compare the prices on searched-for-products at
dierent stores online. They evaluate similar merchandise for the consumer and then recommend
corresponding links to consumers based on previously conducted searches. This is due to merchants
providing their product data feeds to the sites. Based on the product feeds submitted, comparison-
shopping engines can sort products in regards to price, shipping rates and seller ratings to make
it easy for consumers to compare products in one place { fast and easy. So for example if I am
searching for digital cameras, Google and other comparison engines show comparison pages, which
feature dierent sellers that also carry the product as well as price information: Consumers who
click on any of the listings will be directed to the seller's website. Each visit to your website will be
charged on a pay per click basis by the comparison-shopping engine.
Comparison-shopping engines have seen some major growth in the past few years due to the
fact that they are able to amplify ecommerce transactions. In 2012 alone, CSE trac increased by
56% and resulted in ecommerce revenues of over $1 trillion. Google Shopping, Shopzilla, Nextag,
Amazon Product Ads, Price Grabber and Bing are well-known examples amongst others.
Personal motivation
I have got motivated to start developing a product with this topic because our country does
not have a comparison-shopping engine rather just some libraries with products.
The desired outcome of a comparison shopping engine is for users to follow suggested links
and make a purchase from one of those links. The advantage of this for consumers is that they
can compare merchandise prices without having to perform extensive searches themselves in order
to decide where to buy a particular product. Comparison shopping engines are considered product-
specic search queries because they're designed to link users to specic online storefronts.
Retailers in many industries have seen an increase in website trac of up to 20% that can be
attributed to comparison-shopping engines. As mentioned above, online shoppers spend time online
to research and compare the products they want. As a matter of fact 65% of shoppers spend 15
minutes or more on comparing merchandise online. 94% of online shoppers are also investing time in
nding the best-priced product before they nalize a purchase. Consumers who are viewing products
on comparison-shopping engines are twice as likely to turn into a purchase. Ecommerce on CSEs is
also growing twice as fast as compared to overall commerce, with Amazon product ads being at the
top of the surge. Especially in the new age of enhanced campaigns and improved mobile targeting
possibilities, online retailers need to be aware of the fact that 31% of all smartphone owners tend to
shop with their phone. Moreover, July to December has seen a 67% increase in comparison-shopping
engine transactions on mobile devices.
How to get started Moldova Shopping Engine?
To get started on comparison-shopping engine I need to create an excel le or product data
13

feed that contains all of the product information that I want to provide to the shopping channels.
Dierent comparison sites will have dierent requirements for the feed format. Once I will have the
data feed aligned, all I need to do is to upload it to the CSE I want to create.
Moldova Shopping Engine is a cloud based mobile application for enhancing the shopping
experience for users on the go. My application can recommend best oers in nearby stores, deals and
most searched products based on your location. Project uses highly scalable and ecient Amazon
services like SQS and SNS for ensuring high availability. For notications, I have used Google Cloud
Messaging for real time service. In this project I am using REST API for providing responses
from backend ElasticSearch engine scanning through high amount of geocoded deals data ensuring
minimum response time for users. With this application users now have a power to reach beyond
just an conventional shopping application. By registering as a merchant in the app and user can
start own business or boost an existing one.
Moldova Shopping can collect data directly from merchants. Retailers who want to list their
products on the website then supply their own lists of products and prices, and these are matched
against the original database. This is done by a mixture of information extraction, fuzzy logic and
human labour.
Comparison sites can also collect data through a data feed le. Merchants provide information
electronically in a set format. This data is then imported by the comparison website. Some third
party businesses are providing consolidation of data feeds so that comparison sites do not have to
import from many dierent merchants. Aliate networks aggregate data feeds from many merchants
and provide them to the price comparison sites. Many of the popular shopping websites provide direct
aliation to the customer who wants to become aliate partner. They provide their own API to
the aliate partner to show their products with specications to the aliate partner's website. This
enables price comparison sites to monetize the products contained in the feeds by earning commissions
on click through trac. Other price comparison sites have deals with merchants and aggregate feeds
using their own technology.
In recent years, many o the shelf software solutions have been developed that allow website
owners to take price comparison websites' inventory data to place retailer prices (context adverts)
on their blog or content the only website. In return, the content website owners receive a small share
of the revenue earned by the price comparison website. This is often referred to as the revenue share
business model.
Another approach is to crawl the web for prices. This means the comparison service scans retail
web pages to retrieve the prices, instead of relying on the retailers to supply them. This method is
also sometimes called 'scraping' information. Some, mostly smaller, independent sites solely use this
method, to get prices directly from the websites that it is using for the comparison.
However, some combination of these two approaches is most frequently used. Some search
engines are starting to blend information from standard feeds with information from sites where
product stock-keeping units are unavailable.
Empirical projects that assessed the functionality and performance of page-wise SSC engines
exist. These studies demonstrate that no best or parsimonious shopping bot exists with respect to
price advantage.
14

1 Description and Analysis of the Domain
This chapter is intended to examine the purpose and objectives of this project, analyze the
existing solutions and similar products, as well as describe the development environment. The main
purpose of this project is:
{ to ease data analysis for people whose searches for products yield massive amounts of data
or need some kind of pattern recognition with which an uninitiated human brain could cope with;
{ to lower costs on such kinds of searches, by eliminating the need of implementing complex
software to analyze the data;
{ to provide an easy way for those interested in a search engine eld to help and learn.
The arguments that support the choice of the theme and application are presented below.
1.1 Purpose and objectives of the project
For a person at least slightly interested in buying something worth here in Moldova, not very
much is happening. This means that the Internet remains the main source for those who want to
buy something cheap, good, and wothy of trust. For these people, a this project could well be the
best way to "taste" from the process of engine search. While answering the people's questions, this
person, the volunteer, will learn the types of data with which the people are working, the types of
problems they encounter. After this, the volunteer would decide if they want to pursue search in this
eld, does it live up to his expectations and is it worth it pursuing this kind of career. But, being a
part of the process, the part of the discovery, the volunteer would be eager to continue helping other
product teams in their search. Search Engine projects are the most accessible way to help progress
happen in places where the amount of data is overwhelming, and the processing of it – costly or time
consuming. This project is exactly the application such a volunteer would be interested in. It would
represent a collection of products with problems ready to be indexed in the further shopping engine
to be developed, and discoveries to be made.
It must be known that search is heavily based on constant nancing. Financing product search,
on the other hand, is rarely a priority in many countries, especially those like Moldova. This product
is aimed on aiding product search by providing a much cheaper alternative – building an application.
This is a one time investment which could potentially save plenty of resources, or redirect them for
further search. While developing an application is still quite costly, it is cheaper that nancing a
search in a traditional manner – by spending many hours analyzing the data with a team of searchers,
or by spending many hours on building a specialized software to analyze the data. This software
also needs to be coached on "training" data – already solved examples so the software can "learn"
what needs to be done. Coming back though, after building the application the only spending of the
search team would be maintenance of the application, which is much more cheaper than developing
it, and, after being built, is much more versatile than a specialized software, which leads well into
the next argument.
Even with the fast development of technology nowadays, the human brain remains unmatched
in it's
exibility, pattern recognition and solving of diverse problems. Surely the computers are much
faster at solving specialized problems, but take time to be programmed, debugged or "trained" for
15

the result one wants. Most of the time it is not suitable using such software for a search team with a
specic task, budget or time limit. In this context comes the amazing processing power of the human
brains by showing its superiority over the silicone crystals. In several sentences and a few examples
the human brain is ready to analyze and solve tasks that it had never encountered before. One may
argue that the human brain isn't as precise as a computer and there is place for mistakes. This is
totally true but any probability of a mistake can be drastically reduced if one example is solved by
several people. If the searcher needs the data to be very precise, the number of people solving the
same example would increase leading to a more precise answer. If the searcher needs as much data
to be processed as possible, to see the general image, less people will solve the same task, speeding
up the process.
Being versatile is very good, but if to consider that some projects are quite lengthy, creating a
software that specializes in solving these types of problems is probably a good idea. As mentioned
before, these kinds of software need "training" – a set of solved examples so that, based on these, the
software can start search new products. And, of course, the more training examples are provided –
the better. Using the examples ranked by the search engines, people can train the software without
much fuss. In this way, the user does not need to generate the found products by himself, because
he has a database full of found examples. This project may be considered the intermediate step
between a product team analyzing all the data by themselves and the data being entirely analyzed
by a computer. In the future, ideally, these kinds of tasks will be solved solely using computer
software, but this will come only with advancements in pattern recognition software and machine
learning. For now, this project is envisioned to help product projects analyze their data and speed
up the training process of the software that could analyze the data by itself.
These days, keeping track of the political and economical situation in the world, probably
has the same importance as keeping track of the problems and news in the product community.
Discoveries in dierent science elds not only deepen the understanding of the world we live in,
but also make our life better. This needs to be brought to the knowledge of the public. Science is
all about curiosity, but sadly all the curiosity and attention are directed to the new and expensive
mini-computers in our pockets. By providing a direct way through which people can talk to the
population, through these attention-sucking devices for example, the situation may become better.
It is well known that general public must be able to understand the basics of science to make
informed decisions. Perhaps the best example of the negative consequences of poor communication
between people and the public is the issue of climate change. A variety of factors, not the last being
a breakdown in the transmission of fundamental climate data to the general public, has contributed
to widespread mistrust and misunderstanding of people and their search. The issue of climate change
also illustrates how the public acceptance and understanding of science (or lack of understanding)
can in
uence governmental decision making with regard to regulation, science policy and funding.
However, the importance of eective communication with a general audience is not limited to such
polarized issues like climate change. It is also critical for a vast variety of complex and socially charged
neuroscience issues such as the genetic basis for a particular behavior, the therapeutic potential of
stem cell therapy for neurodegenerative diseases, or the use of animal models { areas where the
public understanding of science can also in
uence policy and funding decisions. Furthermore, with
16

continuing advances in individual genome sequencing and the advent of personalized medicine, more
non-people will need to be comfortable parsing complex product information to make decisions that
directly aect their quality of life. Being a mobile application, this project would be very accessible
to any person with a smartphone (everyone these days) and would greatly increase the number of
informed non-people, thus eectively communicating science.
1.2 Existing solutions and similar products
This project's seems to be new in our country in the sense that there is no similar implementa-
tions such as Google Shopping Engine, each with its own similarities and dierences from the project
described in this paper. The short descriptions of these products are presented below.
Google Shopping Engine is the largest and most popular platform for shopping engine. This
search is made possible by volunteers of people around the world who come together to assist product
searches. The goal of the Google Shopping Engine project is to enable search that would be possible,
or practical, otherwise. Google Shopping Engine search results in new discoveries, datasets useful to
the wider search community, and many publications.
The user does not need any specialized background, training, or expertise to participate in any
Google Shopping Engine projects. It is made easy for anyone to contribute to real academic search,
on their own computer, at their own convenience.
The user is able to study authentic products of interest gathered by searchers, like images of
faraway galaxies, historical records and diaries, or videos of animals in their natural habitats. By
answering simple questions about the images, the user can help contribute to the understanding of
the world, the history, the Universe, and more. With the wide-ranging and ever-expanding suite of
projects, covering many disciplines and topics across the sciences and humanities, there's a place for
anyone and everyone to explore, learn and have fun in the Google Shopping Engine.
Google Shopping Engine is an Android application that can be downloaded for free in the An-
droid Market. It focuses on a specic Search Engine project called, unsurprisingly, Google Shopping
Engine. To understand how galaxies have formed, astronomers need the user's help to classify them
according to their shapes. If the user is quick, he may even be the rst person to see the newest
galaxies that are asked to classify. The images come from telescopes including Hubble and the Sloan
Digital Sky Survey. This app caches several subjects locally so the user can classify even while oine
and have the classications automatically uploaded later.
The Google Shopping Engine project is now arguably the world's best-known online Search
Engine project, and is certainly the one with the largest number of publications based on citizen
people input. The success inspired the creation of The Google Shopping Engine[1], hosting project
using the same technique across many search areas. The project started back in July 2007, with a
data set made up of a million galaxies imaged by the Sloan Digital Sky Survey, who still provide
some of the images until today. With so many galaxies, it was assumed it would take years for
visitors to the site to work through them all, but within 24 hours of launch the creators of the
project were stunned to be receiving almost 70,000 classications an hour. In the end, more than 50
million classications were received by the project during its rst year, which contributed by more
17

than 150,000 people.
That meant that many dierent participants saw each galaxy. This is deliberate; having mul-
tiple independent classications of the same object is important, as it allows the creators of the
project to assess how reliable their results are. For example, for projects where there are only a few
thousand galaxies but it is mandatory to be sure they're all spirals before using up valuable telescope
time on them, there's no problem | use those that 100% of classiers agree are, for example, spiral
galaxies. For other projects, the creators may need to look at the properties of hundreds of thousands
of galaxies. In those cases, in the nal result will be used those galaxies that a majority of users say
are spiral galaxies.
If to compare the application envisioned in this project with the Google Shopping Engine
project , the last is a web page application which limits it's usability to a personal computer or a
laptop. Of course, the web page can also be visited from a smartphone, but the experience would be
less immersing. More often than not, the companies prefer to develop an Android application than
upgrade their web pages to work well with a mobile device (Facebook, YouTube). This project's
application strives to be a mobile version of the Google Shopping Engine project web page. Ideally,
this project could unite people and volunteers from dierent product elds, just like in the Google
Shopping Engine project, promoting exchange of knowledge, or even the creation of a community of
productally aware citizen, actively participating in the development of science. The main objective in
this project is to develop an Android application for people to use anywhere, provided a smartphone
and a connection to the Internet, while bored or stuck in trac.
Search engines are normally used to nd information or web sites, but webometric investigations
use them for quantitative data such as the number of pages matching a query and the international
spread of those pages. For this type of application, the accuracy of the hit count estimates and
range of URLs in the full results are important. Here, we compare the applications programming
interfaces of Google, Yahoo! and Live Search for 1,587 single word searches. The hit count estimates
were broadly consistent but with Yahoo! and Google reporting 5-6 times more hits than Live Search.
Yahoo! tended to return slightly more matching URLs than Google, with Live Search reporting
signicantly fewer. Yahoo!'s result URLs included a signicantly wider range of domains and sites
than the other two and there was little consistency between the three engines in the number of
dierent domains. In contrast, the three engines were reasonably consistent in the number of dierent
top-level domains represented in the result URLs, although Yahoo! tended to return the most.
In conclusion, quantitative results from the three search engines are mostly consistent but with
unexpected types of inconsistency that users should be aware of. Google is recommended for hit
count estimates but Yahoo! is recommended for all other webometric purposes.
The growing information science eld of webometrics is concerned with nding and measuring
web based phenomena drawing upon informetric techniques . Although specialist research web
crawlers are sometimes used to collect data analysed , commercial search engines are the only choice
for some applications , especially those needing information from the whole web rather than just
from a limited set of web sites . Other elds, such as corpus linguistics , also sometimes use search
engines for research purposes.
A fundamental problem with scientic uses of commercial search engines is that their results
18

can be unstable and their algorithms are not fully documented in the public domain. Previous studies
comparing search engines have discovered limited overlaps between their results as well as signicant
international biases in coverage and ranking. As an extreme example, the results on the rst page
have a very small overlap: a comparison of Live Search, Google, Yahoo! and Ask Jeeves found that
84.9% of the combined results for a query (sponsored and non-sponsored links) were unique to only
one search engine .
Many previous search engine studies have taken the perspective of the typical user, assessing
the value, freshness and/or completeness of the information returned or the overlap between the
results of multiple search engines . In contrast, the webometrics community tends to employ the hit
count estimates or URLs returned in search engine results to analyse web structure or to generate
other meta-information such as concerning the international spread of ideas on the web (see review
below). Unfortunately, webometric investigations using only one search engine are vulnerable to
accusations that their results may be dependant upon the particular search engine used. This paper
assesses the extent to which search engine results in webometric investigations are engine-dependent
through a comparison of the results across a set of queries.
Search Engines and Web Crawlers
Modern commercial search engines are highly complex engineering products designed to give
relevant results to users. Here, the concept of relevance is negotiated between engineers and mar-
keters, but implemented by engineers. Although the exact details of search engines' methods are
commercial secrets, especially concerning results ranking, their mode of operation is broadly known.
In terms of the results delivered, there are three key operations: crawling, results matching, and
results ranking.
The crawling process involves identifying, downloading and storing in a database as many
potentially useful web pages as possible, given constraints of time, bandwidth and storage. This
is the key mediator between the pages that exist on the web and the pages that the search engine
\knows about". Crawlers nd new pages primarily by following links on known pages but also
through user-submitted URLs. No search engine is able to download all pages it nds and so needs
to have criteria to decide which to ignore. These criteria may include simple rules such as a maximum
number of pages to download per web site, as well as complex criteria in an attempt to ignore pages
in large databases and other \spider traps". An additional important factor in the coverage of any
search engine is historical: probably about half of the pages in a search engine's database cannot
be found by following links from the main web sites but can be found from the engine's `memory'
of previously visited pages. A consequence of all historical and technical dierences in crawling is
that search engine databases may have surprisingly little overlap. The second key operation, results
matching, is the process by which a search engine identies the pages in its database that match
any user query. In theory this is straightforward, but in practice it is not. For instance the search
informetrics does not result in a list of all pages containing this word in an engine's database.
The parser program that extracts words from the web pages HyperText Markup Language may
fail to identify some words due to incorrect or complex HTML or because the page that is longer
then the maximum size parsed.
The major search engines return a maximum of 1000 results per query. A search engine's
19

database may not be fully searched either because insucient time is available during busy periods
or because the database is split into dierent pieces and the engine's internal logic has not invoked
all pieces for a particular query, e.g., because there are too many results.
The most serious issue, however, is ltering. Because most searchers view only the rst two
pages of results , it is important to maximise the chance that a relevant URL is listed amongst the
rst 10. As a consequence, the rst URLs returned should all be dierent from each other to avoid
redundancy of information. On the web there are many pages that are duplicates of each other and
the engine will attempt to identify this and return only unique pages. In addition, the engine needs
to avoid returning pages that are too similar, for the same reason, even if the near-duplicate pages
are on dierent web sites. It seems that search engines use algorithms that do not compare all pairs
of pages based upon their full text because this would take too long. Instead, they use heuristics
based upon seeking duplicate strings of characters or sets of words, which is much faster but is highly
error-prone. Moreover, page similarity may not only be judged by comparing the pages but possibly
also by comparing the snippets created from pages to be presented to the user. These snippets are
normally created from the pages' titles and phrases around the word(s) searched for. Hence pages
that are `locally similar' in this sense may be judged eectively duplicates and all except one removed
from the search engine results. The eect of this and the other two factors above is that the number
of pages returned by a search may be signicantly lower than the actual number of matching pages
in the database .
Results ranking is the third key operation. A search engine will arrange the matching URLs
to maximize the probability that a relevant result is in the rst or second pages. The rank order
depends upon many factors including the extent to which the search terms are important and occur
frequently in the page, whether previous searchers have selected the link and how many links point
to the pages. Hence the rst few pages are a deliberately biased sample of all the results and the
same is true of the top n results for any n less than the total number of results returned.
Finally, although search engines are entirely logical because they are computer programs, their
complexity means that the results they present often have inconsistencies and unexpected variability.
For example, the hit count estimates may
uctuate, even over short periods of time , and individual
URLs may unexpectedly disappear from the results. Moreover, the specic workings of a search
engine may have apparently strange peculiarities. For example Live Search hit count estimates seem
to approximate \relevant pages" when over 8,000 but to re
ect \. . . without too many pages from
the same site" when less than 200. Webometric applications
In webometrics, the most common form of data used from search engines is the hit count
estimate (HCE), a number near the top of the results page estimating the total number of results
available to the search engine. Multiple HCEs are sometimes used in research for comparisons. For
example, using advanced queries the number of pages linking to each of a set of countries could
be compared to see which country had the most inlinks { the highest online impact. Alternatively
the frequency of occurrence of a key phrase such as \integrated water resource management" across
international domains could be compared via the HCEs of a series of searches. Hit counts are also
sometimes used to estimate the number of links or colinks between all pairs of web spaces in a set,
such as biotechnology organisations' Web sites, with the resulting matrix of data used to create a
20

network diagram or other visualisation. In order for the results of any of the above applications to
have validity for comparisons, it is desirable for there to be a high correlation between the results
of the same queries submitted to search engines (i.e., convergent validity). As discussed in the
introduction, previous studies have suggested that the overlaps between search engines are relatively
small, at least for queries with fewer results than the maximum imposed by any of the search engines
compared. Despite the low overlap between search engine result lists, their hit count estimates can
correlate highly with each other. For example, an investigation into the number of pages in 9,330
university web sites found Spearman's rho values from 0.822 to 0.917 between Google, Teoma, MSN
, and Yahoo!, with Google and MSN returning estimates about three times larger than the other
two search engines. From these ndings, it seems reasonable to average the HCEs of multiple search
engines to get the most reliable results, but only if no engine has a demonstrable bias.
A second type of data used from commercial search engines used in webometrics is a complete
list of URLs matching a query, with the list being subsequently processed to extract summary statis-
tics, such as the number originating from each Top Level Domain. In such cases it is reasonable from
a validity perspective to ask whether the summary statistics produced are signicantly dependant
upon the engine used for the data, e.g., whether the results from dierent engines would highly
correlate.
Research Objectives
A previous paper has examined Live Search, Yahoo! and Google from a webometric perspective
and addressed the question of how to get the most accurate and complete results from each individual
engine. Nevertheless, it did not compare these search engines against each other to discover the best
and to give external checks of accuracy and coverage. The overall goal of this follow-up research is to
assess the extent to which the results returned by the main three search engines used in webometrics
are consistent with each other in terms of the conclusions that would be drawn from their data. More
specically, the following questions are addressed.
Are there specic anomalies that make the HCEs of Google, Live Search or Yahoo! unreliable
for particular values?
How consistent are Google, Live Search and Yahoo! in the number of URLs returned for a
search, and which of them typically returns the most URLs?
How consistent are the search engines in terms of the spread of results (sites, domains and
top-level domains) and which search engine gives the widest spread of results for a search?
Note that the questions are not expressed in the form of a simple hypothesis test. It is a priori
almost certain that there will be highly signicant correlations between the search engines, so this
is not an appropriate test. Moreover, an interpretive method to evaluate whether the search engine
choice aects likely conclusions from research is also not the goal here because the objective is to cast
light upon the issue in general. Hence the research questions are designed to support a data-lead
discussion of the key issues.
Data
A list of 2,000 words of varying usage frequency was used as the set of queries. The words
were extracted primarily from blogs using selection criteria based purely upon word frequency. Due
to the data source used, there is a bias towards words in English language blogs. Many of the
21

words are spelling mistakes or unusual names. Each of the 2,000 words was submitted to Google,
Windows Live, and Yahoo! During May and June of 2007 via their Applications Programming
Interfaces (APIs), which allow automatic query submission and are commonly used in webometric
investigations, although they may give fewer results and estimates than the normal web interfaces.
For each query and each engine the rst page HCE and the set of up to 1,000 URLs returned were
recorded. A manual comparison of the results was undertaken afterwards and it was discovered that
some of the words were not being searched for in the expected way, yielding errors or mismatched
results. To resolve this problem, all words containing non-alphanumeric characters were removed
(mainly hyphenated words and words containing an apostrophe). The remaining data set of 1,587
words was analysed. Note that the API estimates, like those of the standard web interfaces, are often
rounded to one or two signicant gures when the size of the estimate is large.
Hit count estimates
The hit count estimates of Google, Yahoo! and Live search correlate signicantly, with Google
and Live Search having a particularly high value but with Yahoo! correlating less with both Google
and Live Search. The reason for the dierent Yahoo! results was that Yahoo! automatically corrected
some apparent user errors: either typos , or merged words in 15 cases. An investigation of the results
showed that the uncorrected and corrected search terms were found in dierent pages, so Yahoo! was
apparently searching both. Note also the odd gaps around 4,000-10,000 results for Google , 150-600
for Live Search , and 3,000-8,000 for Yahoo! . On average, Yahoo!'s estimates were about six times
larger than those of Live Search and Google's were about ve times larger than those of Live Search.
Hit count estimates of the three search engines compared. Number of URLs returned report
the number of URLs returned for a query. In theory, these graphs should also be approximately
straight lines since the search engines report similar hit count estimates and should return as many
URLs as their estimate, or the maximum of 1,000 if the estimate is higher than 1,000. In contrast,
whilst there are clusters at the bottom left hand corner and top right hand corner of each graph, as
expected, the graphs are otherwise quite scattered. The clusters along the top or right-hand edges
of a graph indicate cases where one search engine has frequently reported the maximum number of
results and another has reported signicantly less. Although it is not surprising that this sometimes
happens, it is clear from the right hand side clustering in contrast to the absence of clustering at the
top of that it is common for both Google and Yahoo! to return a maximum number of URLs when
Live Search returns less.
The data in represent the number of unique domains extracted from the list of URLs returned
from each search. The graphs should be approximately straight lines, assuming that each search
engine returns URLs equally spread around dierent web domains. There is inevitably a cluster
around the origin (mainly for searches returning few URLs) and a weak linear pattern at the bottom
left hand corner of each graph, but there is an overall scattered pattern in all the graphs. Hence the
number of dierent domains represented in the results of any given search will vary greatly by search
engine. The dense cloud near indicate that Yahoo! often returns results from about 800 dierent
domains when Google only returns results from between 300 and 700 domains, or when Live Search
returns results from between 400 and 900 domains. Similarly, from Live Search tends to return more
dierent domains in its results, at least for queries for which Google includes at least 300 domains.
22

Overall, however, Yahoo! tends to return the largest number of domains in its results URLs, at least
for queries that match URLs in many dierent domains.
Number of Sites returned
The data is the number of unique sites extracted from the list of URLs returned from each
search. Here a site is equated with the domain name ending of an URL. For most domains this is
the end of the domain name including two dot-separated segments. For example www.microsoft.com
{ microsoft.com and uk.groups.yahoo.com { yahoo.com. For sites with second-level domain name
systems, such as ac.uk in the UK or edu.ph in the Phillipines, the site is the domain name end-
ing including three dot-separated segments. For example, www.admu.edu.ph { admu.edu.ph and
www.scit.wlv.ac.uk { wlv.ac.uk. The same patterns are evident. This suggests either that search
engines treat web sites similarly to domains, or that the results contain few multiple-domain web
sites (e.g., university web sites, blog and social network sites).
Number of TLDs returned
The data represented is the number of unique top-level domains extracted from the list of URLs
returned from each search. Since most TLDs[2] approximately equate to countries, this is also a test
of the internationally spread of the results of the search engines. The graphs show that they are
approximately the same in this regard, but a linear regression with an intercept set to zero indicated
that Yahoo! returns about 10% more TLDs than the other two search engines.
Comparison within results
It illustrate the relationship between the hit count estimates, the number of URLs returned (in
black, mostly above the other points), the number of unique sites returned in the result URLs (in
light grey, mostly in the middle of the graphs), and the number of unique TLDs returned in the result
URLs (in dark grey, near the bottom of the graphs underneath the line y=100). The graphs echo
the data and to some extent the results , but present a new perspective. Google's graph is probably
the only one that is as might be expected: the number of URLs returned approximately corresponds
to the HCE until the HCE reaches 1,000, when the number of URLs returned is mostly above 950,
although, surprisingly, it is not always at 1,000, even for large HCEs. The occasional dark dots
within the middle indicate that some searches with large HCEs return substantially less than 1,000
matching URLs. Although not clearly visible on the graph, the number of TLDs returned reaches a
peak at a HCE of 5,000 and then stays approximately constant around an average of 25. The Live
Search graph shows a smooth relationship between HCEs and URLs except for a cluster at around
850 URLs. Live Search seems to stick at about 850 URLs even for HCEs of up to 5,000. Moreover,
the line below 850 is not as smooth as that of Google. The TLDs returned peaks at an average of
about 30 at a HCE of 10,000 but then declines, with the last 12 being 20 or under. The Yahoo!
graph is quite dierent to those of Google and Live Search. The slope of the HCEs for up to 1,000
results is the least smooth, suggesting that the Yahoo! HCEs may be the most approximate. The
TLD pattern is broadly the same as Live Search but Yahoo! peaks at about 50,000 with an average
of about 35 before declining to an average of around 20. The `stalactite' at about 20,000-50,000
results from 800-1,000 in the URL data is strange: it suggests that a HCE of 20,000-50,000 is often
a misleading estimator of the available results.
Comparison of statistics within each search engine (logarithmic x-axis scale).
23

The research has some limitations, which should be taken into consideration. First, recall that
15 Yahoo! results are very large in comparison to those of the other search engines due to Yahoo!
automatically correcting hypothesised typos. This small number of potentially spurious data points
does not aect the overall interpretation of the results, however. The search terms used are an
important limitation. These are all words written in alphanumeric characters and the results may be
dierent for non-ASCII languages such as Japanese and Arabic. It is also possible that other types
of search, such as multiple-word searches, search phrases and advanced searches could give dierent
results. This would be especially likely if any or all of the search engines used dierent algorithms
and datasets to respond to dierent types of query. The biggest limitation of this research is that
search engine algorithms change frequently and so it is not known for how long the results will be
valid. Nevertheless, the graphical methods introduced here can be repeated periodically to reassess
the ndings, for example before any future major webometric exercise. Finally, note that the results
are specic to the applications programming interfaces of the three search engines, which deliver
dierent results to the standard web interfaces. The ndings should therefore not be extrapolated
to the results of human web queries.
The graphs clearly show that the three search engines are reasonably consistent in their hit count
estimates and the number of dierent top-level domains in the URLs of their results. In contrast, they
have signicant inconsistencies for the number of dierent URLs, sites and domains returned within
the search results. Moreover, these inconsistencies sometimes manifest themselves in quite irregular
ways, and there are inconsistencies in Yahoo! and Live Search that make their hit count estimates
seem less reliable than those of Google. Based upon the above ndings, recommendations can now
be made about which search engine is the most suitable for various tasks. Recall that search engine
algorithms are updated regularly and so these recommendations need to be periodically checked and
revised. Google currently seems to be the most consistent in terms of the relationship between its
HCEs and the number of URLs returned, and so it is recommended for webometrics tasks when
consistent HCEs are needed. In contrast, Yahoo! is recommended if the (webometrics or general
search) objective is to get results from the widest variety of web sites, domains or TLDs. For the
latter tasks, other methods can sometimes also be used to obtain additional results. References
1.3 The development environment
During the development of the application, several Integrated Development Environments
(IDEs) and frameworks are planned to be used to accomplish the tasks set. There are several
cornerstone tasks that need to be fullled, namely: developing an Android app, creating an Appli-
cation Programming Interface (API) which would serve the data to the application and having a
database which would store the data as well as ensuring the communication between these elements.
For development of the Android app, Android Studio will be used. Android Studio is the
ocial Integrated Development Environment for Android app development, based on IntelliJ IDEA.
A positive side in using Android Studio is that it is designed specically for Android development,
coming with a lot of tools one will use in developing apps, like Android Software Development Kit
(Android SDK), a selection of tools including the Android platform itself, and the Android Virtual
24

Device – an emulator for testing the application.
While developing the API which would serve the data to the application, the PHP language
would be used. PHP is a widely-used open source general-purpose scripting language that is especially
suited for web development. The Symfony framework would be used because of it's exhausting
documentation, popularity among developers and it's reputation as being a stable environment and
recognized internationally. PHP Storm would be the IDE of choice for this project because of its
support for the Symfony framework and built-in developer tools such as Version Control Systems
integration. .
A challenge in developing the API is persisting the information into a database. Although the
Symfony Framework doesn't integrate any component to work with databases, it provides integration
with a third-party library called Doctrine. Doctrine's goal is to give the user powerful tools to
make database interactions easy and
exible. Doctrine ORM is a tool which can map objects to
a relational database such as MySQL. Using Object-Relational Mapping, or ORM, the properties
and relationships of the objects in an application can be easily stored and retrieved from a database
without writing SQL statements directly and with less overall database access code .
This chapter examined the arguments that support the choice of this project's theme, the
similarities and dierences between already existing products, as well as the development environ-
ment planned to be used while developing the application. The following chapter will discuss the
architectural planning of the system.
25

2 Analysis of the application from architectural point of view
To examine the application from an architectural prospective, one must rst view the appli-
cation as an information system. In this chapter, the main focus will be on modeling this system.
Modeling an information system is the practice of creating graphical representations, aiming to study,
document and describe it. Models, the name of these graphical representations, give the reader a
cross-section of the application for a better understanding the nal product. Models are used to show
the interactions between system components and are necessary to plan the further development of
the product. It is easier to spot a mistake on a model and correct it than building the app and only
then nding he error.
This chapter will focus on several such models to showcase dierent parts of the system and
show how dierent entities, classes or ever the software itself is planned to interact. To describe this
project, the following models were used:
{ Use Case model – describes the proposed functionality of a new system. A use case represents
a discrete unit of interaction between a user, human or machine, and the system. This interaction is
a single unit of meaningful work, such as "Create Account" or "View Account Details".
{ Activity model – used to model the behaviors of a system and the way in which these behaviors
are related in an overall
ow of the system. The logical paths a process follows, based on various
conditions, concurrent processing, data access, interruptions and other logical path distinctions, are
all used to construct a process, system or procedure.
{ Sequence model – a structured representation of behavior as a series of sequential steps over
time. It is used to depict work
ow, message passing and how elements in general cooperate over
time to achieve a result.
{ Database model – helps visualize the entities which store the data and the relations between
them. Also, the database model contains the attributes of the entities, as well as their types. The
types of relations between the entities are also stored in the Database model.
{ Deployment model – depicts the run-time architecture of a system. It shows the conguration
of the hardware elements (nodes) and shows how software elements and artifacts are mapped onto
those nodes. It also shows what hardware and software components were used to setup the whole
environment for designed system.
In this chapter, this project will be analyzed using the diagrams from above, to get a clearer
image about the system and ease further development. Modeling is imperative while creating an
application because by modeling one plans everything, so that later there will be less errors. It
should be obvious that the cost of an error on this stage of the development is far less that in further
stages. Following, the requirements of the system are analyzed.
2.1 Product and technical requirement
While developing a project, a set of requirements must be created which would act as check-
points, guiding the further development of the system. Product and technical requirements dene
the systemic and technical needs that a developer must keep in mind, to achieve the desired fea-
tures and functionality. Of course requirements are subject to change, so in the development process
26

they may vary. Nevertheless, a set of initial requirements is needed to dene the direction of future
development.
This project is required to be able to run on an Android device and connect to the API. After
logging or registering the user, he must be able to create a product, if the person in product is a
scientist. If the user is a user, he must be able to add any of the available products. The application
will need to persist all the new adds and products, updating the respective lists with the new entries.
All this can be systematized to the following list of requirements. The application must:
{ Run on a majority of Android devices (Android 4.0 or higher);
{ Be able to use an Internet connection to communicate with an API;
{ Allow being used by users and scientists;
{ Perform user logging and registering;
{ List the available products and adds;
{ Allow the user to create a product and persist it;
{ Allow the user to add a product and persist it;
{ Update the respective lists with new products or adds.
These are the initial requirements which, as mentioned, may be updated in favor of more
precisely dened ones. Future possible requirements are vastly dependent on the reviews and appre-
ciation of future users.
A possible future requirement might be to add forum-like features to the system, to promote
exchange of information between users and scientists, or between users themselves. A blog for
articles written about the successes and struggles of research teams may be another possible future
requirement. Lastly, a possible future requirement may be to gamify the experience for the users:
by implementing a reward system, setting goals and rewards for the most active users, the app may
become a popular "spend your time with purpose" type of game.
2.2 Examination of possible interactions with the system
In this section, Use Case diagrams are used to better understand the future functionality of the
system. Below, in Figure 2.1, are represented the use cases linked to account management.
This accounting practice management software is a comprehensive system, designed to meet
the needs of today's professionals. A proven product, AMS not only oers standard time and billing,
it helps you operate your entire practice at peak productivity with real-time access to essential rm,
sta, and client information. You can access your system at anywhere anytime to manage your
business at just your ngertips because accounting system is such an ease to use web base system.
27

Figure 2.1 { Use case diagram for account management
Users must log in to use the application in order to post a new product from a registered store.
Having an account will aid in keeping the user's information and facilitate the gamication process.
O
A possible rendering of the login use case would be the following: when starting the application,
the actor is shown the login screen with two text elds, and is prompted to ll in his email and
password. After lling in the necessary information, the actor presses the "login" button. If the
information matched an entry in the database, the actor would be presented with the main application
screen. If the information didn't match anything in the database, the user would be prompted to
enter his credentials again.
A possible rendering of the register use case would be the following: when starting the appli-
cation, the actor is shown the login screen where a "register" button can be found. When pressed,
the application loads the registration screen where the user is prompted to enter his email and a
28

password. After pressing the create account button, an account is created and the actor is presented
with the main application screen.
The main screen of the application is imagined as a screen with several tabs, just like in a
internet browser. Below, Figure 2.2 represents the use cases linked to the main application screen.
Figure 2.2 { Use case diagram for the main screen
By default, the "Browse result" tab would be the rst tab an actor can view. They would be
presented with a list of all active products, with the possibility to select any of them and see more
details about the selected product.
To view his products, the actor would be swiping right to land on the "my products" tab. Here
the actor would be presented with a list of products that he would have posted. Additionally the
actor would have the possibility to add a new product, by pressing the "add product" button.
Lastly, swiping another time to the right, the actor would nd himself on the "my prole" tab
where he would be able to visualize some statistical info about himself. The prole page might be
useful in the process of gamication of the application and could be used for setting goals, competing
with other users or receiving rewards. The application would provide full available information about
the selected product.
The scientist, on the other hand, could add a product by pressing the add product button
on the "my products" tab. The application would provide a form to create a new product. After
lling in the information, the scientist would save the product by pressing the "add product" button.
The application would persist the new product and update the lists of active products and personal
products. Just like a user, the scientist can view a product by tapping on it to reveal the full available
29

information about the selected product.
Another set of use cases for this project are those related to adding a product. Below, Figure
2.3 represents the use cases linked from Viewing items to payment process on the store provided.
Figure 2.3 { Online Shopping – Checkout, Authentication and Payment
To be able to view or add product, the actor must rst select and view a search, just as was
described before. When viewing a product, a list of products would be seen below.
Thus, a list of possible interactions was derived. Their implementation in the nal application
may be dierent, but will most probably contain the main use cases analyzed in this chapter.
2.3 Analysis of the dynamic aspects of the system
In the Figure 2.4, illustrated below, are represented the steps a registrated user will proceed
to buy a product. After starting the application, the actor would land on the login screen, where
he would be prompted to enter his credentials – his email address and password. To proceed the
user would need to press the "login" button. Depending on the correctness of the credentials and
the fact that such an email and password pair exists in the database, the access to the application
would be granted or not. If the access is not granted, a pop-up message would appear, prompting
the actor to type in his credentials again. If the access would be granted, the application would load
its main screen. To continue, the actor would need to swipe to "my product" tab where the list of
the actor's products would reside as well as the "add product" button. After pressing the button,
the application would present a new screen to ll in the relevant data such as the product itself, some
data or an image. To submit the new product, the actor would need to press the "add product"
30

button. If the product would not be successfully created, an error message would appear, prompting
the actor to try again. If the product creation succeeds, a message displaying product added would
appear and the process would be over.
Figure 2.4 { Activity diagram for online browsing
Now it is time to analyze the step by step process of how one could add a product. In the
Figure 2.5, illustrated below, are represented the steps a user would perform to add a posted product.
As in the case of Figure 2.4, the rst steps in the process of adding a product would be the logging
in process. After logging in the application, the actor would land on the main application screen. To
proceed, the actor would swipe to the product tab to nd a list of available products. After selecting
a product to add, the actor would tap the product to view it. On the newly appeared screen, the
actor would press the "add" button and would ll in his add. The next step would be to press the
"submit" button. If the add was not successfully added, an error message would appear, prompting
the actor to try again. If the add was successfully added, a message displaying add added would
appear and the process would be over.
31

Figure 2.5 { Activity diagram for adding a product
32

2.4 Study of object interactions in time
Modeling the system using sequence diagrams means to show graphically the interactions in
time between dierent elements of a system. A sequence diagram can show the
ow of messages and
data between dierent objects, such as presenters, views and entities storing data. To illustrate the
communication between these elements, the use case of selecting a product was analyzed.
Consider the actor who landed on the main application screen and switched to the "products"
tab. The user would like to view a product so he taps one. This causes the activity that controls
the view, the MainActivity, to trigger it's onClickListener and send the position argument – the
position in the list of the product the actor clicked on. Then, the product's id is found and an
intent is created, having in it the productId. The MainActivity starts the productDetailActivity
and sends the intent, thus sending the productId within it. Moving on to the productDetailActivity,
the activity now needs to communicate with the productService, which handles the connection to
the API. By calling the productService's getproduct method the activity passes the productId to the
latter. Having the productId, the productService may now communicate via HTTP with the API and
retrieve the necessary information. Having retrieved the necessary information, the productService
returns a product object back to the productDetailsActivity. But to display the view, the list of all
adds for the product is needed. So, the Activity once again calls a method of the productService
class, called getproductadds to receive the product's adds. The class once again communicates with
the API and returns a list of adds. Now, the productDetailsActivity has all the data to render the
view on the screen, so the view is rendered and the user can now see the full information about the
selected product and all the adds of this product.
The following Figure 2.6 shows how the aforementioned adding process has bee implemented
in the application.
Figure 2.6 { Adding products by adding the store
33

In Figure 2.7 are presented the elements which would communicate in the system for the select
product use case. It showcases the interactions between Views, Activities and the API, which may
be considered as elements of the Model-View-Presenter[3] architectural pattern.
Figure 2.7 { Sequence diagram for selecting a product
The following Figure 2.8 shows how the Search bar has been implemented in the program itslef.
Figure 2.8 { Search bar with category implementation
2.5 Denition of data storing entities
The Physical data model is a visual representation of how the data will be stored in a relational
database. Together with providing an understandable visual abstraction of the database structure,
34

this model can be used to directly generate the database schema for a database management system.
The richness of the meta-data included in the model is why direct conversion is possible.
Below, in Figure 2.9 is presented the Physical database model of the application. The database
would contain 3 tables. The User table would store the users and researchers which would use the
application. Their emails and passwords would be stored to create an user account. When logging
in the application, this table would be queried to nd the email-password pair that the user would
provide.
The product table would contain all the products posted in the application. Together with the
product data, a reference to the user who asked the product would be stored in the table, as a foreign
key. This table would be queried when the application would need the list of all products, or when
the list of the user's products is needed.
The add table would persist the adds submitted by the users to add the products. Of course,
as a foreign key, a reference to a product must be persisted, so that the application can display the
adds for a selected product. Together with the add, a reference to the user who asked the product
would also be stored in the table, as a foreign key. When showing a product, the application may
need to show the adds linked to that product, so it would query the add table to nd the adds with
that product id.
To conclude, the database model must add to an application's needs. This model will suit well
the rst iteration of this project, persisting the main entities to which the application may refer to.
In further development it may be needed to expand the model, adding more attributes to existing
tables or more tables to the existing model.
Figure 2.9 { Database diagram
35

2.6 Planning of the distribution of software elements
A deployment diagram is one that depicts the physical layout of a system. The diagram models
the execution architecture of the application, showing the hardware elements on which the software
artifacts are deployed. Their interactions are saved as deployment relationships, which describe how
the nodes of the application communicate.
Below, in Figure 2.10 is presented the deployment diagram of the application. The three nodes
of the system are represented by the Smartphone device, the API server device and the Database
server device
The Smartphone device would be the device running the application. Taking this into consid-
eration, the smartphone must be a device capable to run Android OS, presumably version 4.0 or
later. The application would also be designed to run on this version of the OS.
The API server could be represented by a notebook with the latest Windows OS running on
it. Together with the OS requirement, the communication between the API and application should
be through HTTP requests. If speaking about future development, the device and OS do not really
matter for the API. The main requirement for this node is the Internet connection and the possibility
of HTTP communication with the application.
The Database server could be represented by the same notebook, but this is not necessarily a
requirement. Any database management system[4] that could communicate with the API and persist
the application's data would do. The development of the API server and Database server should not
be considered part of the application, but still need to be discussed..
Figure 2.10 { Deployment diagram
In this chapter, several projections of the future application were made, to better understand
how the system would work and to plan how the application would be implemented. In the next
chapter, the development process of the application will be discussed, as well as the implementation
methodologies used in the project.
36

3 Implementation and development methodologies
This chapter presents the implementation and development methodologies of this project. In
the development process of this project, the Model-View-Presenter (MVP) architectural pattern was
used. The players in this architectural pattern are:
{ The Model: responsible for managing data;
{ The View: responsible for presenting data in a way decided by the presenter;
{ The Presenter: responsible for querying the model and updating the view, reacting to user
interactions and updating the model .
Further in this chapter are presented the steps performed to setup the developing environment
as well as how to run one's rst project in Android Studio. The parts of the system responsible for
managing the data (the Model), as well as the classes which represent the View and Presenter parts
of the pattern, are also discussed below.
3.1 Conguring the project
Before starting an Android Studio project, several steps must be performed rst. Both Java
Development Kit (JDK) from Oracle as well as Android Studio must be installed. While installing
Android Studio, the program will set up everything one needs to be able to do Android development.
After, the installation program will guide the user through several steps like conguring the memory
for the virtual device and installing Android SDK. In Figure 3.1 is shown the initial Android Studio
menu where one can select to start a new project, open an existing one or import an existing project.
If the new project button is clicked, the user is prompted to enter the application's name, the
company domain and project location. On the next screen the user must congure the types of
Android devices on which the application will run. Depending on the targeted market, one must
choose between phone and tablets, TV and wear. This project was targeted towards Android phones
and tablets, so "phone and tablets" was chosen. Also at this step, it is required to select the minimum
SDK { the set of tools available for the developing process. If to select the oldest Android API, the
application will run on any devices, but the tools that are available for developing will be very limited.
If to choose the latest API, the developer will have a wide range of tools at his disposal, but only
a few of the devices on the market will be supported. Usually choosing "API 15: Android 4.0.3"
is a safe bet. But for this project a minimum SDK of "API 10: Android 2.3.3" was chosen, to t
the devices had while developing the application, which meant less tools to work with but better
integration with existing devices.
37

Figure 3.1 { Android Studio welcoming screen
Setting this lets Android Studio set up and generate a new project. A few of the most important
folders and their description are listed in Table 3.1 .
Table 3.1 { Auto-generated les in an Android Studio project
Folder Descriptyion
MyApplicationProject/ The entire project context
.idea/ Contains the specic meta-data stored by Android Studio
MyApplication/ The actual project
MyApplication/build/ The build outputs are here
MyApplication/lips/ Contains private libraries
MyApplication/src/ Contains all code and resource les for the module
gradle Describes how Android Studio communicates with the gradle
External Libraries A place where referenced libraries are shown
To run this project there needs to be performed one more step – to create an activity. By going
to File New Activity Gallery, the menu from Figure 3.2 will appear. Here one can choose any
activity template. Android Studio will create the necessary classes by itself.
38

Figure 3.2 { Creating a new activity menu
Now it is possible to build and run this trivial application. By going to the route Run Run
application a list of devices will appear, some of them real physical devices and some of them { virtual
machines emulated on the computer. After selecting a suitable device and running the application,
the Figure 3.3 shows a screenshot of the device. These are the main basic steps one must perform
to set up and build one's rst Android project.
Figure 3.3 { Example Android application
39

3.2 Managing the data
This section examines the challenges encountered in the development process of the Presenter
part of the system, as well as the techniques and tools used.
The building blocks of an Android application can be considered activities. An activity rep-
resents one discrete action that an user can do, something like an use case. Usually, all activities
interact with the user, so the Activity class takes care of creating a window in which the programmer
can place the user interface. While activities are often presented to the user as full-screen windows,
they can also be used in other ways: as
oating windows or embedded inside of another activity.
While running the application, activities are managed as an activity stack. If a new activity starts,
it is placed on the top of the activity stack and is now the running activity. The previous activity is
now below it in the stack, and will not appear on the foreground again until the user exits the new
activity. Another attribute of an activity are it's states. An activity has essentially four states. If
an activity:
{ Is in the foreground of the screen (at the top of the stack), it is active or running;
{ Has lost focus but is still visible (that is, a new non-full-sized or transparent activity has
focus on top of your activity), it is paused;
{ Is completely obscured by another activity, it is stopped;
{ Is paused or stopped, the system can drop the activity from memory by either asking it to
nish, or simply killing its process. In this project, activities represent the building blocks of the
application. They were used to implement the application screens such as the login screen or the
main screen of the application.
To provide on overview of this project, Figure 3.4 shows the activity map of the application.
From the start of the application to the end of it, the arrows show the possible routes the user could
take to reach a certain screen.
Individual activities communicate with intents. Intents are asynchronous messages which allow
activities to send or receive data from each other. In case an activity needs to know some data from
the previous screen, it will read it from the intent which is sent to it by the previous activity.
Figure 3.4 { Activity map of the application
40

The Figure 3.5 shows the states an activity can be in. The ovals are major states the activity
can be in. The square rectangles represent callback methods a programmer can implement to move
the activity between states.
Figure 3.5 { Activity state paths
In Figure 3.6 we provide UML class diagram which shows a domain model for online shopping.
The purpose of the diagram is to introduce some common terms, "dictionary" for online shopping
– Customer, Web User, Account, Shopping Cart, Product, Order, Payment, etc. and relationships
between. It could be used as a common ground between business analysts and software developers.
Each customer has unique id and is linked to exactly one account. Account owns shopping
cart and orders. Customer could register as a web user to be able to buy items online. Customer is
not required to be a web user because purchases could also be made by phone or by ordering from
catalogues. Web user has login name which also serves as unique id. Web user could be in several
states – new, active, temporary blocked, or banned, and be linked to a shopping cart. Shopping cart
belongs to account.
41

Figure 3.6 { Class diagram for online shopping domain
Account owns customer orders. Customer may have no orders. Customer orders are sorted
and unique. Each order could refer to several payments, possibly none. Every payment has unique
id and is related to exactly one account.
Each order has current order status. Both order and shopping cart have line items linked to a
specic product. Each line item is related to exactly one product. A product could be associated to
many line items or no item at all.
The next Figure 3.7 shows the online shopping user account protocol state machine diagram
Every company having customers maintains customer accounts and supports a complete life
cycle of the account from its creation until it is closed. There are dierences in what are the stages
(states) in the account's life cycle, and what are conditions or events causing account to change its
state.
Here we provide an example of user account life cycle in the context of online shopping, shown
as UML protocol state machine diagram.
For the user account to be created, it has to meet some initial requirements. For example,
user id (used as a login name) must be unique, at least for the existing accounts. After account
was created, it might need to be veried. Verication depends on the company and could include
42

Figure 3.7 { State machine diagram user account protocol
e-mail, phone, and/or address verication. If account was not veried during some predened period
of time, that account could be moved to the suspended accounts.
New, active, or suspended accounts could be cancelled at any time by client's request. Note,
the precondition for this usually includes payment of any outstanding balances, and might require
some separate account state or substate to handle this case.
User account might be suspended for security reasons, manually or automatically. For example,
website intrusion detection system locks user account for predened period of time, if there were
several unsuccessful login attempts using incorrect account password. After account lock times out,
account is activated back automatically.
Some user accounts could be inactive for a long period of time. Company policy or business
rules could require moving such dormant for a year or two accounts to the suspended state.
Once we listed user account states and specied all possible transitions from one state to
another, we can review the diagram with other subject matter experts to see if anything is missing
or needs further clarications.
This next interaction overview diagram presented in Figure 3.8 is enclosed by sd frame (abbre-
viated form for all kinds of interaction diagrams). All non-control nodes of the diagram are references
to interactions – interaction uses.
43

Figure 3.8 { Interaction overview diagram
The Figure 3.9 represents the business
ow activity of order processing. Requested order is
input parameter of the activity. After order is accepted and all required information is lled in,
payment is accepted and order is shipped. Note, that this business
ow allows order shipment before
invoice is sent or payment is conrmed.
The states of a protocol state machine present an external view of the class that is exposed to
its clients. Depending on the context, protocol states can correspond to the internal states of the
instances as expressed by behavioral state machines, or they can be dierent.
The states of protocol state machines are exposed to the users of their context classiers. A
protocol state represents an exposed stable situation of its context classier: When an instance
of the classier is not processing any operation, users of this instance can always know its state
conguration.
44

Figure 3.9 { Business
ow activity diagram
The Figure 3.10 represents an object diagram which shows some runtime objects related to web
user login process. Class instance loginCtrl of the LoginController has several slots with structural
features of Integer and String types and corresponding value specications.The instance of Login-
Controller is also associated with instances of UserManager, CookieManager, and Logger. Login-
Controller, UserManager, and HibernateUserDAO (Data Access Object) share a single instance of
Logger.
Figure 3.10 { User login controller object diagram
UserManager has private attribute defaultURIs which is ordered collection (array) of 5 unique
45

Strings. Instance of the CookieManager[5] has two public structural features with specied values.
Most links are non navigable backwards.
The Figure 3.11 represents the component diagram for online shopping. The diagram shows
"white-box" view of the internal structure of three related subsystems – WebStore, Warehouses,
and Accounting. In UML Subsystem is a standard component stereotype for larger components,
usually containing some smaller components. WebStore subsystem contains three components related
Figure 3.11 { Component diagram example with three related subsystems
to online shopping – Search Engine, Shopping Cart, and Authentication. Search Engine component
allows to search or browse items by exposing provided interface Product Search and uses required
interface Search Inventory provided by Inventory component. Shopping Cart component uses Manage
Orders interface provided by Orders component during checkout. Authentication component allows
customers to create account, login, or logout and binds customer to some account.
Accounting subsystem provides two interfaces – Manage Orders and Manage Customers. Del-
egation connectors link these external contracts of the subsystem to the realization of the contracts
by Orders and Customers components.
Warehouses subsystem provides two interfaces Search Inventory and Manage Inventory used
by other subsystems and wired through dependencies.
This Figure 3.12 represents a deployment diagram which shows manifestation of components
by artifacts and internal structure of artifacts. I would call this kind of deployment diagrams mani-
46

festation diagrams or implementation diagrams as they actually do not show any deployments.
Figure 3.12 { Manifestation diagram for web application
Web application archive artifact book club app.war contains several les, folders and subfolders.
Stereotypes leandlibrary are standard UML stereotypes applicable to artifacts. This diagram
also shows non-standard stereotype folder which is rendered as package.
Several components are shown on the diagram manifested (implemented) by jar archive les.
In the Figure 3.13 is a representation of web application UML deployment diagram. Book club
web application artifact book club app.war is deployed on Catalina Servlet 2.4 / JSP 2.0 Container
which is part of Apache Tomcat 5.5 web server.
Apache Tomcat, often referred to as Tomcat Server, is an open-source Java Servlet Container
developed by the Apache Software Foundation (ASF). Tomcat implements several Java EE speci-
cations including Java Servlet, JavaServer Pages (JSP), Java EL, and WebSocket, and provides a
"pure Java" HTTP web server environment in which Java code can run.
Tomcat is developed and maintained by an open community of developers under the auspices of
the Apache Software Foundation, released under the Apache License 2.0 license, and is open-source
software.
Because Catalina is a Java class, if you enable Java Management Extentions (JMX) manage-
ment, you can actually manage all of Catalina's exposed functions as a single MBean, and reference
all its hierarchical elements by name. Apache maintains a list of all the MBean names as part of the
Tomcat documentation.
Catalina[6] is Tomcat's servlet container. Catalina implements Sun Microsystems's specica-
tions for servlet and JavaServer Pages (JSP). In Tomcat, a Realm element represents a "database"
of usernames, passwords, and roles (similar to Unix groups) assigned to those users. Dierent imple-
47

mentations of Realm allow Catalina to be integrated into environments where such authentication
information is already being created and maintained, and then use that information to implement
Container Managed Security as described in the Servlet Specication.
The book club app.war artifact manifests (embodies) OnlineOrders component. The artifact
contains three other artifacts, one of which manifests UserServices component.
The Application Server device (computer server) has communication path to Database Server
device (another server).
Figure 3.13 { Deployment diagram for J2EE web application
48

4 Aplication description
The Moldova Shopping Engine, can be installed by having the database connected to your
project and by using the apk to install it as a client application on your local virtual machine or
on the Android device. Below, the login activity will be examined. Several important methods
of the activity class are discussed, to better understand the main challenges encountered in the
implementation progress.
When programming an activity, it is necessary to implement the onCreate() method, to perform
the setup of the application.
The Figure 4.1 demonstrates the implementation of login activity.
Figure 4.1 { Login pop-up window process
Listing 1 shows how the onCreate() method is implemented in the login activity. After the
49

layout resource (the View) is loaded, the application will seek to nd the views on that layout.
When the views are found, the method sets the listeners, monitoring the user inputs.
1public class LoginActivity extends AppCompatActivity {
2
3 …
4
5 @Override
6 protected void onCreate ( Bundle savedInstanceState ) {
7 super . onCreate ( savedInstanceState ) ;
8 setContentView ( R . layout . activity_login ) ;
9 findViews () ;
10 setListeners () ;
11 }
12
13 …
14}
Listing 1 { LoginActivity – implementing onCreate method
The main task of an activity class, as a presenter, is to ll in the view with information and use
the data lled in the screen by the user. To do this, it rst needs to nd the views located on the
layout. Each button, text eld, or image, is considered to be a view and, when created, is given
an unique label. Using the built-in function ndViewById(), the activity can nd and point to the
views, utilizing them later. Because the MVP pattern stipulates that Views should only display the
data they are given, it is the job of the activity to listen for user input. After the views are found,
using the method setOnClickListener the activity are sets up to listen for user taps on the login or
register buttons. Below, Listing 2 shows how these methods are implemented.
1public class LoginActivity extends AppCompatActivity {
2
3 Button mLoginBtnView ;
4 EditText mEmailEditView , mPassEditView ;
5 TextView mErrorTxtView , mRegisterTxtView ;
6
7 @Override
8 protected void onCreate ( Bundle savedInstanceState ) { … }
9
10 private void findViews () {
11 mLoginBtnView = ( Button ) findViewById ( R . id . btn_login ) ;
12 mEmailEditView = ( EditText ) findViewById ( R . id . edit_email ) ;
13 mPassEditView = ( EditText ) findViewById ( R . id . edit_pass ) ;
14 mErrorTxtView = ( TextView ) findViewById ( R . id . txt_error ) ;
15 mRegisterTxtView = ( TextView ) findViewById ( R . id . txt_register ) ;
16 }
17
18 public void setListeners () {
19 mLoginBtnView . setOnClickListener ( new View . OnClickListener () {
50

20 @Override
21 public void onClick ( View v ) {
22 String pass , email ;
23 email = mEmailEditView . getText () . toString () ;
24 pass = mPassEditView . getText () . toString () ;
25 login ( email , pass ) ;
26 }
27 }) ;
28
29 mRegisterTxtView . setOnClickListener ( new View . OnClickListener () {
30 @Override
31 public void onClick ( View v ) {
32 Intent intent = new Intent ( LoginActivity . this ,
33 RegisterActivity . class ) ;
34 startActivity ( intent ) ;
35 }
36 }) ;
37 }
38}
Listing 2 { LoginActivity – nding views and setting listeners
If the user clicks the register button, an intent is created and the user is directed to the register
screen. If instead the user clicks the login button, the method login() is called. Login() will receive
as arguments the email and password entered by the user and will verify if the entries are valid. If
they are, the method will create an user object and ll it in, then will call the method that will
communicate with the server. If the response is okay, the login() method will continue to the main
activity. If not, the user will be prompted to retry. Below, in Listing 3 is presented the method
discussed before.
1public class LoginActivity extends AppCompatActivity {
2 @Override
3 protected void onCreate ( Bundle savedInstanceState ) { … }
4 private void findViews () { … }
5 public void setListeners () {
6 mLoginBtnView . setOnClickListener ( new View . OnClickListener () {
7 @Override
8 public void onClick ( View v ) {
9 String pass , email ;
10 email = mEmailEditView . getText () . toString () ;
11 pass = mPassEditView . getText () . toString () ;
12 login ( email , pass ) ;
13 }
14 }) ;
15 mRegisterTxtView . setOnClickListener ( new View . OnClickListener () {
…
16}) ;
17 }
18
51

19 /** Called when the user clicks the Send button */
20 public void login ( String email , String pass ) {
21 if (! email . isEmpty () && ! pass . isEmpty () ) {
22 User user = new User () ;
23 user . setEmail ( email ) ;
24 Intent intent = new Intent ( LoginActivity . this , MainActivity .
class
25);
26 intent . putExtra ( TAG_USER , user ) ;
27 startActivity ( intent ) ;
28 } else {
29 mErrorTxtView . setText (" Please try again ..") ;
30 mPassEditView . setText ("") ;
31 mPassEditView . requestFocus () ;
32 }
33 }
34}
Listing 3 { LoginActivity – logging in
When programming an activity, there are several steps that usually need to be performed:
{ Load the layout resource;
{ Locate the views;
{ Fill the views with information, or listen for user interactions;
{ Serve the layout with new data, or proceed to another screen.
A particular case of activities are fragments. Similar to an activity, a fragment represents an use
case: a piece of the application with which the user interacts. But unlike an activity, a fragment can
be part of another activity. The interactions with a fragment are done through a FragmentManager.
This is because a fragment's life cycle is closely related to the parent activity { if the activity gets
destroyed, all it's fragments are also destroyed. Another fact about fragments is that they can be
reused in several activities – like a smaller building block.
Fragments are used for a variety of things like menus, showing details or lists. In this project,
fragments are used to display lists with questions. In further code examples it is analyzed how with
the help of fragments, a list with questions can be made. Below, in Listing 4 is presented the code
discussed before.
1public class MainActivity extends AppCompatActivity {
2
3 @Override
4 protected void onCreate ( Bundle savedInstanceState ) { … }
5
6 public class DemoCollectionPagerAdapter extends FragmentStatePagerAdapter
7{
8 public DemoCollectionPagerAdapter ( FragmentManager fm ) {
9 super ( fm ) ;
10 }
11
52

12 @Override
13 public Fragment getItem ( int i ) {
14
15 Fragment fragment = null ;
16 switch ( i ) {
17 case 0:
18 fragment = new QuestionsListFragment () ;
19 break ;
20 case 1:
21 fragment = new MyQuestionsListFragment () ;
22 break ;
23 case 2:
24 fragment = new MyProfileFragment () ;
25 break ;
26 }
27
28 return fragment ;
29 }
30 …
31 }
32}
Listing 4 { MainActivity – tabs and fragments
Listing 4 shows a part of the MainActivity, more specically the Pager class responsible for
tabs. Here, depending on the tab the user uses, a fragment must be loaded. The getItem() method
returns a fragment depending on the tab the user resides on. If, for example, the user resides on the
tab with all the questions, a new QuestionList fragment will be created. Continuing, in Listing 5 is
presented the onCreateView() method which is called when a fragment is created. onCreateView()
is called when the fragment is ready to draw its user interface for the rst time. The system nds
the layout linked to the questions list and in
ates it, meaning that it will be the layout used by the
fragment. onCreateView() now must return the view in order to draw the UI.
1public class QuestionsListFragment extends Fragment {
2
3 ListView listViewQuestions ;
4
5 @Nullable
6 @Override
7 public View onCreateView ( LayoutInflater inflater , @Nullable ViewGroup
8container , @Nullable Bundle savedInstanceState ) {
9 View view = inflater . inflate ( R . layout . fragment_questions , null )
;
10 listViewQuestions = ( ListView ) view . findViewById ( R . id .
11listViewQuestions ) ;
12 return view ;
13 }
14 …
53

15}
Listing 5 { QuestionListFragment – onCreateView
Below, in Listing 6 is presented the onViewCreated() method. This method is called after the
fragment has initialized. A list of questions is received from question service which, with the help of
an adapter, populates the list. A listener is set up to monitor the taps of the user. If a question gets
selected, an intent is generated and the user is redirected to the question details screen.
1public class QuestionsListFragment extends Fragment {
2
3 ListView listViewQuestions ;
4 @Nullable
5 @Override
6 public View onCreateView ( LayoutInflater inflater , @Nullable ViewGroup
7container , @Nullable Bundle savedInstanceState ) { … }
8 @Override
9 public void onViewCreated ( View view , @Nullable Bundle savedInstanceState )
10{
11 super . onViewCreated ( view , savedInstanceState ) ;
12 List < Question > questions = QuestionService . getAllQuestions (1 ,3) ;
13
14 ListAdapter adapter = new ListAdapter ( getActivity () , R . layout .
15 list_item , questions ) ;
16 listViewQuestions . setAdapter ( adapter ) ;
17 listViewQuestions . setOnItemClickListener ( new AdapterView .
18 OnItemClickListener () {
19 @Override
20 public void onItemClick ( AdapterView <? > parent , View view , int
21position , long id ) {
22 Question question = ( Question ) parent . getItemAtPosition (
23 position ) ;
24 Intent intent = new Intent ( QuestionsListFragment . this .
25 getContext () , QuestionDetailsActivity . class ) ;
26 intent . putExtra ( QuestionDetailsActivity . TAG_QUESTION_ID ,
27 question . getId () ) ;
28 startActivity ( intent ) ;
29 }
30 }) ;
31 }
32}
Listing 6 { QuestionListFragment – onViewCreated
To generalize, fragments are a useful instrument to work with specic parts of the application. In
this application fragments are used:
{ As an interactive part of an activity;
{ To ll in the information to lists, with the use of list adapters;
{ To monitor user taps on questions and to redirect to other activities.
54

4.1 Presenting the data
This section discusses the challenges encountered in the development process of the View part
of the system as well as the techniques and tools used.
The layout is what denes the visual structure of a user interface, and by doing this, serves as
the UI for an activity. Layouts can be declared in two ways: either to declare UI elements through
XML or instantiate layout elements at runtime. Both ways have their own uses. In this application
the method of declaring UI elements through XML was chosen, to better separate the View and
Presenter parts of the MVP pattern. Another argument for this method was that there were no
elements that could only be implemented through runtime instantiation.
The view is basically the building block for user interface components. View is the base class
for widgets, which are used to create interactive UI components like buttons, images or text elds.
All of the views in a window are arranged in a single tree. Once a tree of views has been
created, there are typically a few types of common operations one may wish to perform:
{ Set properties: for example setting the text of a TextView;
{ Set focus: force focus to a specic view, by calling requestFocus();
{ Set up listeners: be notied when something interesting happens to the view;
{ Set visibility: hide or show views using setVisibility().
Every view supports their own variety of XML attributes. Some attributes are specic to a
view object like, for example, TextView supports the textSize attribute. Some are common to all
view objects like the ID attribute. Other attributes are layout parameters, which are attributes that
describe certain layout orientations of the view object.
Any view object may have an integer ID associated with it, to uniquely identify the view within
the tree. When the application is compiled, this ID is referenced as an integer, although the ID is
typically assigned in the layout XML le as a string. Setting the ID for a view will prove to be
very useful, because it is the easiest way to refer to it from an activity. A layout's job is to display
the information it is given. Where and how to display the information is usually provided by the
activity. Below, in several examples are discussed the basic tools used in layouts. Listing 7 illustrates
the views and layouts in an XML document responsible for the login page. Here layouts and views
are nested in a tree structure. Layouts may be considered the nodes of the tree while the views {
leaves. Each of them may have a plethora of attributes dening how they will look or behave on
the screen. One of the more important attributes is the ID, which as mentioned before, gives the
possibility to address the view from an activity.
1<? xml version ="1.0 " encoding =" utf -8"? >
2< LinearLayout … >
3
4 < ImageView … / >
5
6
7 < TextView … / >
8
9 …
55

10
11 < LinearLayout … >
12
13 < ImageView … / >
14
15 …
16
17 </ LinearLayout >
18
19 …
20
21</ LinearLayout >
Listing 7 { Activity login – tree structure
Below, in Listing 8 is presented the XML le for the main activity. On the main screen, the
pagerview is located { a view responsible for creating the tabs. The activity will manage what to
draw on each tab, depending on where the user is located. The layout does nothing in this regard.
1<? xml version ="1.0 " encoding =" utf -8"? >
2< LinearLayout xmlns : android =" http :// schemas . android . com / apk / res /
android "
3 android : layout_width =" match_parent "
4 android : layout_height =" match_parent "
5 android : background =" @color / colorBackground "
6 android : orientation =" vertical " >
7
8 < android . support . v4 . view . ViewPager
9 android : id =" @ + id / pager "
10 android : layout_width =" match_parent "
11 android : layout_height =" match_parent " >
12
13 < android . support . v4 . view . PagerTabStrip
14 android : id =" @ + id / tabStrip "
15 android : layout_width =" fill_parent "
16 android : layout_height =" wrap_content "
17 android : layout_gravity =" top "/ >
18
19 </ android . support . v4 . view . ViewPager >
20
21</ LinearLayout >
Listing 8 { Activity main – creating tabs
Here in Listing 9, an example of a fragment layout is presented. The question fragment layout
is quite simple, being responsible only for the listview. It occupies the whole fragment, but the
fragment itself will occupy only the space dened by the pagerview from Listing 8.
1<? xml version ="1.0 " encoding =" utf -8"? >
2< RelativeLayout xmlns : android =" http :// schemas . android . com / apk / res
56

/ android "
3 android : layout_width =" match_parent "
4 android : layout_height =" match_parent " >
5 < ListView
6 android : id =" @ + id / listViewQuestions "
7 android : layout_width =" match_parent "
8 android : layout_height =" wrap_content " / >
9
10</ RelativeLayout >
Listing 9 { Questions fragment – generating a list
The main activity window can be seen in the Figure 4.2 where all the categories are available
to be seen.
Figure 4.2 { Categories window
57

The Figure 4.3 show up the new product registration in the current application by adding a
store as its category holder, so that every product added will be linked to the specied store.
Figure 4.3 { Adding a product by adding a store with
Each screen in this app that is not the main entry point (all screens that are not the "home"
screen) should provide navigation so the user can return to the logical parent screen in the app
hierarchy by tapping the Up button in the app bar.
Below, Listing 10 shows the layout which is responsible for how the question looks in the list.
This is the layout which will be lled with meaningful data, with the help of the listadapter. The
adapter lls in the necessary data and each listitem is drawn in the listview.
58

1<? xml version ="1.0 " encoding =" utf -8"? >
2< LinearLayout xmlns : android =" http :// schemas . android . com / apk / res /
android "
3 android : layout_width =" match_parent "
4 android : layout_height =" match_parent "
5 android : orientation =" horizontal " >
6
7 < ImageView
8 android : layout_width =" wrap_content "
9 android : layout_height =" match_parent "
10 android : src =" @mipmap / ic_launcher " / >
11
12 < LinearLayout
13 android : layout_width =" match_parent "
14 android : layout_height =" wrap_content "
15 android : orientation =" vertical " >
16
17 < TextView
18 android : id =" @ + id / txtData "
19 android : layout_width =" wrap_content "
20 android : layout_height =" wrap_content "
21 android : fontFamily =" sans – serif "
22 android : textSize ="14 sp "
23 android : textStyle =" normal | bold " / >
24
25 < TextView
26 android : id =" @ + id / txtQuestion "
27 android : layout_width =" wrap_content "
28 android : layout_height =" wrap_content " / >
29
30 </ LinearLayout >
31</ LinearLayout
Listing 10 { List item – presenting the products
Typically, user controls are the basis for developing Web Parts during design time. This means that
the view logic is more commonly used in the user control and the user control is contained in the
Web Part. In the Partner Portal application, the Web Part gathers context that is then passed either
to the view (an instance of the user control) or directly to the presenter. In the case where the Web
Part does not contain a user control that implements the view, the Web Part implements the view
interface and directly interacts with the presenter.
The presenter only interacts with the view interface. This decouples the presenter from the
view implementation. The view is passed into the presenter when the presenter is constructed.
This approach is sometimes referred to as constructor injection. Because the view is passed to the
presenter, you can also provide a mock view for unit tests. The following code demonstrates the
constructor injection approach.
In the application, the View part of the MVP pattern is represented by layouts and views.
59

They:
{ Are responsible for outputting on the screen the information and data they are given;
{ Are saved in a tree like structure;
{ Can be in
uenced by attributes, one of the more important ones being the ID attribute.
In the Figure 4.4 is represented the view of the products after the search request occur.
Figure 4.4 { Products ltering after a seach request has occured
It is planed to create the dtSearch to support three types of search requests: An "any words"
search is any sequence of text, like a sentence or a question.
In an "any words" search, use quotation marks around phrases, put + in front of any word or
phrase that is required, and – in front of a word or phrase to exclude it.
An "all words" search request is like an "any words" search except that all of the words in the
60

search request must be present for a document to be retrieved.
A "boolean" search request consists of a group of words, phrases, or macros linked by connectors
such as AND and OR that indicate the relationship between them.
After you get the product needed you will have the posibility to make a choice between the
prices, reviews, specications as in the Figure 4.5.
Figure 4.5 { Multiple oers view
Here you are able to chose your store and desired price, and go to shopping cart inside the store
selected. The Figure 4.6 shows the Specications view designed for every product selected or found
after a search request.
61

Figure 4.6 { Specications view
4.2 Persisting the data
This section discusses the challenges encountered in the development process of the Model part
of the system as well as the techniques and tools used.
The Figure 4.7 demonstrates the recent price
uctuations so that you can choose a appropriate
time to buy or not the current product.
The Model part of the MVP pattern is represented by an API that persists and serves the
application with data. The API was implemented in Symfony, a PHP framework. Symfony is a
popular framework which performs well, has plenty of documentation and tutorials online, as well as
a thriving community of programmers all over the world .
The central objects of a Symfony API are controllers. Controllers are the basic functions that
62

Figure 4.7 { Price
uctuations view
read the request objects and serve the necessary information back in a response object. A controller
is the one that reads information the a request, loads a database resource or builds the response.
Either way, the return value of this function must be a response object.
To persist the data used by the application, a MySQL database was used. Instead of directly
writing SQL statements to interact with the database, a tool from Symfony was used { Doctrine
ORM. ORM stands for Object-Relational Mapping. Doctrine ORM[7] is a third-party library which
provides tools to ease interactions with databases. Doctrine lets the programmer to create PHP
objects which get transformed and persisted automatically, without any SQL.
Because the API needs to serve data for the application, a set of paths was developed to fulll
the application's needs. Below, in Table 4.1 are shown the paths this API uses.
63

Table 4.1 { API paths and their actions
HTTP Verb Path Controller Action
POST /users/user/register newUserAction save a new user
POST /users/user/login loginUserAction login a user
GET /users/user/:id getUserByIdAction return a specic user
GET /questions getQuesAction return all questions
GET /questions/user/:id getQuesByUserIdAction return question of a user
GET /questions/ques/:id getQuesById return a specic question
POST /questions/user/:id newQuesAction save a new question
GET /answers/answer/:id getAnsByIdAction return a specic answer
GET /answers/:id getAnsByQuesIdAction return answer for a question
POST /answers/:id/user/:id newAnsAction save answer for a question
The paths are presented in 3 groups, depending on the entity that they request. If a question
or set of questions is requested, or a new user is saved into the database, there should be a route and
a controller for that route.
HTTP communication is all about requesting an information and receiving a response. Con-
trollers are methods which specialize in serving specic requests. In Listing 11, an example of such
controller is presented. One can see that Doctrine is a powerful tool which even has built in abilities
to perform basic queries on the database without the need of programming it. So, after taking con-
trol of the Doctrine manager, such a query is used to receive a list of all questions which then gets
serialized and returned as a response back to the application.
1class APIController extends Controller
2{
3 …
4 /**
5 * @Route ("/ questions ")
6 * @Method (" GET ")
7 */
8 public function getQuestionsAction ()
9 {
10 $em = $this – > getDoctrine () -> getManager () ;
11 $questions = $em – > getRepository ( AppBundle : Question )
12 -> findAll () ;
13
14 if (! $questions ) {
15 throw $this – > createNotFoundException ( No questions found )
;
16 }
17
18 $data = [
19 questions = > $questions
20 ];
21
64

22 return new JsonResponse ( $data ) ;
23 }
24
25 …
26
27}
Listing 11 { API controller – getQuestionsAction
Listing 12 illustrates an entity class, of which the Doctrine ORM makes use when persisting to and
serving data from the database. As seen in Listing 11, many attributes or methods have annotations
{ special comments that are used for mapping information and validation conguration. The ORM
uses them to relate the attributes of the object to elds in the database tables and set up features
like primary key or auto-increment. The annotations can be used to link tables in relations. In the
referred listing, the user is a reference to the a User object. In the database, however, this relation
will be created using the primary key of the User table as the foreign key in the Question table.
1 /**
2 * @ORM \ Entity
3 * @ORM \ Table ( name =" question ")
4 */
5 class Question implements ArraySerializable
6 {
7
8 use ArraySerializableTrait ;
9
10 /**
11 * @ORM \ Id
12 * @ORM \ GeneratedValue ( strategy =" AUTO ")
13 * @ORM \ Column ( type =" integer ") */
14 private $id ;
15
16 /**
17 * @ORM \ Column ( type =" string ")
18 */
19 private $text ;
20
21 …
22
23 /**
24 * @ORM \ ManyToOne ( targetEntity =" User ")
25 */
26 private $user ;
27
28 …
29
30}
Listing 12 { API Entity – Question
65

The Model part of the MVP pattern is represented by the API which serves the application with
data. It uses:
{ A set of predened paths to communicate with the application;
{ Controllers to receive requests, and serve back responses;
{ An ORM tool to map objects into a relational database.
In this chapter, the application was analyzed from the implementation point of view. Here
were discussed the tools used, as well as which parts and how they interact within the system. In
the next chapter, an economical analysis will be performed to estimate the costs and prots of the
application.
66

5 Economic Analysis
The idea of this project is to develop an application that would ease people way of chosing the
right product needed when buying something around the internet. The projects also will provide an
easy way to visualize and buy a needed product. From the economical point of view, i think that
the companies using my product will benet from it since it will bring an nancial growth.
5.1 Project Description
Analyzing the product from an individual's point of view, this project represents a fast and
easy way to create a quick visualization of your products so you can go to the store knowing already
what you have to buy or just waiting home for delivery.
A Shopping Engine, is a positive advancement in technology. The uses for Shopping Engine
have not fully been explored. I denitely think that Shopping Engine technology can be benecial
and useful. I think that Shopping Engine technology can help a lot of people in certain elds, besides
mine is aiming, do their jobs a lot better. The main objectives of this project are:
{ To be able to interact with visual models
{ To be able to compare dierent products and their types
{ To get a better visualization of the environment
{ To increase productivity
{ To make it accessible for dierent user's needs
In order to form correct representation about future of this product, it should be inspected
in the expense way. In this chapter we will describe all costs and all salaries for each member of
the project. All deadlines and time schedules should be established, as well as the number of days
necessary to elaborate the project will be also discussed. Having all this data it will be much easier
to draw a conclusion which will tell us if the product will succeed or not with a higher probability.
5.2 Project time schedule
To start the development of this project it is preferable to set the correct time-of-development
boundaries. In order to elaborate the time schedule it is necessary to select the type of software
development. That's why Agile technology was chosen. This technology is preferable in the mean
of it's adaptivity and visibility throughout the whole development process. Through continuous
planning and a feedback loop, this development technique ensures that value is continuously maxed
in the process.The iterative stages of planning, research, development, testing and deployment provide
control over what and how everything is done, which suits well this project, as well as minimizing
the risks which come with an error in the initial stages of a waterfall cycle.
5.2.1 SWOT Analysis
Performing the SWOT analysis for any given system is an important step in predicting the
success or failure of the system. A SWOT analysis is a study that can identify the internal strengths
and weaknesses of a product, as well as its external opportunities and threats. In the table below
67

are presented the strengths and weaknesses, as well as the opportunities and threats of this project.
Combining them can dene the near future of the product and where developer should pay more
attention in order to secure the future threats from the market. By following these steps usefulness
of the product should increase.
A SWOT analysis session, as in Table 5.1 should always have a clear objective and it is the
Project Manager's responsibility to communicate that objective to all those present at the session. A
typical session will include all stakeholders, where possible, and key members of the project team. If
the analysis is being performed at the start of a project, the objective is likely to be fully identifying
all required activities and potential risks so that a proper plan can be put in place. However, if it is
being conducted during an ongoing project, the objective may be to re-assess the budget or schedule.
Table 5.1 { SWOT analysis
Strengths Weaknesses
{ High R&D;
{ Unique Product;
{ It can be used by everyone ;{ The product is developed by a small group
of individuals with not so much experience;
Opportunities Threat
{ Innovation;
{ Product and services expansion
{ Takeovers
{ It benets all stakeholders{ Product substitution;
{Possibility of having external changes(taxes).
As you can see here are few main options which can be highly eective during the deploy-
ment of the project on the market. If all the strengths and opportunities come together, the project
with high probability will be used by lots of people. In case if the weaknesses come into the project
deployment the interest will remain at the same level and not will be widely known. But there is
still a note that other products provide a little bit dierent functionality and are used in other tasks.
So that our product is secured by it's ambiguity.
Updating the SWOT table in the course of the development process of any project will show
the positive and negative trends and guide the development in the right direction. After deployment,
the SWOT analysis can easily help identify any threats or opportunities to improve the application.
Still the application should be developed in the way to make a decent product so it will be actual on
the market.
5.2.2 Time schedule establishment
When scheduling the development process of this project, necessary steps are taken into
account. At the beginning of development the planning stage should be taken in consideration so
all time boundaries would not be missed. Into this processes should be included things where main
ideas are born, pitched and sketched. After that comes the researching stage, where the general ideas
should be inspected and analyzed to choose the most ecient technologies on the market to be used
by developers. Then the developers come in. Their role is most important so they could implement a
product which will correspond the requirements determined in the previous steps. The testing stage
68

is required to check if the product is stable and can perform necessary tasks and comply with the
requirements. After all those steps the product can be deployed on the market and shipped to the
nal user.
Creation of the plan is one of the mostly crucial steps in development of the product. It
can structurize the time boundaries for each member in development of the product. A strict division
of the available time, as seen in the Table 5.2 is needed to minimize the possible "to the last minute"
work which usually induces plenty of errors. Each step in the development process has to have some
extra time to be reserved so each member would have some more space where he may stuck and
to not steal the time from other stages. In the table below are presented the general steps in the
development process of this product as well as the time needed to perform these steps. The people
involved are also listed, as follows: PM | project manager, SA | system architect, SM | sales
manager, D | developer.
Table 5.2 { Time schedule
Nr. Activity Name Duration (days) People involved
1 Market Research 6 PM, SM
2 Time & Task estimation 8 PM, SA, SM, D
3 Establish functional features 8 PM, SA
4 System Design 8 PM, SA, D
5 Elaborate Technical Requirements 10 PM, D
6 Mobile Application Design 10 PM, D
7 Development 170 D
8 Test the project functionality 15 D
9 Validate economical results 6 PM, SM
10 Write documentation 11 PM, D
11 Deploy the system 5 D
12 Commercialize the product 7 SM
13 Total time to nish the system 264
In this table are presented approximate time intervals where main development processes are
noted. In whole work
ow of the project the data in the table may change. Each member involved
in the development process is responsible for their respective stages. The total tome to elaborate
the project is estimated at 264 working days. Two or more members may work at the same topic
and in the same period of time so they should coordinate by the same time boundaries. Below are
indicated the amount of spent time for each individual:
{ Project manager: 67 days;
{ System architect: 24 days;
{ Sales manager: 23 days;
{ Developer: 243 days;
69

5.3 Economic motivation
In the development of the product it is good practice to economically motivate it, basing the
argument on the economical surroundings and predictions. But in the mean of low determination
in the market and high volatility of prices, previsioning the exact evolving of the product after the
release is quite challenging. The great part of those predictions available in this case are quite blurry.
If we consider this, it is necessary to select preferable methods of economical analysis, so the result
will predict economical success of the product. Next objectives summarize the stages that need to
be taken in order to obtain a desirable forecast:
{ To investigate all steps of business planning in the context on necessary marketplace.
{ To analyze the approaches of the economical contradictions.
{ To check calculation criteria, researching the protability and optimization of such business
plans.
{ To describe arguments sustaining the success of the project as well as investing thoughts in
possible risks and threats;
{ To go through all the practices of economical investigations for IT projects of the region.
This type of project can bring to the owner a reasonable amount of money, because this type
of project is needed on the market and the parts that have a specic interest in it are willing to
pay good money for it. The use of augmented reality immediately raises an e-commerce brand to
a completely new level. A customer who has tried Shopping Engine-enhanced shopping once will
look forward to other similar experiences and will rather prefer Shopping Engine-driven commerce
to traditional methods.
5.3.1 Tangible and intangible asset expenses
The budget of project is the crucial thing which makes the future boundaries of the
development. Because of the budget, project can be upgraded or degraded, depending on the funding.
If the number of funds is excessive the project can obtain greater amount of features or, in other
case, the project would miss some the required features. Other reason why project's budget is so
important, it provides the basis for project cost control. By measuring the project's actual cost
against the approved budget, you can determine if the project is progressing according to the plan
or if corrective action is needed. This accomplished using a cost baseline. In this section, the budget
will be dened and calculated so that we will have numbers to rely on in future. In the table below
are presented all the tangible assets used while developing this product. They are dened as the
physical items used in production, that can be seen in the Table 5.3 .
Table 5.3 { Tangible assets expenses
Material Specication Measurement unit Price per unit (MDL) Quantity Sum (MDL)
PC Dektop PC Unit 8381 1 8381
Total 8381
70

In the Table 5.4 are given intangible assets used while developing the project. Intangible
assets are combination of aspects which do not represent a physical form. Generalizing previous
words, the next table represents the software used while designing and developing product.
Table 5.4 { Intangible assets expenses
Material Specication Measurement unit Price per unit (MDL) Quantity Sum (MDL)
License Intellij Unit 6889 1 6889
License Intellij Unit 6100 1 6100
License Android SDK Unit 19487 1 19487
Total 22476
Last Table 5.5 in this section represents all direct expenses of this project. Those expenses
appeared during the work and cannot be attached in previous lists, because their values are not
included into the budget.
Table 5.5 { Direct expenses
Material Specication Measurement unit Unit Price, MDL Quantity Sum, MDL
Paper A4 500 sheets 75 1 75
Printer Device Unit 400 1 400
Pen Blue Pen Unit 5 10 50
Board White Board Unit 210 1 210
Marker White Board Marker Unit 20 8 160
Total 895
5.3.2 Salary expenses
In this section is discussed the salary of each member involved into the development of the
project. To begin, each worker has the daily payments in amount of
{ Project Manager: 700 MDL;
{ System Architect: 800 MDL;
{ Sales Manager: 300 MDL;
{ Developer: 750 MDL;
Proceeding from the number of working days of each member, the next Table 5.6 shows
the total salary for people involved in development.
71

Table 5.6 { Direct expenses
Employee Working days Salary per day (MDL) Salary fund (MDL)
Project Manager 67 700 33000
System Architect 24 800 35750
Sales Manager 23 300 8400
Developer 243 750 52000
Total 236950
After calculating total salaries, we can subtract Social Insurance which is 23% of the total
salary. Besides, 4.5% of the salary comes to medical insurance fund. Next we will compute the social
fund retrieval.
SI=FreTfs= 236950 0:23 = 54498 :50MDL; (5.1)
Here FS| means salary expense, Fre| is the salary expense fund and Tfs| is the tax for social
service. Now we will compute the medical insurance fund:
MI=FreTmi= 236950 0:045 = 10662 :75MDL; (5.2)
Where Tmi| is the medical insurance tax approved each year by law. The total work expense is
concluded in the sum of all previous equations.
WEF =Fre+SI+MI= 236950 + 54498 :50 + 10662 :75 = 302111 :25MDL; (5.3)
where WEF is the work expense fund, SIis the social insurance and MIis the medical insurance
fund.
5.4 Individual person salary
In this section we will calculate net salary for one of members of the project: developer.
Recalling that his salary is 750 MDL and he works for 243 days, the gross salary of the developer is:
GS= 750 243 = 162400 MDL; (5.4)
where GSis the gross salary in MDL. The current Pension fund tax is 6%, so now calculating:
PF= 162400 0:06 = 9744 MDL; (5.5)
Now calculating cost of medical insurance, which is 6% so it is equal to:
MIF = 162400 0:045 = 7308 MDL; (5.6)
Using this numbers, we can calculate the total taxed salary for the whole project's development
lifetime:
TS=GSPFMIF PE= 162400 9744730811280 = 134068 MDL; (5.7)
where TSis taxed salary, GSis the gross salary, SFis social fund and PEis personal exemption.
Today's personal exemption is 11280 MDL .
72

Now we must compute the total income tax. For incomes under 33000 MDL the tax is 7%. For
income under that sum, the tax is 18%.
IT=TSST= 33000 0:07 + (134068 33000) 0:18 = 2310 + 18192 :24 = 20502 :24MDL;(5.8)
where ITis the income tax, TSmeans taxed salary and STis salary tax. Using these numbers,
now we can obtain the net income of the worker.
NS=GSITSFMIF = 162400 20502 :2497447308 = 124845 :76MDL (5.9)
where NSmeans net salary, GSis the gross salary, ITis the income tax, SFis the social fund and
MIF is medical insurance fund.
5.4.1 Indirect Expenses
This section describes expenses like apartment rent, transport, electricity, Internet access and
water consumables, as seen in the Table 5.7.
Table 5.7 { Indirect expenses
Material Specication Measurement unit Price per unit (MDL) Quantity Sum (MDL)
Rent Oce Month 3000 12 36000
Electricity Union Fenosa KWh 2 2400 4800
Internet Moldtelecom Pack 230 12 2760
Water Apa-Canal m39.19 120 1259
Total 44662.8
5.4.2 Wear and depreciation
As an any product a software system should be analyzed in cases of wear and depreciation.
Depreciation is a primary factor that aects the value of a system, so, it needs to be taken into
account. Wear is a thing which also should be considered in our case and it will be calculated
further. We must carefully think about the depreciation as a linear process, and it will be computed
in the same degree as we did it in the previous steps.
Wear is calculated, relying on type of the resource. In my case i will talk about the pieces that
my computer needs in order to be able to work on my project without problems. So my hardware
pieces roughly will be useful for 3 to 2 years of use. On the other hand if to talk about intangible
assets we have the license for Android SDK that will expire in an year, exactly the period of my
project.
Bellow, as seen in the Table 5.8 is calculated the Sinking Fund of the PC
SF=8381
3365365 = 2793 :6MDL; (5.10)
Next we calculate the Sinking Fund of the Intellij IDE:
SF=6100
365365 = 6100 MDL; (5.11)
73

Next we calculate the Sinking Fund of the Android SDK:
SF=3444
365365 = 1722 MDL; (5.12)
Table 5.8 { Sinking fund calculation
No Resource Name Value, MDLExploitation period,
days Project durationSinking fund
,MDL
1 PC 8381 3365 365 2793.6
2 Intellij IDE 6100 365 365 6100
3 Android SDK 19487 365 365 19487
InputV alue is the total asset value, ExploitationPeriod means for how long the good is useful
to us. To calculate the Sinking Fund (SF) we have to take Input Vale(IV) divided by exploitation
period (EP) and multiply it by the Project duration(PD)
SF=IV alue
EPeriodPDuration (5.13)
5.4.3 Product Cost
This section represents the group of total calculations of all expenses. It includes product
costs, direct and indirect expenses so as salaries and wear. It is presented in the Table 5.9.
Table 5.9 { Total Product Cost
Expense type Sum (MDL) Percentage (%)
Direct expenses 695 0.18
Indirect expenses 44662.8 11.78
Salary expenses 263950 62.52
Asset wear expenses 30860 8.14
Social Insurance 78498.50 14.38
Medical Insurance 10662.75 2.81
Total product cost 500023.6 100
5.4.4 Economic indicators and results
Having all expenses calculated, we can now nd out the approximate price for the product on
the market. Our application is focused on shops and companies from Republic of Moldova . I intend
to sell the entire project to a company that is inclined to use it in its own purpose. In other words i
sell all the right to the buyer. I intend to sell the project for 818625 MDL (incl. VAT), Gross Price
(GP).
We are using the up-down method to caluculate the necessary indicators. First of all we
calculate the GI for the product adding TVA.
74

GI=NI+V AT = 818625 + 0 :2818625 = 1254900 MDL; (5.14)
Here GIis the gross income, NImeans the net price and ( V AT ) tax added to the gross price
of the price of product, which are 20%.
The GI price from sales will be 1254900 MDL , since its the whole project that i am selling.
Next we calculate the Gross Prot of the project which is the Price without V AT minus the total
cost (PC) supported during the entire project.
Gp=NIPC= 818625 500023 :6 = 385876 :4MDL (5.15)
Next we calculate the Net Prot (NP) of the project after the income tax (IT) of 12%.
NP=GpIT= 385876 :40:12385876 :4 = 340701 :12MDL (5.16)
Next we have to calculate Financial protableness (FP).
FP=NP
PC100% =340701 :12
500023 :6100% = 73 :23% (5.17)
5.5 Economic conclusions
In conclusion, in this chapter were discussed the main objectives, time schedules, some of prod-
uct strengths and weaknesses. Also were established prots and the total costs of this project. This
is a must chapter of every successful project. This research provides a good understanding of possible
obstacles and threats, which can be faced during the development's, deployment's and realization's
on the market, lifetimes of the product and a better arrangements in the future development.
Considering all gross and net prots we can say what to expect from possible prots and overall
expenses. The greatest part of all costs are project members payments, which is not surprising,
because of the amount of human work that should be done and intangible assets(software licenses)
as well as indirect expenses. Proceeding from these numbers, we can surely say that the prot will
cover all expenses. To do so we must introduce premium features and advertising.
It is important to note that the eect of Shopping Engine on the economy is inclined to grow in
the next years because of its constantly growth. However the impact of Shopping Engine will extend
beyond the economy, with experts predicting a range of social benets. Some of these social impacts
will have economic consequences, which may be accounted for in our estimates. However, there are
also benets to individuals and society that are not accounted for in our models, both tangible and
intangible. We leave the estimation of these eects to future research.
75

Conclusions
This thesis had a major impact in my future experiences as I have learned how to create a nal
product in order to be released on production. It implied a lot of time spending on nding the best
solution for my problem but it was worthy for.
Now-a-days nding the required information quickly and easily on the web remains a major
challenge, if the searcher has little prior knowledge of search strategies and search techniques of
search engines. Once the search is complete, Browse capabilities provide the user with the capability
to determine which items are of interest and select those to be displayed. So browse capabilities
plays a major role in information retrieval.
With the initiation of the Web and search engines, online searching has become a common
method for obtaining information. People search for information on a daily basis, for various pur-
poses. Searching is the second most common online activity after email. On a typical day more than
half of Internet users are searching the Internet using a search engine.
Web searching is an easy and convenient way to nd information. Web search provide searchers
with almost instant access to millions of search results, but the quality of the information linked
to by these search results is rough. Some of this information may be incorrect, or come from
unreliable sources. Today, So many search engines available on the Internet, such as Google, Yahoo,
Bing, AltaVista, MSN Search and Ice rocket. These search engines provide dierent features and
eciencies. Obviously, we can set a priority between this engines; now that is what I want to obtain,
to get a high priority for Moldova Shopping Engine while searching a product on our domestic stores.
Searching is one of the common tool for seeking online information. Search engines are the
resources that help the people to search any kind of information on the web in a simple and easy
way. The purpose of this study is to presents the extensive review and analysis of our local market
and examines the user behavior while interacting with the application developed in this project.
From my analysis of the local market products availability on the search engines, I conclude
that there is a need in creating a Comparison Search Engine for a better experience while shopping.
People like to search information on Google as it provides better interface, features and ease of use
to the users, but in our case it will not provide the all products needed, that is why there is a need
of a shopping engine so that people can get the best deals.
As nal thoughts I can express my gratitude to this project because I was able to nd a real
solution for a problem in our country and the future development of this application became a goal
of mine.
76

References
1Google Shopping Engine https://www.google.com/shopping?hl=en { Price Comparison Website
2Top Level Domain https://en.wikipedia.org/wiki/Top-level_domain
3MVP https://msdn.microsoft.com/en-us/library { The Model-View-Presenter Pattern
4DBSM https://www.studytonight.com/dbms { Database Management System
5CM https://developer.android.com/reference/android/webkit { CookieManager
6Tomcat Catalina https://www.mulesoft.com/tcat/tomcat-catalina { Catalina Servlet
7Doctrine ORM https://www.doctrine-project.org/ { Object Relational Mapper (ORM)
77

Appendix
I. 5.5 MainActivity
1package com . cloudcomputing . shopit ;
2
3import android . content . Context ;
4import android . content . Intent ;
5import android . content . SharedPreferences ;
6import android .os. Build ;
7import android .os. Bundle ;
8import android . support .v4.app . ActivityOptionsCompat ;
9import android . support .v7.app . AppCompatActivity ;
10import android . text . SpannableString ;
11import android . text . Spanned ;
12import android . text . style . ForegroundColorSpan ;
13import android . transition . Transition ;
14import android . transition . TransitionInflater ;
15import android . util . DisplayMetrics ;
16import android . util .Log ;
17import android . view . View ;
18import android . widget . Button ;
19import android . widget . FrameLayout ;
20import android . widget . TextView ;
21import android . widget . Toast ;
22
23import com. cloudcomputing . animation . Animation ;
24import com. cloudcomputing . models . ResultListener ;
25import com. cloudcomputing . networkcalls . Network ;
26import com. facebook . CallbackManager ;
27import com. facebook . FacebookCallback ;
28import com. facebook . FacebookException ;
29import com. facebook . GraphRequest ;
30import com. facebook . GraphResponse ;
31import com. facebook . login . LoginResult ;
32import com. facebook . login . widget . LoginButton ;
33
34import org. json . JSONObject ;
35
36import java . util . Arrays ;
37
38public class MainActivity extends AppCompatActivity implements ResultListener {
39
40 FrameLayout mErrorLayout ;
41 LoginButton mFacebookButton ;
42 Button mLoginButton ;
43 TextView mEmailTextBox , mPasswordTextBox , mSignUpTextView ;
44 public static String url = " http :// firstrestexample -env . elasticbeanstalk .com /
78

myhellocall / responsehello ";
45 private CallbackManager mCallbackManager ;
46 private SharedPreferences mSharedPreferences ;
47 public final String mSignupString = " Dont 'have an account .. SignUp here ";
48
49 @Override
50 protected void onCreate ( Bundle savedInstanceState ) {
51 super . onCreate ( savedInstanceState );
52
53 DisplayMetrics mDisplayMetric = getResources (). getDisplayMetrics ();
54 Constants . SCREEN_WIDTH = mDisplayMetric . widthPixels ;
55 Constants . SCREEN_HEIGHT = mDisplayMetric . heightPixels ;
56
57 mCallbackManager = CallbackManager . Factory . create ();
58 if ( Build . VERSION . SDK_INT >= 21) {
59 TransitionInflater inflater = TransitionInflater . from ( this );
60 Transition transition = inflater . inflateTransition (R. transition .
mainactivity_exit_transition );
61 getWindow (). setExitTransition ( transition );
62 }
63
64 setContentView (R. layout . activity_main );
65
66 mFacebookButton = ( LoginButton ) findViewById (R.id. facebookButton );
67 mLoginButton = ( Button ) findViewById (R.id. loginButton );
68 mEmailTextBox = ( TextView ) findViewById (R.id. emailTextBox );
69 mPasswordTextBox = ( TextView ) findViewById (R.id. passwordTextBox );
70 mErrorLayout = ( FrameLayout ) findViewById (R.id. errorLayout );
71 mSignUpTextView = ( TextView ) findViewById (R.id. signupTextView );
72 mSignUpTextView . setOnClickListener (new View . OnClickListener () {
73 @Override
74 public void onClick ( View v) {
75 startActivity (new Intent ( MainActivity .this , RegistrationActivity .
class ));
76 }
77 });
78 SpannableString spannableString = new SpannableString ( mSignupString );
79 spannableString . setSpan (new ForegroundColorSpan ( MainActivity . this .
getResources (). getColor ( android .R. color . holo_blue_dark )), 22, mSignupString .
length () , Spanned . SPAN_EXCLUSIVE_EXCLUSIVE );
80 mSignUpTextView . setText ( spannableString );
81
82 mErrorLayout . setOnClickListener (new View . OnClickListener () {
83 @Override
84 public void onClick ( View v) {
85 v. setVisibility ( View . INVISIBLE );
86 }
87 });
88 mFacebookButton . setReadPermissions ( Arrays . asList (" public_profile , email ,
79

user_birthday "));
89 mFacebookButton . registerCallback ( mCallbackManager , new FacebookCallback <
LoginResult >() {
90 @Override
91 public void onSuccess ( final LoginResult loginResult ) {
92
93
94 GraphRequest request = GraphRequest . newMeRequest ( loginResult .
getAccessToken () , new GraphRequest . GraphJSONObjectCallback () {
95 @Override
96 public void onCompleted ( JSONObject object , GraphResponse
response ) {
97 // Application code
98 Log.e(" LoginActivity ", response . toString ());
99 mSharedPreferences = getSharedPreferences ( Constants .
SHARED_PREFERENCES_NAME , Context . MODE_PRIVATE );
100 SharedPreferences . Editor mEditor = mSharedPreferences .
edit ();
101 mEditor . putString ( Constants . LOGIN_USER_ID , loginResult .
getAccessToken (). getUserId ());
102 mEditor . putString ( Constants . LOGIN_USER_TOKEN , loginResult
. getAccessToken (). getToken ());
103 mEditor . commit ();
104 gotoNextActivity ();
105 Toast . makeText ( MainActivity .this , response . toString () ,
Toast . LENGTH_LONG ). show ();
106 }
107 });
108 Bundle parameters = new Bundle ();
109 parameters . putString (" fields ", "id ,name ,email ,gender , birthday ");
110 request . setParameters ( parameters );
111 request . executeAsync ();
112
113
114 }
115
116 @Override
117 public void onCancel () {
118
119 Toast . makeText ( MainActivity .this , "FB login Cancel ", Toast .
LENGTH_SHORT ). show ();
120 }
121
122 @Override
123 public void onError ( FacebookException error ) {
124
125 Animation . ErrorLayoutAnimation ( mErrorLayout , getResources ().
getDimension (R. dimen . translate_left_right ));
126 Toast . makeText ( MainActivity .this , "FB login Error ", Toast .
80

LENGTH_SHORT ). show ();
127
128 }
129 });
130
131 mLoginButton . setOnClickListener (new View . OnClickListener () {
132 @Override
133 public void onClick ( View v) {
134
135 String query = Constants . GETLOGIN ;
136 String formattedQuery = String . format (query , mEmailTextBox .
getText (). toString () , mPasswordTextBox . getText (). toString ());
137 Constants . USERNAME = mEmailTextBox . getText (). toString ();
138 if (! mEmailTextBox . getText (). toString (). isEmpty () && !
mPasswordTextBox . getText (). toString (). isEmpty ())
139 Network . getInstance (). Login ( formattedQuery , MainActivity . this
);
140 else
141 Toast . makeText ( MainActivity .this , " Wrong username or
passoword ", Toast . LENGTH_SHORT ). show ();
142
143 }
144 });
145 }
146
147 private void gotoNextActivity () {
148
149 ActivityOptionsCompat activityOptionsCompat = ActivityOptionsCompat .
makeSceneTransitionAnimation (this , null );
150 startActivity (new Intent (this , MainScreen . class ), activityOptionsCompat .
toBundle ());
151 finish ();
152 }
153
154 @Override
155 protected void onActivityResult (int requestCode , int resultCode , Intent data )
{
156 mCallbackManager . onActivityResult ( requestCode , resultCode , data );
157 }
158
159 @Override
160 public void onResult ( boolean result ) {
161 if ( result )
162 gotoNextActivity ();
163 else
164 Toast . makeText ( MainActivity .this , " Wrong username or passoword ",
Toast . LENGTH_SHORT ). show ();
165 }
81

166}
Listing 13 { MainActivity
82

I. 5.5 MainScreen
1package com . cloudcomputing . shopit ;
2
3import android . app. ProgressDialog ;
4import android . content . Context ;
5import android . location . Location ;
6import android .os. AsyncTask ;
7import android .os. Build ;
8import android .os. Bundle ;
9import android . support .v4.app . Fragment ;
10import android . support .v4.app . FragmentTransaction ;
11import android . support .v4. view . GravityCompat ;
12import android . support .v4. widget . DrawerLayout ;
13import android . support .v7.app . AppCompatActivity ;
14import android . support .v7. widget . Toolbar ;
15import android . transition . Explode ;
16import android . view . Menu ;
17import android . view . MenuItem ;
18
19import com. cloudcomputing . fragments . Category ;
20import com. cloudcomputing . fragments . CategoryDeals ;
21import com. cloudcomputing . fragments . DealsFragment ;
22import com. cloudcomputing . fragments . EventFragment ;
23import com. cloudcomputing . fragments . MapDealFragment ;
24import com. cloudcomputing . fragments . MapFragment ;
25import com. cloudcomputing . fragments . MerchantDeals ;
26import com. cloudcomputing . fragments . PostDeal ;
27import com. cloudcomputing . fragments . WebFragment ;
28import com. cloudcomputing . models . onDrawerItemSelected ;
29import com. google . android .gms . common . ConnectionResult ;
30import com. google . android .gms . common .api . GoogleApiClient ;
31import com. google . android .gms . location . LocationServices ;
32
33
34public class MainScreen extends AppCompatActivity implements onDrawerItemSelected
, GoogleApiClient . ConnectionCallbacks , GoogleApiClient .
OnConnectionFailedListener {
35
36
37 DrawerLayout drawer ;
38 Toolbar toolbar ;
39 MainScreen mainScreen ;
40 private GoogleApiClient mGoogleApiClient ;
41
42 @Override
43 protected void onStart () {
44 super . onStart ();
83

45 mGoogleApiClient . connect ();
46 }
47
48
49 @Override
50 protected void onStop () {
51 mGoogleApiClient . disconnect ();
52 super . onStop ();
53 }
54
55 @Override
56 protected void onCreate ( Bundle savedInstanceState ) {
57 super . onCreate ( savedInstanceState );
58 Constants . init ();
59 mainScreen = this ;
60 if ( Build . VERSION . SDK_INT >= 21) {
61 Explode slide = new Explode ();
62 slide . setDuration (1000) ;
63 getWindow (). setEnterTransition ( slide );
64 }
65
66 if ( mGoogleApiClient == null ) {
67 mGoogleApiClient = new GoogleApiClient . Builder ( this )
68 . addConnectionCallbacks ( this )
69 . addOnConnectionFailedListener ( this )
70 . addApi ( LocationServices .API)
71 . build ();
72 }
73
74 setContentView (R. layout . activity_main_screen );
75 toolbar = ( Toolbar ) findViewById (R.id. toolbar );
76 setSupportActionBar ( toolbar );
77 drawer = ( DrawerLayout ) findViewById (R.id. drawer_layout );
78 NavigationDrawerFragment navigationDrawerFragment = (
NavigationDrawerFragment ) getSupportFragmentManager (). findFragmentById (R.id.
navigation_drawer_fragment );
79 navigationDrawerFragment . setUp (drawer , toolbar );
80
81
82 // changeFragment (0, Constants . GETDEAL_QUERY , "") ;
83
84 }
85
86
87 public void changeFragment (int position , int queryType , String categoryName )
{
88
89
90 Fragment frag = null ;
84

91
92 if ( Constants . isConsumer ) {
93
94 switch ( position ) {
95 case 0:
96 frag = new DealsFragment ();
97 break ;
98 case 1:
99 frag = new MapFragment ();
100 break ;
101 case 2:
102 frag = new Category ();
103 break ;
104 case 3:
105 frag = new MerchantDeals ();
106 break ;
107 case 4:
108 frag = new CategoryDeals ();
109 Bundle bundle = new Bundle ();
110 // bundle . putInt ( Constants . QUERY_TYPE , Constants .
GETDEAL_CATEGORY_QUERY );
111 bundle . putString ( Constants . QUERY_PARAMETER_CATEGORY ,
categoryName );
112 frag . setArguments ( bundle );
113 break ;
114
115 case 5:
116 frag = new MapDealFragment ();
117 Constants . keyword = categoryName ;
118 /* bundle = new Bundle ();
119 bundle . putString (" keyword ", categoryName );
120 frag . setArguments ( bundle );*/
121 break ;
122
123 case 6:
124 frag = new WebFragment ();
125 bundle = new Bundle ();
126 bundle . putString (" url ", categoryName );
127 frag . setArguments ( bundle );
128 break ;
129
130 case 7:
131 frag = new EventFragment ();
132 break ;
133
134 }
135 } else {
136 switch ( position ) {
137 case 0:
85

138 // frag = new MerchantOrders ();
139 frag = new PostDeal ();
140 break ;
141 case 1:
142 frag = new PostDeal ();
143 break ;
144
145 }
146 }
147 FragmentTransaction trans = getSupportFragmentManager (). beginTransaction
(). addToBackStack ( null );
148 trans . replace (R.id. container , frag ). commit ();
149 drawer . closeDrawers ();
150
151
152 }
153
154
155 @Override
156 public void onBackPressed () {
157 DrawerLayout drawer = ( DrawerLayout ) findViewById (R.id. drawer_layout );
158 if ( drawer . isDrawerOpen ( GravityCompat . START )) {
159 drawer . closeDrawer ( GravityCompat . START );
160 } else {
161 super . onBackPressed ();
162 }
163 }
164
165 @Override
166 public boolean onCreateOptionsMenu ( Menu menu ) {
167 // Inflate the menu ; this adds items to the action bar if it is present .
168 getMenuInflater (). inflate (R. menu . main_screen , menu );
169 return true ;
170 }
171
172 @Override
173 public boolean onOptionsItemSelected ( MenuItem item ) {
174 // Handle action bar item clicks here . The action bar will
175 // automatically handle clicks on the Home /Up button , so long
176 // as you specify a parent activity in AndroidManifest .xml .
177 int id = item . getItemId ();
178
179 // noinspection SimplifiableIfStatement
180 if (id == R.id. action_settings ) {
181 return true ;
182 }
183
184 return super . onOptionsItemSelected ( item );
185 }
86

186
187
188 @Override
189 public void fragmentFetcher (int position , int queryType , String categoryName )
{
190
191 changeFragment ( position , queryType , categoryName );
192 }
193
194
195 @Override
196 public void onConnected ( Bundle bundle ) {
197
198 if ( mGoogleApiClient . isConnected ()) {
199 new LocationFinder ( MainScreen . this ). execute ();
200
201 }
202
203
204 }
205
206 @Override
207 public void onConnectionSuspended (int i) {
208
209 }
210
211 @Override
212 public void onConnectionFailed ( ConnectionResult connectionResult ) {
213
214 }
215
216
217 class LocationFinder extends AsyncTask <Void , Void , Location > {
218
219 ProgressDialog mProgressDialog ;
220
221 public LocationFinder ( Context context ) {
222
223 mProgressDialog = ProgressDialog . show ( context , " Please Wait !", "
Getting your location ");
224 }
225
226 @Override
227 protected void onPreExecute () {
228 super . onPreExecute ();
229 }
230
231 @Override
232 protected Location doInBackground ( Void … params ) {
87

233
234 return LocationServices . FusedLocationApi . getLastLocation (
mGoogleApiClient );
235 }
236
237 @Override
238 protected void onPostExecute ( Location location ) {
239 super . onPostExecute ( location );
240
241 Constants . mLocation = location ;
242 mProgressDialog . cancel ();
243 changeFragment (0, Constants . GETDEAL_QUERY , "");
244 }
245 }
246}
Listing 14 { MainScreen
88

I. 5.5 SplashScreen
1package com . cloudcomputing . shopit ;
2
3import android . content . Context ;
4import android . content . Intent ;
5import android . content . SharedPreferences ;
6import android .os. Bundle ;
7import android . support .v7.app . AppCompatActivity ;
8
9import com. cloudcomputing . networkcalls . GooglePlayServiceHelper ;
10
11/**
12* An example full – screen activity that shows and hides the system UI (i.e.
13* status bar and navigation / system bar) with user interaction .
14*/
15public class SplashScreen extends AppCompatActivity {
16
17 SharedPreferences mSharedPreferences ;
18 GooglePlayServiceHelper mGooglePlayServiceHelper ;
19
20 @Override
21 protected void onResume () {
22 super . onResume ();
23 if( GooglePlayServiceHelper . mGoogleApiClient == null )
24 {
25 mGooglePlayServiceHelper = new GooglePlayServiceHelper ();
26 if( mGooglePlayServiceHelper . checkPlayServices ( this ))
27 {
28 mGooglePlayServiceHelper . buildGoogleApiClient ( ApplicationInstance
. getInstance ());
29 }
30
31 }
32 }
33
34 @Override
35 protected void onStart () {
36 super . onStart ();
37 if( GooglePlayServiceHelper . mGoogleApiClient != null )
38 {
39 GooglePlayServiceHelper . mGoogleApiClient . connect ();
40 }
41 mGooglePlayServiceHelper . mGoogleApiClient . connect ();
42
43
44 }
45
89

46 @Override
47 protected void onCreate ( Bundle savedInstanceState ) {
48 super . onCreate ( savedInstanceState );
49 setContentView (R. layout . activity_start );
50 if ( hasSharedPreference ()) {
51 // createShatedPreferences ();
52 startActivity (new Intent (this , MainActivity . class ));
53 } else {
54
55
56 startActivity (new Intent (this , MainScreen . class ));
57
58 }
59
60 finish ();
61 // Set up the user interaction to manually show or hide the system UI.
62
63
64 }
65
66
67 public boolean hasSharedPreference () {
68 mSharedPreferences = getSharedPreferences ( Constants .
SHARED_PREFERENCES_NAME , Context . MODE_PRIVATE );
69 return mSharedPreferences . getString ( Constants . LOGIN_USER_ID , null ) ==
null ;
70
71 }
72
73 public void createShatedPreferences () {
74 mSharedPreferences = getSharedPreferences ( Constants .
SHARED_PREFERENCES_NAME , Context . MODE_PRIVATE );
75 SharedPreferences . Editor mEditor = mSharedPreferences . edit ();
76 mEditor . putString ( Constants . LOGIN_USER_ID , "id");
77 mEditor . putString ( Constants . LOGIN_USER_TOKEN , " password ");
78 mEditor . commit ();
79 }
80
81}
Listing 15 { SplashScreen
90

I. 5.5 RegistrationActivity
1package com . cloudcomputing . shopit ;
2
3import android . app. ProgressDialog ;
4import android . content . BroadcastReceiver ;
5import android . content . Context ;
6import android . content . Intent ;
7import android . content . IntentFilter ;
8import android . content . SharedPreferences ;
9import android .os. Bundle ;
10import android . preference . PreferenceManager ;
11import android . support .v4. content . LocalBroadcastManager ;
12import android . support .v7.app . AppCompatActivity ;
13import android . util .Log ;
14import android . view . View ;
15import android . widget . Button ;
16import android . widget . EditText ;
17import android . widget . TextView ;
18
19import com. cloudcomputing .gcm . QuickstartPreferences ;
20import com. cloudcomputing .gcm . RegistrationIntentService ;
21import com. cloudcomputing . models . ResultListener ;
22import com. cloudcomputing . networkcalls . Network ;
23
24public class RegistrationActivity extends AppCompatActivity implements
ResultListener {
25
26 EditText mNameTextBox , mPasswordTextBox , mConfirmPasswordTextBox ,
mEmailTextBox ;
27 Button mOkayButton ;
28 TextView mWarningText ;
29 private BroadcastReceiver mRegistrationBroadcastReceiver ;
30 ProgressDialog mProgressDialog ;
31
32 @Override
33 protected void onCreate ( Bundle savedInstanceState ) {
34 super . onCreate ( savedInstanceState );
35 setContentView (R. layout . activity_registration );
36
37 mNameTextBox = ( EditText ) findViewById (R.id. nameTextBox );
38 mPasswordTextBox = ( EditText ) findViewById (R.id. passwordTextBox );
39 mEmailTextBox = ( EditText ) findViewById (R.id. emailaddressTextBox );
40 mConfirmPasswordTextBox = ( EditText ) findViewById (R.id.
confirmPasswordTextBox );
41 mOkayButton = ( Button ) findViewById (R.id. okayButton );
42 mWarningText = ( TextView ) findViewById (R.id. warningText );
43 mRegistrationBroadcastReceiver = new BroadcastReceiver () {
91

44 @Override
45 public void onReceive ( Context context , Intent intent ) {
46
47 SharedPreferences sharedPreferences = PreferenceManager .
getDefaultSharedPreferences ( context );
48 boolean sentToken = sharedPreferences . getBoolean (
QuickstartPreferences . SENT_TOKEN_TO_SERVER , false );
49 if ( sentToken ) {
50 Log .d(" Token Sent ", " Success ");
51 } else {
52 Log .d(" Token Sent ", " Fail ");
53 }
54 }
55 };
56
57
58 Intent intent = new Intent ( RegistrationActivity .this ,
RegistrationIntentService . class );
59 startService ( intent );
60
61 mOkayButton . setOnClickListener ( new View . OnClickListener () {
62 @Override
63 public void onClick ( View v) {
64
65
66 if ( mNameTextBox . getText () != null && mPasswordTextBox . getText ()
!= null && mConfirmPasswordTextBox . getText () != null
67 && mConfirmPasswordTextBox . getText (). toString (). equals (
mPasswordTextBox . getText (). toString ()) && ! mEmailTextBox . getText (). toString ().
isEmpty ()) {
68
69
70 if (! Constants . token . isEmpty ()) {
71 String signUp = String . format ( Constants . GETSIGNUP ,
mEmailTextBox . getText (). toString () , mPasswordTextBox . getText (). toString () ,
mNameTextBox . getText (). toString () , Constants . token );
72 Network . getInstance (). SignUp (signUp , RegistrationActivity
. this );
73 mProgressDialog = ProgressDialog . show (
RegistrationActivity .this , " Signing up", " Please Wait !");
74 }
75
76
77 }
78
79
80 }
81 });
82 }
92

83
84
85 @Override
86 protected void onResume () {
87 super . onResume ();
88 LocalBroadcastManager . getInstance ( this ). registerReceiver (
mRegistrationBroadcastReceiver ,
89 new IntentFilter ( QuickstartPreferences . REGISTRATION_COMPLETE ));
90 }
91
92 @Override
93 protected void onPause () {
94 LocalBroadcastManager . getInstance ( this ). unregisterReceiver (
mRegistrationBroadcastReceiver );
95 super . onPause ();
96 }
97
98 @Override
99 public void onResult ( boolean result ) {
100
101 mProgressDialog . cancel ();
102 if ( result ) {
103 Constants . USERNAME = mNameTextBox . getText (). toString ();
104 startActivity (new Intent ( RegistrationActivity .this , MainScreen . class )
);
105 } else {
106 mWarningText . setVisibility ( View . VISIBLE );
107 }
108 }
109}
Listing 16 { RegistrationActivity
93

I. 5.5 NoticationDealActivity
1package com . cloudcomputing . shopit ;
2
3import android .os. Bundle ;
4import android . support .v7.app . AppCompatActivity ;
5import android . support .v7. widget . LinearLayoutManager ;
6import android . support .v7. widget . RecyclerView ;
7
8import com. cloudcomputing . adapters . NotificationDealAdapter ;
9
10public class NotificationDealActivity extends AppCompatActivity {
11
12 RecyclerView mRecyclerView ;
13 NotificationDealAdapter adapater ;
14 LinearLayoutManager linearLayoutManager ;
15
16 @Override
17 protected void onCreate ( Bundle savedInstanceState ) {
18 super . onCreate ( savedInstanceState );
19 setContentView (R. layout . activity_notification_deal );
20 mRecyclerView = ( RecyclerView ) findViewById (R.id. deals );
21 adapater = new NotificationDealAdapter ( getApplicationContext () , Constants
. mNotificationDeals );
22 mRecyclerView . setAdapter ( adapater );
23 linearLayoutManager = new LinearLayoutManager ( getApplicationContext ());
24 mRecyclerView . setLayoutManager ( linearLayoutManager );
25
26 }
27
28}
Listing 17 { NoticationDealActivity
94

I. 5.5 NavigationDrawerFragment
1package com . cloudcomputing . shopit ;
2
3
4import android . content . Context ;
5import android . content . Intent ;
6import android . content . SharedPreferences ;
7import android .os. Bundle ;
8import android . support .v4.app . Fragment ;
9import android . support .v4. widget . DrawerLayout ;
10import android . support .v7.app . ActionBarDrawerToggle ;
11import android . support .v7. widget . LinearLayoutManager ;
12import android . support .v7. widget . RecyclerView ;
13import android . support .v7. widget . Toolbar ;
14import android . view . LayoutInflater ;
15import android . view . View ;
16import android . view . ViewGroup ;
17import android . widget . AdapterView ;
18import android . widget . Spinner ;
19import android . widget . TextView ;
20
21import com. android . volley . toolbox . ImageLoader ;
22import com. cloudcomputing . adapters . NavigationDrawerAdapter ;
23import com. cloudcomputing . adapters . SpinnerAdapter ;
24import com. cloudcomputing . animation . Animation ;
25import com. cloudcomputing . models . GenericModel ;
26import com. cloudcomputing . models . onDrawerItemSelected ;
27import com. pkmmte . view . CircularImageView ;
28
29import java . util . ArrayList ;
30
31
32/**
33* A simple { @link Fragment } subclass .
34*/
35public class NavigationDrawerFragment extends Fragment {
36
37 ActionBarDrawerToggle mActionBarDrawerToggle ;
38 DrawerLayout mDrawerLayout ;
39 private boolean mUserLearnedDrawer ;
40 private static final String PREF_FILE_NAME = " drawer ";
41 private static final String KEY_USER_LEARNED_DRAWER = " user_learned_drawers ";
42 RecyclerView mNavigationDrawerRecyclerView ;
43 Spinner mAccountSwitchSpinner ;
44 TextView mUserName ;
45 CircularImageView mUserImage ;
46 onDrawerItemSelected mDrawerItemSelection ;
95

47 MainActivity mainActivity ;
48
49 public NavigationDrawerFragment () {
50 // Required empty public constructor
51 }
52
53
54 @Override
55 public void onAttach ( Context context ) {
56 super . onAttach ( context );
57
58 mDrawerItemSelection = ( onDrawerItemSelected ) context ;
59 }
60
61
62 @Override
63 public View onCreateView ( LayoutInflater inflater , ViewGroup container ,
64 Bundle savedInstanceState ) {
65 // Inflate the layout for this fragment
66 return inflater . inflate (R. layout . fragment_navigation_drawer , container ,
false );
67 }
68
69 @Override
70 public void onViewCreated ( View view , Bundle savedInstanceState ) {
71 super . onViewCreated (view , savedInstanceState );
72 mUserImage = ( CircularImageView ) view . findViewById (R.id. user_image );
73 ImageLoader mImageLoader = ApplicationInstance . getInstance ().
getImageLoader ();
74 mImageLoader .get (" https :// api . sqoot .com /v2/ deals /4294143/ image ",
ImageLoader . getImageListener ( mUserImage , R. drawable . app_icon , R. drawable .
background ));
75
76 mUserName = ( TextView ) view . findViewById (R.id. userName );
77 mUserName . setText ( Constants . USERNAME );
78 mNavigationDrawerRecyclerView = ( RecyclerView ) view . findViewById (R.id.
navigation_drawer_recyclerview );
79 mAccountSwitchSpinner = ( Spinner ) view . findViewById (R.id.
user_merchant_spinner );
80 SpinnerAdapter mSpinnerAdapter = new SpinnerAdapter ( getActivity () , R.
layout . navigation_drawer_list_item , getSpinnerData ());
81 mAccountSwitchSpinner . setAdapter ( mSpinnerAdapter );
82 mAccountSwitchSpinner . setSelection ( Constants . mPostion );
83 NavigationDrawerAdapter recyclerViewAdapter = new NavigationDrawerAdapter
( getActivity () , getListItems () , this );
84 mNavigationDrawerRecyclerView . setAdapter ( recyclerViewAdapter );
85 LinearLayoutManager linearLayoutManager = new LinearLayoutManager (
getActivity ());
86 mNavigationDrawerRecyclerView . setLayoutManager ( linearLayoutManager );
96

87
88 mAccountSwitchSpinner . setOnItemSelectedListener ( new AdapterView .
OnItemSelectedListener () {
89 @Override
90 public void onItemSelected ( AdapterView <?> parent , View view , int
position , long id) {
91 if ( Constants . mInitialization ) {
92 Constants . mInitialization = false ;
93 } else {
94 switch ( position ) {
95 case 0:
96 Constants . isConsumer = true ;
97 Constants . mPostion = 0;
98 break ;
99 case 1:
100 Constants . isConsumer = false ;
101 Constants . mPostion = 1;
102 break ;
103
104 }
105
106 mDrawerLayout . closeDrawers ();
107 Constants . mInitialization = true ;
108 startActivity (new Intent ( getActivity () , MainScreen . class ));
109 getActivity (). finish ();
110 }
111 }
112
113 @Override
114 public void onNothingSelected ( AdapterView <?> parent ) {
115
116 }
117 });
118 }
119
120 private ArrayList < GenericModel > getListItems () {
121
122 ArrayList < GenericModel > spinnerList = new ArrayList < GenericModel >();
123 if ( Constants . isConsumer ) {
124 GenericModel temp = new GenericModel (" Deals ", R. drawable . nav_deals );
125 spinnerList . add( temp );
126
127 temp = new GenericModel (" Search ", R. drawable . nav_search );
128 spinnerList . add( temp );
129
130 temp = new GenericModel (" Category ", R. drawable . nav_setting );
131 spinnerList . add( temp );
132
133 temp = new GenericModel (" Merchant Deals ", R. drawable . nav_logout );
97

134 spinnerList . add( temp );
135
136 temp = new GenericModel ("Set Event ", R. drawable . nav_setting );
137 spinnerList . add( temp );
138
139 } else {
140 /* GenericModel temp = new GenericModel (" Orders ", R. drawable . nav_deals
);
141 spinnerList . add( temp );*/
142
143 GenericModel temp = new GenericModel (" Post ", R. drawable . nav_search );
144 spinnerList . add( temp );
145
146 /* temp = new GenericModel (" Merchant Settings ", R. drawable . nav_setting
);
147 spinnerList . add( temp );
148
149 temp = new GenericModel (" Merchant Logout ", R. drawable . nav_logout );
150 spinnerList . add( temp );*/
151 }
152
153 return spinnerList ;
154
155 }
156
157 private ArrayList < GenericModel > getSpinnerData () {
158 ArrayList < GenericModel > spinnerList = new ArrayList < GenericModel >();
159 GenericModel temp = new GenericModel (" Consumer ", R. mipmap . ic_launcher );
160 spinnerList . add( temp );
161 temp = new GenericModel (" Merchant ", R. mipmap . ic_launcher );
162 spinnerList . add( temp );
163 return spinnerList ;
164 }
165
166 public void setUp ( DrawerLayout drawer , Toolbar toolbar ) {
167 mDrawerLayout = drawer ;
168
169 mActionBarDrawerToggle = new ActionBarDrawerToggle ( getActivity () , drawer ,
toolbar , R. string . navigation_drawer_open , R. string . navigation_drawer_close ) {
170
171 @Override
172 public void onDrawerClosed ( View drawerView ) {
173 getActivity (). invalidateOptionsMenu ();
174
175 Animation . CircularImageAnimation ( mUserImage , false );
176 }
177
178 @Override
179 public void onDrawerSlide ( View drawerView , float slideOffset ) {
98

180 super . onDrawerSlide ( drawerView , slideOffset );
181 }
182
183 @Override
184 public void onDrawerOpened ( View drawerView ) {
185
186 Animation . CircularImageAnimation ( mUserImage , true );
187 if (! mUserLearnedDrawer ) {
188 mUserLearnedDrawer = true ;
189 saveToPreferences ( getActivity () , KEY_USER_LEARNED_DRAWER ,
Boolean . toString ( mUserLearnedDrawer ));
190 }
191
192 getActivity (). invalidateOptionsMenu ();
193 }
194 };
195 drawer . setDrawerListener ( mActionBarDrawerToggle );
196 mActionBarDrawerToggle . syncState ();
197 }
198
199 private static void saveToPreferences ( Context context , String preferenceName ,
String value ) {
200 SharedPreferences sharedPreferences = context . getSharedPreferences (
PREF_FILE_NAME , Context . MODE_PRIVATE );
201 SharedPreferences . Editor editor = sharedPreferences . edit ();
202 editor . putString ( preferenceName , value );
203 editor . apply ();
204 }
205
206 private static String readFromPreferences ( Context context , String
preferenceName , String value ) {
207 SharedPreferences sharedPreferences = context . getSharedPreferences (
PREF_FILE_NAME , Context . MODE_PRIVATE );
208 return sharedPreferences . getString ( preferenceName , value );
209
210 }
211
212 public void CallFragmentChanger (int position ) {
213
214 mDrawerItemSelection . fragmentFetcher ( position , 0, "");
215 }
216}
Listing 18 { NavigationDrawerFragment
99

I. 5.5 KeywordDealActivity
1package com . cloudcomputing . shopit ;
2
3import android .os. Bundle ;
4import android . support .v7.app . AppCompatActivity ;
5
6public class KeywordDealActivity extends AppCompatActivity {
7
8 @Override
9 protected void onCreate ( Bundle savedInstanceState ) {
10 super . onCreate ( savedInstanceState );
11 setContentView (R. layout . fragment_deals );
12
13
14 }
15
16}
Listing 19 { KeywordDealActivity
100

I. 5.5 FragmentTab
1package com . cloudcomputing . shopit ;
2
3/**
4* Created by Nitin on 12/11/2015.
5*/
6
7import android .os. Bundle ;
8import android . support .v4.app . Fragment ;
9import android . view . LayoutInflater ;
10import android . view . View ;
11import android . view . ViewGroup ;
12import android . widget . TextView ;
13
14public class FragmentTab extends Fragment {
15
16
17 @Override
18 public void onCreate ( Bundle savedInstanceState ) {
19 super . onCreate ( savedInstanceState );
20 }
21
22 @Override
23 public View onCreateView ( LayoutInflater inflater , ViewGroup container ,
24 Bundle savedInstanceState ) {
25 View v = inflater . inflate (R. layout . fragment_layout , container , false );
26 TextView tv = ( TextView ) v. findViewById (R.id. text );
27 Bundle b = getArguments ();
28
29 tv. setText (b == null ? " Bundle Null " : b.get (" text "). toString ());
30 return v;
31 }
32}
Listing 20 { FragmentTab
101

I. 5.5 Constants
1package com . cloudcomputing . shopit ;
2
3import android . location . Location ;
4
5import com. cloudcomputing . apicallmodels . CategoryDealHolder ;
6import com. cloudcomputing . apicallmodels . DealHolder ;
7
8import java . util . ArrayList ;
9import java . util . List ;
10
11/**
12* Created by Nitin on 12/4/2015.
13*/
14public class Constants {
15
16
17 public static int SCREEN_WIDTH ;
18 public static int SCREEN_HEIGHT ;
19
20 public static String GETDEALS = " http :// myrestapi -env . elasticbeanstalk .com /
mywebservice / getdeals ? location =%s ,%s& radius =%s& page =%s& category =%s& keyword =%s"
;
21 public static String GETELASTICDEAL = " http :// finalrestapi -env .
elasticbeanstalk .com / mywebservice / getelasticdeals ? location =%s ,%s& radius =20&
page =%s& keyword =%s";
22 public static String GETDEALSBYCATEGORY = " http :// myrestapi -env .
elasticbeanstalk .com / mywebservice / getdealsbycategory ? location =%s ,%s& radius =%s&
page =%s& category =%s";
23 public static String GETELASTICCATEGORY = " http :// finalrestapi -env .
elasticbeanstalk .com / mywebservice / getelasticdealsbycategory ? category =%s&
location =%s ,%s& radius =20& page =%s";
24
25 public static String GETSIGNUP = " http :// finalrestapi -env . elasticbeanstalk .
com / mywebservice / signup ? email =%s& password =%s& username =%s& deviceid =%s";
26 public static String GETLOGIN = " http :// finalrestapi -env . elasticbeanstalk .com
/ mywebservice / login ? email =%s& password =%s";
27 public final static String SHARED_PREFERENCES_NAME = " logindetails ";
28 public final static String LOGIN_USER_ID = " loginid ";
29 public final static String LOGIN_USER_TOKEN = " loginusertoken ";
30 public static boolean isConsumer = true ;
31 public static boolean mInitialization = true ;
32 public static int mPostion = 0;
33 public static String USERNAME ;
34 public static ArrayList <String > mCategoryList ;
35 public static String token = "";
36 public static Location mLocation ;
102

37 public static int radius = 5;
38 public static List < DealHolder > mNotificationDeals ;
39 public static String keyword = "";
40 public final static int GETDEAL_QUERY = 0;
41 public final static int GETDEAL_CATEGORY_QUERY = 1;
42
43 public final static int FRAGMENT_CATEGORY_DEALS = 4;
44
45
46 public final static String QUERY_TYPE = " type ";
47 public final static String QUERY_PARAMETER_CATEGORY = " category ";
48 public static String mNotificationCategory = "";
49
50 public static String getDealsQuery (int type ) {
51 String query = null ;
52 switch ( type ) {
53
54 case 0:
55 // query = GETDEALS ;
56 query = GETELASTICDEAL ;
57 break ;
58 case 1:
59 // query = GETDEALSBYCATEGORY ;
60 query = GETELASTICCATEGORY ;
61 break ;
62
63 }
64
65 return query ;
66 }
67
68
69 public static void init () {
70 mCategoryList = new ArrayList <String >();
71 mCategoryList .add(" Bowling ");
72 mCategoryList .add(" City Tours ");
73 mCategoryList .add(" Comedy Clubs ");
74 mCategoryList .add(" Concerts ");
75 mCategoryList .add(" Dance Classes ");
76 mCategoryList .add(" Golf ");
77 mCategoryList .add(" Life Skills Classes ");
78 mCategoryList .add(" Museums ");
79 mCategoryList .add(" Outdoor Adventures ");
80 mCategoryList .add(" Skiing ");
81 mCategoryList .add(" Skydiving ");
82 mCategoryList .add(" Sporting Events ");
83 mCategoryList .add(" Theater ");
84 mCategoryList .add(" Wine Tasting ");
85 mCategoryList .add(" Bars & Clubs ");
103

86 mCategoryList .add(" Fitness Classes ");
87 mCategoryList .add("Gym");
88 mCategoryList .add(" Martial Arts ");
89 mCategoryList .add(" Personal Training ");
90 mCategoryList .add(" Pilates ");
91 mCategoryList .add(" Yoga ");
92 mCategoryList .add(" Chiropractic ");
93 mCategoryList .add(" Dental ");
94 mCategoryList .add(" Dermatology ");
95 mCategoryList .add(" Eye & Vision ");
96 mCategoryList .add(" Facial ");
97 mCategoryList .add(" Hair Removal ");
98 mCategoryList .add(" Hair Salon ");
99 mCategoryList .add(" Makeup ");
100 mCategoryList .add(" Manicure & Pedicure ");
101 mCategoryList .add(" Massage ");
102 mCategoryList .add("Spa");
103 mCategoryList .add(" Tanning ");
104 mCategoryList .add(" Teeth Whitening ");
105 mCategoryList .add(" Automotive Services ");
106 mCategoryList .add(" Food & Grocery ");
107 mCategoryList .add(" Home Services ");
108 mCategoryList .add(" M e n s Clothing ");
109 mCategoryList .add(" Photography Services ");
110 mCategoryList .add(" Treats ");
111 mCategoryList .add(" W o m e n s Clothing ");
112 mCategoryList .add(" Baby ");
113 mCategoryList .add(" Bridal ");
114 mCategoryList .add(" College ");
115 mCategoryList .add(" Jewish ");
116 mCategoryList .add(" Kids ");
117 mCategoryList .add(" Kosher ");
118 mCategoryList .add(" Pets ");
119 mCategoryList .add(" Travel ");
120
121 }
122
123
124}
Listing 21 { Constants
104

I. 5.5 BackgroundLocationService
1package com . cloudcomputing . shopit ;
2
3import android . app. Notification ;
4import android . app. NotificationManager ;
5import android . app. PendingIntent ;
6import android . app. Service ;
7import android . content . Context ;
8import android . content . Intent ;
9import android . content .pm. PackageManager ;
10import android . location . Location ;
11import android . location . LocationListener ;
12import android . location . LocationManager ;
13import android .os. Bundle ;
14import android .os. IBinder ;
15import android . support .v4.app . ActivityCompat ;
16import android . util .Log ;
17import android . widget . Toast ;
18
19import com. cloudcomputing . apicallmodels . CategoryDealHolder ;
20import com. cloudcomputing . apicallmodels . DealHolder ;
21import com. cloudcomputing . apicallmodels . Test ;
22import com. cloudcomputing . models . NetworkListener ;
23import com. cloudcomputing . networkcalls . Network ;
24
25import java . util . List ;
26
27public class BackgroundLocationService extends Service implements NetworkListener
{
28 private LocationManager locationManager ;
29 private MyLocation mMyLocation ;
30 String mCategory ;
31 String mFormattedQuery , mQuery ;
32
33 public BackgroundLocationService () {
34 }
35
36 @Override
37 public IBinder onBind ( Intent intent ) {
38 // TODO : Return the communication channel to the service .
39 mCategory = Constants . mNotificationCategory ;
40 throw new UnsupportedOperationException ("Not yet implemented ");
41 }
42
43
44 public void onStart ( Intent intent , int StartId ) {
45 mCategory = Constants . mNotificationCategory ;
105

46 locationManager = ( LocationManager ) BackgroundLocationService . this .
getSystemService ( Context . LOCATION_SERVICE );
47 mMyLocation = new MyLocation ();
48 if ( ActivityCompat . checkSelfPermission (this , android . Manifest . permission .
ACCESS_FINE_LOCATION ) != PackageManager . PERMISSION_GRANTED && ActivityCompat .
checkSelfPermission (this , android . Manifest . permission . ACCESS_COARSE_LOCATION )
!= PackageManager . PERMISSION_GRANTED ) {
49 // TODO : Consider calling
50 // ActivityCompat # requestPermissions
51 // here to request the missing permissions , and then overriding
52 // public void onRequestPermissionsResult (int requestCode , String []
permissions ,
53 // int [] grantResults )
54 // to handle the case where the user grants the permission . See the
documentation
55 // for ActivityCompat # requestPermissions for more details .
56 return ;
57 }
58 locationManager . requestLocationUpdates ( LocationManager . GPS_PROVIDER , 0,
100 , mMyLocation );
59 Toast . makeText ( BackgroundLocationService .this , " Retreiveing Location ",
Toast . LENGTH_SHORT ). show ();
60 // permittednotification (no);
61
62
63 }
64
65 @Override
66 public <T> void onLoadResults (T result ) {
67
68
69 // Test mQueryData = ( Test ) result ;
70 Test mTemp = ( Test ) result ;
71 List < DealHolder > mQueryData = mTemp . getHits (). getHitsList ();
72 if ( mQueryData != null ) {
73 if ( mQueryData . size () > 0) {
74 Constants . mNotificationDeals = mQueryData ;//. getDeals ();
75
76 Intent intent = new Intent ( BackgroundLocationService .this ,
NotificationDealActivity . class );
77 PendingIntent pendingIntent = PendingIntent . getActivity (
BackgroundLocationService .this , 0, intent , PendingIntent . FLAG_UPDATE_CURRENT );
78
79 Notification . Builder notificationBuilder = new Notification .
Builder ( this );
80 notificationBuilder . setAutoCancel ( true );
81 notificationBuilder . setDefaults ( Notification . DEFAULT_ALL );
82 notificationBuilder . setContentTitle (" Shop it");
83 notificationBuilder . setContentText ("New Deals for you !!");
106

84 notificationBuilder . setSmallIcon (R. drawable . app_icon );
85 notificationBuilder . setTicker (" Ticker ");
86 notificationBuilder . setContentIntent ( pendingIntent );
87 NotificationManager notificationManager = ( NotificationManager )
getSystemService ( Context . NOTIFICATION_SERVICE );
88 notificationManager . notify (1, notificationBuilder . build ());
89 }
90 } else {
91 Toast . makeText ( BackgroundLocationService .this , "No Deals ", Toast .
LENGTH_SHORT ). show ();
92 }
93 }
94
95 @Override
96 public <T> void onRefreshResults (T result ) {
97
98 }
99
100 @Override
101 public <T> void onPagingResults (T result ) {
102
103 }
104
105
106 class MyLocation implements LocationListener {
107
108
109 @Override
110 public void onLocationChanged ( Location location ) {
111
112 if ( location != null ) {
113 mQuery = Constants . getDealsQuery ( Constants . GETDEAL_CATEGORY_QUERY
);
114 mFormattedQuery = String . format (mQuery , ! mCategory . equals ("") ?
mCategory . toLowerCase () : "", location . getLatitude () , location . getLongitude () ,
1);
115
116 // mFormattedQuery = String . format (mQuery , "", "", "", "", !
mCategory . equals ("") ? mCategory . toLowerCase () : "");
117 // mFormattedQuery = String . format (mQuery , location . getLatitude ()
, location . getLongitude () , 10 + "", mCategory , "", "") ;
118
119
120 // mFormattedQuery = String . format (mQuery , location . getLatitude
() , location . getLongitude () ,10+"" , "", "", "") ;
121
122 Network . getInstance (). getDealsNotification ( mFormattedQuery ,
BackgroundLocationService . this );
123 Log .e(" Location ", " Location changed " + mCategory );
107

124 } else
125 Log .e(" Location ", " Location not changed ");
126 }
127
128 @Override
129 public void onStatusChanged ( String provider , int status , Bundle extras ) {
130
131 }
132
133 @Override
134 public void onProviderEnabled ( String provider ) {
135
136 }
137
138 @Override
139 public void onProviderDisabled ( String provider ) {
140
141 }
142 }
143}
Listing 22 { BackgroundLocationService
I. 5.5 ApplicationInstance
1package com . cloudcomputing . shopit ;
2
3import android . app. Application ;
4import android . graphics . Bitmap ;
5import android . support .v4. util . LruCache ;
6
7import com. android . volley . Request ;
8import com. android . volley . RequestQueue ;
9import com. android . volley . toolbox . ImageLoader ;
10import com. android . volley . toolbox . Volley ;
11import com. facebook . FacebookSdk ;
12
13/**
14* Created by Nitin on 11/29/2015.
15*/
16public class ApplicationInstance extends Application {
17
18 private RequestQueue mRequestQueue ;
19 private static ApplicationInstance mInstance ;
20 private ImageLoader mImageLoader ;
21 public static final String TAG = ApplicationInstance . class . getName ();
22
23 @Override
24 public void onCreate () {
108

25 super . onCreate ();
26 mInstance = this ;
27 FacebookSdk . sdkInitialize ( this );
28 mRequestQueue = Volley . newRequestQueue ( getApplicationContext ());
29 mImageLoader = new ImageLoader ( mRequestQueue , new ImageLoader . ImageCache
() {
30
31 private final LruCache <String , Bitmap >
32 cache = new LruCache <String , Bitmap >(20) ;
33
34 @Override
35 public Bitmap getBitmap ( String url ) {
36 return cache .get (url );
37 }
38
39 @Override
40 public void putBitmap ( String url , Bitmap bitmap ) {
41
42 cache .put(url , bitmap );
43 }
44 });
45 }
46
47 public static synchronized ApplicationInstance getInstance () {
48 return mInstance ;
49 }
50
51 public RequestQueue getRequestQueue () {
52 return mRequestQueue ;
53 }
54
55 public <T> void add ( Request <T> req ) {
56 req. setTag (TAG);
57 getRequestQueue ().add(req);
58 }
59
60 public ImageLoader getImageLoader () {
61 return mImageLoader ;
62 }
63
64 public void cancel () {
65 mRequestQueue . cancelAll (TAG);
66 }
67
68}
Listing 23 { ApplicationInstance
109