API based Native Hybrid App for ORVBA

(on road vehicle breakdown assistance)

Undertaken By:
TOHEED HAYAT
CIIT/FA15-BS (SE)-074/WAH

SAGHAR MEHMOOD
CIIT/FA15-BS (SE)-050/WAH

Supervised By:

Ms. Mamuna Fatima

A DISSERTATION SUBMITTED AS A PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF

BACHELOR IN COMPUTER SCIENCE

DEPARTMENT OF COMPUTER SCIENCES

COMSATS UNIVERSITY ISLAMABAD, WAH CAMPUS
PAKISTAN
SESSION 2015-2019
 DEDICATION

To my Loving Parents, Teachers, Friends and

Respectable Supervisor who guides us in every step of

the project

i
ORVBA
 Acknowledgement
In the name of ALLAH, the most beneficent and most merciful, without Allah’s
blessing this project, API based Native Hybrid App for ORVBA (on road
vehicle breakdown assistance) would not have been possible.

We would like to thank our parents for their continued support which kept us
motivated all along the way.

We are especially grateful to our Project supervisor Ms. Mamuna Fatima for
believing in us and guiding us throughout the project. His continued support and
kindness, constructive criticisms and appreciation, helped this project to bring where
it is now.

At the end we are thankful to our senior students for their help, assistance and
guidance.

ii
ORVBA
 PROJECT BRIEF

PROJECT NAME API BASED NATIVE HYBRID APP FOR

ORVBA (ONROAD VEHICLE
BREAKDOWN ASSISTANCE)
ORGANIZATION NAME COMSATS UNIVERSITY ISLAMABAD
OBJECTIVE THE PROJECT AIMS TO SOLVE A VERY
COMMON ISSUE IN REGARD TO THE
ASSISTANCE OF ROAD VEHICLES
UNDERTAKEN BY TOHEED HAYAT
SAGHAR MEHMOOD
SUPERVISED BY MS. MAMUNA FATIMA
COMPUTER SCIENCE DEPARTMENT
CUI WAH
STARTED ON JULY 10, 2018
COMPLETED ON MAY 20, 2019
COMPUTER USED LENOVO (CORE I7), DELL (CORE I5)
SOURCE LANGUAGE HTML, CSS, JAVASCRIPT, PHP
LARAVELL REACT NATIVE, MYSQL
OPERATING SYSTEM WINDOWS 10, WINDOW 8.1
TOOLS USED VISUAL STUDIO, MS WORD 2016
GIT BASH, HEIDI SQL.

iii
ORVBA
 ABSTRACT

The proposed system “ORVBA (on road vehicle breakdown assistance)” The
application is designed to enhance the user experience and ensure that users get
immediate and hassle-free service in the event of any vehicle breakdown. Our
application shall make all possible efforts to locate the nearest service provider to
user's location to solve the vehicle problem.

Our quick and easy solution provide any user with an app having an ability to search
for a competent service provider, book a service activity and finally generate a
reasonable bill in just a matter of few clicks

iv
ORVBA
 TABLE OF CONTENT

1.1 PURPOSE ........................................................................................................................ 2

1.2 SCOPE ............................................................................................................................. 2
1.3 OBJECTIVE: ................................................................................................................... 2
2.1 PROJECT OVERVIEW ................................................................................................... 4
2.2 EXISTING SYSTEM ....................................................................................................... 4
2.3 BUSINESS CONTEXT ................................................................................................... 4
3.1 OBJECTIVE OF PROPOSED SYSTEM ........................................................................ 6
3.2 FUNCTIONAL REQUIREMENTS ................................................................................ 6
3.3 SIGN UP/ REGISTRATION ........................................................................................... 7
3.4 LOGIN ............................................................................................................................. 7
3.5 SEARCH FOR SERVICE PROVIDER ........................................................................... 8
3.6 NOTIFICATION .............................................................................................................. 9
3.7 CONFIRMATION ........................................................................................................... 9
3.8 VIEW LOCATION ........................................................................................................ 13
3.9 BILL RECEIPT .............................................................................................................. 13
3.10 FEEDBACK ................................................................................................................... 13
4.1 DESIGNING ................................................................................................................. 13
4.2 HARDWARE DESIGN ................................................................................................ 14
4.3 INTERFACE DESIGN .................................................................................................. 14
4.3.1 INFORMATION DISPLAY................................................................................................... 13
4.3.2 PERFORMANCE REQUIREMENT ........................................................................................ 13
4.3.3 COMMUNICATION INTERFACE ......................................................................................... 14

