Sprint 2 - ISIS-3510-Grupo-35/Application-Backend GitHub Wiki

Implemented Business questions

Type 1: How often do users experience slow load times when searching for available parking spots? This targets performance issues related to the speed of retrieving parking spot data, a crucial aspect of user experience that can indicate server or database lag.
Type 2: Which parking spots have a rating higher than 4.5 around a given location?
This is a Type 2 question as it is useful for users and is answered directly within the app. To answer it, a filtering process must be performed by the analytics engine.
Type 3: What percentage of users utilize the app's online reservation system to book parking spots in a day? This information is useful to analyze if the users are using the functionality or if it should be removed.
Type 2: In which parking lots around the user's location is it necessary to leave keys? This is a Type 2 question as it is of interest to users and should be answered by querying the analytics engine to identify parking spots that meet the given condition. Flutter - Juan Manuel Perez

Analytics pipeline

Before starting with the analytics pipeline, we considered the UML diagram of the entire application thinking of the different elements we would be needing. The diagram looks like this: UniPark (1) We thought of 5 classes, which are User, ParkingLot, Reservation, Transaction, and Review. For all of the classes, there is a respective id associated, but thinking on secure practices, we implemented a uuid, which means that the id will be a combination of letters and numbers. In our case, we are using Firebase for the backend, and this platform had different funtionalities such as assigning uuid's. The complete list of attributes for the class User goes as follows:

User

Attribute	Datatype
id	String
fistName	String
lastName	String
password	String
email	String
isDriver	Boolean
balance	Int
favoriteParkingLots	arrayList [ParkingLot]

The attribute of "isDriver" is a boolean because if the value is true then it means that the user is a driver, but if it is false then it means that he is a parking lot owner. Each user can have 0 or multiple favorite parking lots, and a parking lot should have just one owner. Likewise, a parking lot is owned by just one user, and a user could have 0 or 1 parking lot associated. The full list of attributes for ParkingLot looks as follows:

ParkingLot

Attribute	Datatype
id	String
name	String
userId (FK)	String
openingTime	Datetime
closingTime	Datetime
capacity	Int
priceMinute	Int
fullRate	Int
durationFullRate	Int
address	String
latitude	Double
longitude	Double
image	String

Both _ParkingLot _and _User _have a connection with Review , as a user can make a review of a parking lot. The parking lot can have zero or more reviews, and a review can only belong to one review. Likewise, the review can only belong to one user, but a user can make 0 or multiple reviews. The full list of attributes for _Review _goes as follows:

Review

Attribute	Datatype
id	String
userId (FK)	String
parkingLotId (FK)	String
rate	Double
review	String

User, is also associated with a Reservation , as the goal of the app is present a solution to students, staff members and visitors a solution to the parking problems they may experience. One user can make 0 or multiple reservations, but a reservation can only belong to one user. The full list of attributes for Reservation goes as follows:

Reservation

Attribute	Datatype
id	String
userId (FK)	String
parkingLotId (FK)	String
arrivalTime	DateTime
departureTime	DateTime
licensePlate	String
status	String

In Reservation , the "licensePlate" is an attribute in order for the owner of the parkinglot to know the car that will be parking, and the Status is an abstract object in which there are 4 posible choices: pending, paid, cancelled, and onGoing. This abstract also applies to the status in Transaction, an object that is also associated with User. A reservation needs a transaction, and a transaction can only be associated with 1 reservation. The transaction is also associated with User , as part of the solution is to transfer money from one user to another. Another abstract object used in Transaction is PaymentMethod which has 3 options of payment: debitCard, creditCard, and cash. The full list of attributes for Transaction goes as follows:

Transaction

Attribute	Datatype
id	String
senderUserId (FK)	String
receiverUserId (FK)	String
reservationId (FK)	String
totalCost	Double
paymentMethod	PaymentMethod
transactionDate	DateTime
status	Status

In Firebase, we created a "collection" for each of the tables

The Pipeline:

Blank diagram

Explanation Analytics Pipeline:

