Development Flutter:

• Juanes:

  • Part 1

    • Type 4 Question: Which are the most used tags (chilling, studing, teaching) in bookings (by building + time window)?
    • Rationale: identify the common ways in which the rooms are being used.

  • Part 2

    • A: Clean Architecture
    • P: Repository Pattern, Use Case Pattern, Dependency Injection, Data Model Pattern (DTO),

  • Part 3

    • Screens: Header, Footer, Bookings, Homepage.

  • Part 4

    • Sensors: Used: GPS for CA / Inplemented: Light – Dark in Flutter.
    • CA: Recomends Based on the current location of the user.
    • SF: Location based recomendations on nearby rooms (frontend in flutter)

• Daniel:

  • Part 1

    • BQ 9: What is the most common way users upload/import their schedule (ICS file, manual), and which method has the highest drop-off by step?
    • Rationale: Invest in the winning method and remove friction in the losing one (permissions, formats, UX).

  • Part 2

    • A: Clean Architecture
    • P: Repository Pattern, Use Case Pattern, Dependency Injection, Data Model Pattern (DTO),

  • Part 3

    • Screens: Schedule (3), Login, Sign up

  • Part 4

    • Sensor Used: Light Sensor for CA
    • Type 2 Question: Which rooms should the app recommend to a user during their free schedule gaps, based on their daily behavior, preferred buildings/floors, and upcoming classes?
    • CA: It detects when the phone's light level is low and switches the theme to dark mode.
    • SF: Gap-based room recommendation with fixed weights (Front y Back)
    • Auth: Sign Up and Login In
    • ES: Smart room recommendation based on the uploaded schedule (connected in the Backend)

• Cesarín:

  • Part 1

    • Type 2 Question: For a user near a building (or with approximate location), what are the top N “Available now” rooms ordered by estimated walking time, including the room status last-updated timestamp?

  • Part 2

    • A: Clean Architecture
    • P: Repository Pattern, Use Case Pattern, Dependency Injection, Data Model Pattern (DTO).

  • Part 3

    • Screens: Room Detail, Search Results.

  • Part 4

    • Sensor Used: GPS for SF and CA.
    • CA: Recomends Based on the current location of the user.
    • SF: Location based recomendations on nearby rooms (backend development of the navigation graph and dijkstra)
    • ES: Smart room recommendation based on the uploaded schedule (connected in the Backend)

Architectural Design and Patterns - Flutter

1. Clean Architecture + Feature-First

• Clean Architecture (Vertical): Divides the code into Presentation (UI/Controllers), Domain (Pure Logic/Contracts), and Data (Infrastructure/API). The golden rule is independence: the business logic remains decoupled from the framework and external tools.

• Feature-First (Horizontal): Organizes the project by functionality (auth, rooms, bookings). Each feature acts as a "mini-project" containing its own Clean Architecture layers.

2. Design Patterns

• Repository Pattern: Acts as a mediator. The Domain requests data through an interface (contract), and the Data layer decides whether it comes from Dio (Backend) or a local cache. This allows changing the data source without affecting the UI.

• Use Cases (Interactors): Represent a single business action (e.g., SearchRooms). They prevent controllers from becoming bloated with logic, allowing the same action to be reused across different parts of the app.

• Dependency Injection (DI): Implemented via Riverpod. Classes do not manually instantiate their dependencies; they receive them. This enables injecting mock versions for testing or global services (like Analytics or Session) in a clean, centralized way.

• StateNotifier (Controller): Manages the UI state in a reactive and immutable manner. The controller receives user events, triggers the Use Case, and emits a new state that the UI redraws automatically.

• Data Transfer Object (DTO): Classes within the Data layer that map raw JSON from the backend. They are then mapped into Entities before reaching the Domain to ensure the business logic only handles validated, typed data.

---

Development Kotlin:

Developers

• Gabriel:

  • Part 1

    • Type 3 Question: Which filters (place, time, utilities, close to me) are applied most often?
    • Rationale: simplify UI (defaults, quick filters) and reduce taps when users are in a rush.

  • Part 2

    • A: MVVM
    • P: Repository Pattern

  • Part 3

    • Screens: Header, Footer, Bookings, Homepage.

  • Part 4

    • Sensors: Used: GPS for CA / Inplemented: Light – Dark in Kotlin.
    • CA: Recomends Based on the current location of the user.
    • SF: Location based recomendations on nearby rooms (frontend in kotlin)

• Juan David:

  • Part 1

    • Type 2 BQ: Where in the app do students spend the most time browsing?.
    • Rationale: identify which available rooms satisfy a user’s specific time gap and required utilities to speed up decision-making.

  • Part 2

    • A: MVVM
    • P: Repository Pattern

  • Part 3

    • Screens: Results, Room Detail

  • Part 4

    • Sensors: GPS for CA
    • CA: Nearby recommendations
    • SF: User-based recommendations

• Mateo:

  • Part 1

    • Type 3 BQ: Where in the app do students spend the most time browsing?.
    • Rationale: identify most used screens on the app so they can be used to put adds and the dev team can shift the GUI to benefit that functionality or others.

  • Part 2

    • A: MVVM
    • P: Singleton Pattern

  • Part 3

    • Screens: Upload your Schedule, View your Schedule, Login, Sign up

  • Part 4

    • CA: It detects when the phone's light level is low and switches the theme to dark mode.
    • Auth: Sign Up and Login In (Backend and Front)

Architecture Diagram

Rationale:

This diagram presents a layered architecture following an MVVM pattern, organized from left to right to reflect the system’s data flow.

On the left, the Presentation Layer contains the UI components (Screens) and their corresponding ViewModels. Screens handle user interaction, while ViewModels manage UI state and delegate operations, ensuring a clear separation between interface and logic.

Moving to the center, the Data Access Layer is represented by the AppRepository, which implements the Repository pattern. This component acts as a single source of truth, centralizing data operations and decoupling the ViewModels from data sources.

On the right, the Infrastructure layer provides external services and shared resources through Singleton components such as the NetworkModule and AnalyticsSessionManager. The ApiService (via Retrofit) handles communication with external APIs.

The overall flow goes from Screens → ViewModels → Repository → Infrastructure services, with responses propagating back in the opposite direction. This structure ensures low coupling, clear responsibility separation, and maintainability.

• MVVM (Model-View-ViewModel): We used it because it’s the standard architectural pattern for Kotlin. It’s used to separate UI from business logic, improving testability and lifecycle management in Android.

• Repository Pattern: Centralizes data access and abstracts data sources, enabling cleaner architecture and easier maintenance. For example, AppRepository talks to NetworkModule.apiService so ViewModels can call things like login, search rooms, bookings, and analytics without dealing with HTTP directly.

• Singleton: Ensures a single shared instance for global resources, reducing overhead and maintaining consistency. For example, NetworkModule, so the app uses one API client.

• Observer Pattern: Enables reactive UI updates by allowing ViewModels to notify the UI automatically when data changes. For example, StateFlow in the ViewModel and the screen observing it to update what you see without manual refresh.

Pipeline

List of Implemented Features

Ethics Video

To watch this video you have to be authenticated with an Uniandes account