4.4 USER FRIENDLY ......................................................................................................... 14

4.5 WORKING COST ......................................................................................................... 14
4.6 SECURITY .................................................................................................................... 14
4.7 RELIABILITY ............................................................................................................... 14
4.8 EXTENSIBILITY .......................................................................................................... 14
4.8 SERVICEABILITY ....................................................................................................... 14
5.1 PRELIMINARY OBJECT-ORIENTED DOMAIN ANALYSIS ................................. 17
5.1.1 Inheritance Relationships………………………….………………………………….17

v
ORVBA
5.2 USE CASE DIAGRAMS ............................................................................................... 17
5.2.1 MAIN CLASS DIAGRAM .................................................................................................. 18
5.2.2 USE CASE ..................................................................................................................... 19
5.2.3 SEQUENCE DIAGRAM .................................................................................................... 20
5.2.4 ACTIVITY DIAGRAM ..................................................................................................... 21
5.2.5 ER DIAGRAM ................................................................................................................. 22

6.1 PROVIDERS .................................................................................................................. 24

6.1.1 INDEX ........................................................................................................................... 25
6.1.2 Store ............................................................................................................................. 25
6.1.3 Show ............................................................................................................................. 26
6.1.4 DESTROY ....................................................................................................................... 27
6.2 USER API AUTHENTICATION.................................................................................... 27
6.2.1 GET TOKEN .................................................................................................................... 27
6.2.2 LOGIN ......................................................................................................................... 28
6.2.3 REGISTER ................................................................................................................... 28
6.3 CONTACTS .................................................................................................................... 28
6.3.1 INDEX ............................................................................................................................ 29
6.3.2 Store .............................................................................................................................. 29
6.3.3 Show .............................................................................................................................. 30
6.3.4 DESTROY ........................................................................................................................ 31
6.3 FAQ’S .............................................................................................................................. 31
6.4.1 INDEX ............................................................................................................................. 32
6.4.2 Store .............................................................................................................................. 32
6.4.3 Show .............................................................................................................................. 33
6.4.4 DESTROY ........................................................................................................................ 34
7.1 AUTHENTICATION ....................................................................................................... 36
7.2 HOME………….……………………………………………………….………….…….37
7.3 BOOK VBA……….…………………………………………………….………….……38
7.4 FAQS………….………………………………………………………….……...…...….39
7.5 CONTACT MESSAGES………………….……………………………….…….….…...40
7.6 BILLS……….………………………………………………………………….….…….41
8.1 SIMULATOR………………………………………………………………………...….42
CONCLUSION…………………………………………………………………………………..43
REFERENCE………………………………………………………………………………….....44

vi
ORVBA
 LIST OF FIGURES

Figure 1: Main Class Diagram ...................................................................................................... 18

Figure 2: Use Case Diagram ......................................................................................................... 19
Figure 3: Sequence Diagram ......................................................................................................... 20
Figure 4: Activity Diagram ........................................................................................................... 21
Figure 5: ER Diagram ................................................................................................................... 22

vii
ORVBA
 LIST OF TABLES

Table 1:Sign up/registration ............................................................................................................ 7

Table 2: Login ................................................................................................................................. 7
Table 3: Search for Serive provider ................................................................................................ 8
Table 4: Notification ....................................................................................................................... 9
Table 5: Confirmation ..................................................................................................................... 9
Table 6: View Location ................................................................................................................ 10
Table 7: Bill Receipt ..................................................................................................................... 10
Table 8: Feedback ........................................................................................................................ 11

viii
ORVBA
Chapter 1
Introduction
Chapter 1 Introduction

1.1 Purpose

The application is designed to enhance the user experience and ensure that users get immediate
and hassle-free service in the event of any vehicle breakdown. Our application shall make all
possible efforts to locate and direct the nearest service provider to user's location.

1.2 Scope

Orvba will act as a marketplace between Queries [Customers] and the Service providers.
Whenever a Query finds itself assistance. It will open the tab and go through various categories of
services. i.e. Tire Burst, Brakes System and so on. Once the query selects its issue related category
the Orvba will go through the main database and pull all the records of Such Service Provider
which are nearest to the Query. The query will further select from one of these providers and then
a request will be generated for that particular service provider. If the service provider accepts the
Service, the Orvba app will start the service as an active service. At the end of the Service the
Orvba app will ask for feedback if the query wish so.