The analytics pipeline begins by capturing data directly through the mobile app, using the user’s phone as the primary input device. Data is ingested through event-driven raw data transfers, capturing events such as crashes or other infrequent occurrences only when they happen, minimizing unnecessary data storage. The data is then stored in Firestore, the chosen backend-as-a-service solution, which offers real-time capabilities and robust functionality to support the application’s needs. For the analysis phase, Firebase Analytics will be utilized to process the information and generate key metrics. Finally, by linking Firebase Analytics with Google Analytics, we can obtain deeper insights and visualize critical metrics, enabling more informed decision-making based on the data flowing through this streamlined pipeline.

Architectural design

Rationale:

The Architecture displayed was chosen for the following reasons:

Architectural Style: Client - Server

The architecture follows a Client-Server style to separate the client-side application (mobile app) from the server-side backend (Firebase). This approach allows the client to focus on the views and user interactions while data storage, processing, and real-time synchronization tasks to the server. The mobile app communicates with Firebase through a network interface specifically an API REST.

Architectural Pattern: MVVM

The Model-View-ViewModel (MVVM) pattern is used to separate the user interface (View) from the business logic and data handling (ViewModel), which interacts with the data layer (Model). This separation makes the architecture more maintainable as it is decoupled. In the mobile application, the View layer is responsible for rendering the UI components, while the ViewModel (Observer, App Service) handles user interactions, notifies the View about data changes, and fetches data from the Model layer. This setup allows real-time data updates for example the location service creating dynamism in the UI without tightly coupling the UI components with the business logic.

Design Patterns:

Observer:

The Observer pattern is implemented in the ViewModel layer to notify Views of any changes in the underlying data. This ensures that the UI is always in sync with the latest data in real time. For example, if data in the Firebase Firestore database changes, the Observer pattern will propagate these changes to the View, triggering an automatic UI update without requiring direct intervention in the View layer.

Repository:

The Repository pattern is employed to abstract data access logic from the ViewModel. It serves as a single source of truth by managing data from both the local database (Local DB) and Firebase (Firestore). This pattern allows the mobile app to handle real-time modifications seamlessly, as the Repository can decide whether to fetch data locally or from the cloud based on availability and network conditions. In other words, the Repository is an intermediary between the application's business logic and various data sources.

DAO (Data Access Object):

DAOs are used within the Model layer to handle interactions with the database. In this architecture, separate DAOs are used for accessing the local database (DAOs Local) and Firebase (DAOs Firebase) as based on the Repository pattern both options can happen, without connection or with connection.

Singleton:

The Singleton pattern ensures only one instance of a component, in this case it is the Repository connection settings. This global instance provides consistent access to data and settings across the application especially the DAOS when sending the requests.

List of implemented features

Currently, the application has the following functionalities:

Log in
Log out
Create a user as a driver or parking lot owner
Search locations on the map
View parking spots near the location
See parking spot details
Filter by highest-rated parking spots
View the user profile
Make a reservation in a parkinglot
Se the details of a reservation

Functionality that uses one sensor of the phone

The application for Android and iOS uses the phone’s GPS to locate the user on the map. To access the location, the corresponding authorization is requested, indicating that it is necessary to show nearby parking spots and ensure the correct functioning of the application.

Functionality that answers type 2 question

To answer one of the type 2 questions, we added the functionality to filter the list of parking spots by those that are highest rated. This filter allows users to view only parking spots with a rating higher than 4.5. This result is displayed directly in the application and can be accessed by the client without needing to perform additional operations.

Functionality that is considered smart feature

Flutter:

Show Pop-up if near the parking spot to save the car and when near pop up showing to leave.

Funtionality that allows users authentication

The functionality that enables user authentication is achieved through the Firebase Authentication platform. It allows users to create an account with an email and password and access the application's features using these credentials.

Funtionality that uses external services

As an external service, we use Firebase, a mobile application development platform by Google that offers powerful features for building, managing, and improving applications. Some of the standout features of the Google Firebase platform include databases, authentication, push notifications, analytics, file storage, and more. Specifically for our application, we have deployed the database in Firebase Firestore, utilize the authentication service, and will address business questions through the analytics engine it provides. Show the location of the parking lots on the map as a marker. Additionally, to display the map and locate the user and parking lots in the Android application, we used the GCP platform, which provides access to the Google Maps API.

Ethical video

You can watch our video here

Issues

https://github.com/ISIS-3510-Grupo-35/Application-Backend/issues?q=is%3Aopen+is%3Aissue