Sprint 2 ‐ Deliverable - Curi-Grupo24/curi_app GitHub Wiki

Introduction

We are at the outset of our mobile app implementation journey. Building upon the outcomes of Sprint 1, we are excited to share our progress in Sprint 2. Guided by the principles of design thinking, we have solidified our vision and objectives. In this Sprint, we unveil our decisions regarding architectural design and patterns, as well as our strategy for implementing the Analytics Engine. These choices lay the foundation for our features, including context-aware features and smart features, that uses some external services to provide authentication and let us respond some of our business questiosn.

Business questions (BQs).

We selected some business questions formulated on Sprint 1. As we are using Flutter for our mobile App, and Firebase as an external service (Authentification), we saw an opportunity to use Firebase Analytics, that actually runs Google Analytics, as our pipeline letting us to have the data management and ETL in a single resource. So one, we think using crshlytics in the following Sprints would let us to have analytics over telemetry as well.

RT Analytics

Selected Business Questions:

  1. Which hour is the most scheduled? (Type 3)
  • Reason: We are evaluating the critical time of the day in which the app is being used the most by analyzing the main feature. It let us see the need of scalability.
  1. Which filter is the most used for searching for tutors? (Type 3)
  • Reason: We are analyzing how useful this feature is in order to improve/modify it so we can improve UX.
  1. What is the most scheduled tutorship of the month? (Type 4)
  • Reason: With this data we can build information about what students are looking for in a certain period of the semester, so we can identify patterns and take advantage from this info.

Analytics pipeline (AP)

The Analitics pipeline gets the information from a Firestore database (NoSQL) and uses the Google Analytics functionalities to display concretized information using Firebase Dashboards. Currently, answering the business questions, the data pipeline focuses on the schedule procedure, paying specially attention over the filters the users use while scheduling, and the courses with the most scheduled sessions.

Analytics Pipeline Diagram

As Firebase Analytics uses directly information from the NoSQL Database, we don't have to make an ETL (Extract, Transform, Load) procedure over the D.B. format, but over the information collected while the user interacts with the App. This information is collected by the Analytics service once the user is using the feature (the user enters the scheduling view and choose one of the filter options) so we can have details over the time (hour, minutes, seconds, location) and information about the courses he/she is looking for.

Architectural design (AD)

System Architecture Design

For our system architecture, we are having a Layered architecture which involves organizing the system into multiple layers, where each layer represents a different level of abstraction (UI, Domain, Data). By using this architectural system, we are ensuring the maintainability and modularity of our App making it easier to develop changes, new business rules and more.

Layered

Design Patterns

  • Repository: This pattern let us managing data access. Divided into three layers (UI, Domain, Data), it ensures a clear separation of concerns. The UI layer handles user interaction, the Domain layer contains business logic, and the Data layer handle data storage and retrieval. By abstracting data access behind repositories, we can switch between different data sources (such as Firestore) without impacting the rest of the apps' code.

  • Abstract Factory: As we are having related objects while modeling our users, due to the possibility to be a tutor, a sutent, or both, we are using this pattern to modify some aspects using the User class interface.

  • DAO: We aare using Firestore as the data access mechanism. As DAO provides an abstract interface to interact with a specific type of database or persistence mechanism, Firestore DAOs encapsulates the logic of the CRUD, abstracting away the details of the Firestore API from the rest of the application.

  • Fachade: With the Facade pattern, we are simplifying the interaction between the presentation layer (UI) and the underlying business logic (Domain layer) of the dashboards access by providing an interface, so the users are not reaching the Domain Layer as it is.

List of implemented features (IF)

  1. User authentication with Firebase authentication
  2. Update profile picture using camera
  3. Profile management
  4. See associated courses
  5. Filter by course

This feature answers "How much time has passed since the user booked that math mentorship?" type 2 question, defined into Sprint 1

  1. Firebase Firestore as external service connection

Ethics video

https://youtu.be/L_yLV1z9qlY