1.3 Objective:
The project aims to solve a very Common Issue in regard to the Assistance of Road Vehicles.
The project is essentially a large-scale Online Portal which provides Membership functionality
to the common public and service providers. Whenever a User puts in an Assistance request the
Service Provider will receive a Push Notification. He then can apply for Assistance. The user
may choose from available Service Providers based on their rating, charges and work history.

2
ORVBA
 Chapter 2
System Study
Chapter 2 System Study

2.1 Project Overview

Orvba is essentially a marketplace with various Vehicle Assistance Service provider form the
whole country. It will act as an independent freelance so that people will have much easier way to
get help in regard to Vehicle breakdown.

2.2 Existing System

As of this moment, our research has made it clear to us that no Service of this nature is currently
available in Pakistan and it has become very difficult to the Female Drivers to get assistance in
Pakistan without going through a lot of hassle

2.3 Business Context

Orvba is an easy opportunity for the Vehicle Service Providers to know exactly where their
potential customers are, and help them accordingly with their skills. It will just need a
Smartphone with an ORVBA app installed.

4
ORVBA
 Chapter 3
Proposed System
Chapter 3 Proposed System

3.1 Objective of proposed system

● To promote modern viable options by giving todays service
providers(mechanics/electration) in digital way to interact with their clients via using
application base solution
● To give a superior quality service even in time of emergence/distress such as vehicle
breakdown system.
● In order to create some new jobs opportunities via application-based business model.

3.2 Functional Requirements

Following are the main features of our system listed below.
 Sign up/ registration
 Login
 Search for Service provider.
 Service provider receive a push notification
 User receive a confirmation message
 User and service provider both can see each other location
 Bill receipt.
 Maintain records of user and service provider
 Both can give/provide feedback

6
ORVBA
Chapter 3 Proposed System

3.3 Sign up/ registration

Table 1: Sign up/ registration

In this function requirement they must sign up at the app in

Description order to get facilitated. After signing up the data will be stored at
database.
Important Functionality because without fulfilling this requirement
Criticality
they will be unable to login in the system and use the app.
The technical issue is that they cannot be able to use same email
Technical Issues
for more than one account.
Cost of this requirement is high in the form of the importance of
Cost and Schedule
this requirement. Schedule for this is one week.
The user must enter all the required fields given at signup forms.
Risks This system must store and allow only those users to get sign who
are registered.
Dependencies with
No dependency.
another requirement

3.4 Login
Table 2: Login

They must be login at the website in order to get facilitated. Then

Description
they will be able to use our services.
Important Functionality because without fulfilling this requirement
Criticality user will be unable to login in the system and use the functionality
of the app.

7
ORVBA
Chapter 3 Proposed System

Technical Issues The technical issue is that user enter a wrong email or password.

Cost of this requirement is high in the form of the importance of

Cost and Schedule
this requirement. Schedule for this is one week.

Risks
They enter a wrong email and password

Dependencies with
Depending on sign up/registration.
another requirement

3.5 Search for Service provider

Table 3: Search for Service provider

The user can search for a service provider with in 2km and then
Description
select the best of them according to their rating and price.
It is critical that user cannot find the service provider without
Criticality
searching
Technical issue is that user cannot find the service provider with
Technical Issues
in his range.
Cost of this requirement is high in the form of the importance of
Cost and Schedule
this requirement. Schedule for this is three weeks.
Risks
Our system should be able to make proper searching

Dependencies with
Depending on login.
another requirement

8
ORVBA
Chapter 3 Proposed System

3.6 Notification
Table 4: Notification

The service provider receives a push notification when user send

Description
him a request/query.
It is critical that the service provider want know how required his
Criticality
services.
Technical Issues Must have active internet connection.

Cost of this requirement is high in the form of the importance of

Cost and Schedule
this requirement. Schedule for this is two weeks.
Risks
The service provider must be able to respond.

Dependencies with
User must search for a service provider.
another requirement

3.7 Confirmation
Table 5: Confirmation

After sending a request/query towards service provider, the user

Description receives a confirmation message from service provider that will be
available or not.
It is critical that user will know that the service provider accepted
Criticality
his request.
Technical Issues The service provider has no active internet connection.

Cost of this requirement is high in the form of the importance of

Cost and Schedule
this requirement. Schedule for this is two weeks.

9
ORVBA
Chapter 3 Proposed System

Risks
The service provider cannot response on his request in time.

Dependencies with
Service provider must receive a notification.
another requirement

3.8 View Location

Table 6: View Location

The user and service provider both can see each other location by
Description
using GPRS system.
Criticality It is critical that they know each other location where they are.

Technical Issues The technical issue is that they lost his internet connection

Cost of this requirement is high in the form of the importance of

Cost and Schedule
this requirement. Schedule for this is two weeks.
Risks The risk is that they lost his internet connection. So, they lost his
Location

Dependencies with
No dependency.
another requirement

3.9 Bill Receipt

Table 7: Bill Receipt

After the completion of service, the system will generate a bill

Description
based on total hours of that service.
Criticality It is critical that everyone get paid according to his work.

10
ORVBA
Chapter 3 Proposed System

The technical issue is that the service provider spends a lot of

Technical Issues
time.
Cost of this requirement is high in the form of the importance of
Cost and Schedule
this requirement. Schedule for this is one week.
Risks The service providers might work slow in order to increase their
bills.

Dependencies with
Depending on confirmation.
another requirement

3.10 Feedback
Table 8: Feedback

Description After the bill payment feedback will be given to the provider.

It is critical that by giving feedback they can see each other

Criticality
ratings.
They can give negative review and ruin the profile of service
Technical Issues
provider.
Cost of this requirement is high in the form of the importance of
Cost and Schedule
this requirement. Schedule for this is two weeks.
Risks
They can give a fake feedback to enhance his rating.

Dependencies with
Depending on bill receipt.
another requirement

11
ORVBA
 Chapter 4
System Design
 Chapter 4 System design

4.1 Designing
The primary design constraint is the android level, since the application is designated also for
mobile handsets, limited screen size and resolution will be a major design consideration. Creating
a user interface which is both effective and easily navigable will pose a difficult challenge. Other
constraints such as limited memory and processing power are also worth considering.

4.2 Hardware design

Smartphone with 2 GB ram and good internet connection (3G+ or Wifi).

4.3 Interface design

The Interfaces should be user friendly that will increase user interest in the application. Making
interfaces more understandable and self-explanatory is main focus, while giving interfaces an

entertaining touch.

4.3.1 Information Display

If information presented is incomplete, ambiguous, or unintelligible, the application will fail to
satisfy the needs of a user. The following guidelines focus on information display;

● Display only that information that is relevant to the current context.

● Use consistent labels, standard abbreviations and predictable colors.
● User are allowed to maintain their data.
● Produce meaningful error messages

4.3.2 Performance Requirements

Performance requirements are of great importance. The system performance responds time must
be minimized so to increase the system functionality. We don’t use heavy images and assets on
the app that makes our app slow. We should use design pattern to maximize our performance and
other techniques. The system should perform accurately under all circumstances except some
battery drop or unavailability of internet. We also make sure error handling that saves our user
from a bad experience.

4.3.3 Communication interface

13
ORVBA
 Chapter 4 System design

Client-server architecture, exchange and manipulate files over a TCP/IP based network, such as
the Internet Promote sharing of files (computer programs and/or data). To encourage reliable
data transfer.

4.4 User Friendly

Each interface is logically related to the user. Every menu in the app is user-related or this
product is interfaced dependent. Interfaces are designed in such a way that user can easily
communicate with the system, they are user-friendly, easy to understand and interact. Interfaces
include all kind of standard buttons, functions, special screen layouts, confirm or error messages
etc.

4.5 Working Cost

68K working cost, till date in the development process.

4.6 Security
Login should be required for a user and service provider. Security requirement defines that the
data in the system must be safe and secure. No data must be visible to any third party or
unauthenticated person. The data of the system is highly sensitive, so it must be secured through
authentication system of the user.

4.7 Reliability
The system must be reliable in terms of price, failure rate, customer usage and operating
environment.

4.8 Extensibility
In future, it might be required to add a new module if required. The system must be of such type

that at adding new module or function, older one should not get disturbed. The system must be

open for extension in future without disturbing existing functionality.

4.9 Serviceability
The system must be available 24/7.

14
ORVBA
 Chapter 5
UML Diagrams
 Chapter 5 Uml diagrams

5.1 Preliminary Object-Oriented Domain Analysis

This section presents a list of the fundamental objects that must be modelled within the system to
satisfy its requirements. The purpose is to provide an alternative, "structural" view on the
requirements stated above and how they might be satisfied in the system.

5.1.1 Inheritance Relationships

ORVBA

Customer Service Provider

Car Inspection Vehicle Profile

Assistance
Services Shop Info Profile
Information

Service
Purchase Vehicle Per/Hour Review
User Info
Required s
parts info Cost

16
ORVBA
 Chapter 5 Uml diagrams

5.2 Use Case Diagrams

5.2.1 Main Class Diagram

Figure 1: Class Diagram

17
ORVBA
 Chapter 5 Uml diagrams

5.2.2 Use Case Diagram

Figure 2: Use Case Diagram

18
ORVBA
 Chapter 5 Uml diagrams

5.2.3 Sequence Diagram

Figure 3: Sequence Diagram

19
ORVBA
 Chapter 5 Uml diagrams

5.2.4 Activity Diagram

Figure 4: Activity Diagram

20
ORVBA
 Chapter 5 Uml diagrams

5.2.5 ER Diagram

Figure 5: ER Diagram

21
ORVBA
Chapter 6
Server
Chapter 6 Server

The server is used by an administrator side in which we have control to maintain all the records
or related information of the user and service providers.
Basically, we have a CRUD (Create, Read, Update and delete) system in a server, we can add the
new service provider (Mech/Elec) through serve by filling the required fields, read the data, if
anyone wants to update the information that can be done and also if we want to delete someone
record we can do it easily.
In a server, we have different sections which are define below.

 Providers
 User Api authentication
 Contact
 FAQ’s

6.1 Providers:
In a server, we have a section of provider controller in which we have 4 different functions that
is used to perform different tasks. These controllers are explained below.

 Index
 Store
 Show
 Destroy

23
ORVBA
Chapter 6 Server

6.1.1 Index:

The index function in a provider controller helps us to list the all providers in ascending
descending order. It also helps us to manage that how many providers will be showed in a one
page.

6.1.2 Store:

The store function in a provider controller helps us to modify a previous provider or create the
new service provider (Mech/Elect).
This function is used to find a previous service provider in a database, if the system failed to
find a specific provider then system request for a new provider and request to fill the required
filled like provider name, provider number etc.

24
ORVBA
Chapter 6 Server

6.1.3 Show:

The Show function in a provider controller helps us to Show a specific service provider
(Mech/Elec) by using ID’s. Only that specific provider will be shown which user request for.

25
ORVBA
Chapter 6 Server

6.1.4 Destroy:

The destroy function in a provider controller helps us to delete the specific service provider
which one we want to delete by using its id.

6.2 User Api Authentication:

When user want to sign in through app, authentication system will generate the token and that
token matches the user id and password through database.
In user api authentication, we have three different sections which are following.
 Get token
 Login
 Register

6.2.1 Get token:

“Token" is for each active user session managed by the application. This token is used to verify
that the authenticated user is the one actually making the requests to the application. After the

26
ORVBA
Chapter 6 Server

user registration the user will get a email and password means get the token on a backend.

6.2.2 Login:

When user want to login in to the app, they have to enter the email and password to login. Then,
the system will generate the token and that token will match the user email and password through
database and then response according to the situation that the user exists or not.

6.2.3 Register:

Firstly, user have to register himself by signing up by filling required fields. After the sign up,
the user will get the login and when user wants to login on the app and enter the email and
password on the app the automatic token will be generated. This token will match the user email
and password through database and then response according to the situation that the user exists
or not.

6.3 Contact Message:

In a server, we have a section of contact controller in which we have 4 different functions that is
used to perform different tasks. These controllers are explained below.

 Index
 Store
 Show
 Destroy

27
ORVBA
Chapter 6 Server

6.3.1 Index:

The index function in a contact controller helps us to list the all contact in ascending/descending
order. It also helps us to manage that how many contact messages will be showed in a one page.

6.3.2 Store:

The store function in a contact controller helps us to modify a previous contact message or
create the new contact.
This function is used to edit the previous contact message, if the system failed to find a specific
contact message then system request for a new contact and request to fill the required filled like
contact name, contact email etc.

28
ORVBA
Chapter 6 Server

6.3.3 Show:

The Show function in a contact controller helps us to Show a specific contact message detail by
using ID’s. Only that specific contact message detail will be shown which user request for.

29
ORVBA
Chapter 6 Server

6.3.4 Destroy:

The destroy function in a contact controller helps us to delete the specific contact message which
one we want to delete by using its id.

6.4 FAQ’s:
In a server, we have a section of FAQ’s controller in which we have 4 different functions that is
used to perform different tasks. These controllers are explained below.

 Index
 Store
 Show
 Destroy

30
ORVBA
Chapter 6 Server

6.4.1 Index:

The index function in a FAQ’s controller helps us to list the all question/answers in
ascending/descending order. It also helps us to manage that how many questions/answers will be
showed in a one page.

6.4.2 Store:

The store function in a FAQ’s controller helps us to modify a previous questions/answers or

create the new questions/answers.
This function is used to edit the previous question/answer, if the system failed to find a specific
question/answer then system request for a new question/answer.

31
ORVBA
Chapter 6 Server

6.4.3 Show:

The Show function in a FAQ’s controller helps us to Show a specific question/answer by using
ID’s. Only that specific question/answer detail will be shown which user request for.

32
ORVBA
Chapter 6 Server

6.4.4 Destroy:

The destroy function in a FAQ’s controller helps us to delete the specific question/answer which
one we want to delete by using question id.

33
ORVBA
CHAPTER 7
App
Chapter 7 App

App is used by a user in which all the required screens are available which user wants. App will
help the user to find the service provider (Mech/Elec) in the nearest location.
The different screens which are in an App are following:

7.1 Authentication:
In Authentication, when user open the App they see sign in and signup options. If user is already
register then they sign in the app. When user sign in through app, authentication system matches
the user id and password through database.

If user is not register in app yet, then they have signup option. Complete the signup process and
then signin in the app.

35
ORVBA
Chapter 7 App

After sign in the app user see different screens:

 Home page
 Book Vba
 Faqs
 Contact messages
 Bills

7.2 Home:
In Home page, we have information about app also have a sign-out option and have some pictures
in that screen

36
ORVBA
Chapter 7 App

7.3 Book Vba:

In book vba, user can see the list of providers. When user click the provider, another screen will
be open and in which provider basic Information will be given. In basic information user see the
Provider Name, location, contact number, Rating, Provider detail (expert in which type of cars).
When User hire the Provider, the request will be transferred to the service provider and the
service will be started.

37
ORVBA
Chapter 7 App

7.4 Faqs:
In FAQs screen, user see the basic Questions and Answers about the app. How app will be work
and in which have some questions and Answers that user want to know.

38
ORVBA
Chapter 7 App

7.5 Contact Messages:

Contact messages is used to help the user. If user face any type of problem or issue, they can
contact us through contact messages. Then, administrator resolve the problem of user as soon as
possible.

39
ORVBA
Chapter 7 App

7.6 Bill Section:

In bill section, when user hire the service provider the counter will be started. After the
completion of the service the app will generate the bill and also have an option to give feedback
to our provider.

40
ORVBA
CHAPTER 8

Simulator
Chapter 8 Simulator

8.1 Simulator:

The Simulator is used by a service provider (Mechanics/Electrications) in which service

providers (Mech/Elec) are able to see the request submitted by a user and they have option to
accept or reject the request that are comes from user. After the acceptance of the request, the
service provider can see the detail of users like user name, user phone number, user car issue and
user location. After the confirmation of the service by the service provider the counter will be
started on both sides’ simulator side as well as app.

After the completion of service, the only service provider will be able to end the service and that
option is only available on simulator.
.

42
ORVBA
Chapter 8 Simulator

Conclusion

In this report, we have focused to develop the system which will automate the all process of hiring
an expert service provider (Mech/Elec).

The user will post the request to the suitable mechanic in order to facilitate. The service provider
will accept the request and the service activity will be started. After the compilation of the
service, the automatic bill will be generated. After the bill payment, the user will be able to give
a feedback according to service provider working.

43
ORVBA
Chapter 8 Simulator

Reference

https://laravel.com/docs/5.8/eloquent
https://reactnavigation.org/docs/en/auth-flow.html
https://medium.com/@Gbxnga/token-based-authentication-with-react-and-laravel-restful-
api-83f16581e85
https://laracasts.com/series/laravel-from-scratch-2018
https://pusher.com/tutorials/chat-laravel
https://vuejsdevelopers.com/2018/02/05/vue-laravel-crud/
https://facebook.github.io/react-native/docs/network
https://docs.expo.io/versions/latest/sdk/map-view/
https://medium.com/nycdev/create-a-react-native-app-with-google-map-using-expo-io-
68041252023d
https://reactnavigation.org/docs/en/tab-based-navigation.html

44
ORVBA