Sprint2

Pre: Repos explanation-> We are not storing locally anything, therefore, we don't have a repository for the back. All the information about events functions through Firebase Analytics. Also, we manage the backend of the analytics engine and the front through FirebaseAnalytics, so we don't have a repo for the analytics part either. We explained this situation to our professor Mario, and he told us it was okay to have only one.

Links:

Repo Swift: https://github.com/Moviles20242-Grupo32/SwiftSprint2

Repo Kotlin: https://github.com/Moviles20242-Grupo32/KotlinSprint2

Project Swift: https://github.com/orgs/Moviles20242-Grupo32/projects/3

Project Kotlin: https://github.com/orgs/Moviles20242-Grupo32/projects/4

1. Business questions

*Mario told us the business question type 2 could be repeated among apps. In this case, we did another type 2 question but, the one that's shared is the 1.2 question bellow.

1.1 How many are the average daily interactions for search filters across all users? *Adaptation from Q10 in Sprint1 This is a Type 3 Business Question because it involves analyzing aggregated data to uncover patterns or trends related to user behavior. The question seeks to understand the average daily interactions for the search filter across all users, which requires data collection, statistical analysis, and possibly identifying correlations. Type 3 questions are typically exploratory, requiring more in-depth data analysis to provide actionable insights for improving user experience or optimizing feature usage. Even though the initial question considered other features, those were not implemented at the end, so it's impossible to measure their usage.

1.2 What was the most ordered box in the past month? *Adaptation from Q4 in Sprint1 This is a type 2 question because it directly relates to the user’s purchasing behavior and interaction with the app. The information collected from this question can be used to enhance the users daily experience by showing the users' favorite box. The original question was related to users who ordered the same box more than twice, which could be interpreted as their favorite box.

1.3 Over the past month, how many seconds does it take a user to search for, select, and aggregate products to create a new order? *Q6 from Sprint1 This is a Type 3 question because it focuses on user interaction with the app features, specifically measuring how efficiently users can complete a task (creating a new order). The insights gained from this data can directly inform changes to the user interface or experience, such as optimizing search functionality or streamlining the selection process, thereby improving daily usage for users. We just changed the word delivery for order, regarding the question in Sprint1.

1.4 What is the total number of users that have ordered in the last month? *Adaptation from Q13 in Sprint1 This is a type 4 question because it focuses on information that can be used by the company or third-party companies to take advantage of. In this case, knowing the total number of users it is possible to know the potential customers of restaurants or other companies such as touristic agencies and it can be used to benefit the app or sell this information to third-parties such as restaurants or hotels to gain valuable insights of possible customers.

1.5 What were the top most ordered boxes during the past month by a user? This is a type 2 question because reordering mystery boxes based on the user's purchase history directly enhances the user experience by providing a personalized view of the most relevant options. Users are more likely to select products they have previously enjoyed, which increases engagement and satisfaction. This dynamic ordering saves the user time by displaying their preferred items first, reducing the effort to search for them manually. As a result, the interaction becomes more intuitive, leading to a more efficient and enjoyable shopping experience.

2. Analytics pipeline

The data pipeline for the app begins with the Data Source Layer, where user interactions generate data as they use the app (making an order, using a feature, etc.). This data is captured and transmitted through the Integration Layer, where Firebase SDKs and REST APIs handle the communication between the app and Firebase. Once the data is collected, it’s stored in the Storage Layer, specifically in Firestore Database (that is the data base that has all the users, items, and orders data) and the Firebase Analytics storage (where all the data from the logs and behavior from the app is kept. Then the data from the user’s behavior is processed by the analytics engine and the data from the data base is processed locally on the app using In-app Logic all this in the Processing Layer. Finally, the processed data is displayed on the Analytics dashboard to the developers or in the app to the user all this in the Presentation Layer.

3. Architectural design

*Mario told us that we could repeat patterns in each app, so both 3 patterns are implemented in both apps.

Class diagram

Phone

Back

Components diagram

In this diagram, it can be observed the different layers that compose the MVVM architecture pattern. Also, the connection of the app to Firebase through a service adapter, managed as a singleton. These patterns would be explained in depth ahead.

Deployment diagram

In this diagram, it can be observed how the apps connect to Firebase.

3.1 Architectural pattern: we implemented a MVVM architecture.

The image shows the distribution of the files in the 3 parts. The Registration and Login views communicate with AuthViewModel, which communicates with the User in model. The Home, Profile and Cart views communicate with HomeViewModel, which communicates with Cart and Item in the Model.

Rationale: this architecture allow us to assign each component a clear responsibility and make the codebase easier to understand and maintain. Regarding Swift, SwiftUI supports reactive programming, MVVM allows for automatic UI updates when data changes. Also, SwiftUI uses bindings and @Published properties to automatically update views, creating a smoother user experience. SwiftUI naturally aligns with MVVM due to its reactive nature. MVVM allows for simpler and more intuitive SwiftUI code, leveraging property wrappers like @State, @ObservedObject, and @Published for efficient state management.

Rationale: Adopting the MVVM architecture in Kotlin provides a clear separation of concerns, which simplifies testing and maintenance. In the context of Jetpack Compose, MVVM naturally complements Compose's declarative UI by allowing the ViewModel to handle state and business logic, while the UI remains reactive to state changes. Jetpack Compose’s state management system, using State, MutableState, and LiveData or StateFlow in ViewModels, enables seamless automatic UI updates when the underlying data changes. This architecture helps maintain a cleaner, more modular codebase, making it easier to scale and refactor over time. MVVM also enhances testability by decoupling the UI from the business logic, allowing the ViewModel to be unit tested without involving the UI layer.

3.2 Design pattern 1 Service Adapter: we implemented a service adapter that is in charge of managing any access to the data base. It is called by AuthViewModel regarding authentication and user informations and it is called by HomeViewModel to manage anything related to the boxes and the orders. It is built in a class called DatabaseManager.

Rationale: this patter allows us to decouple the manipulation of the data base from actions in the View and ViewModel. Also, all the logic related to Firestore is managed in the same place. Additionally, if we needed to change the data base it would be easier.

3.3 Design pattern 2 Singleton: to avoid confusions by having 2 instances that manage the data base we implemented the singleton pattern in the service adapter.

Rationale: this pattern ensures that there is only one instance of the database manager that can be accessed globally throughout the application. This simplifies access to the database without needing to pass instances between different components or views.

4. Features

• Sensor: user's location
• Type 2 question: indicate the box that was the most ordered in the past month by all users. The data about the orders would be collected in Firebase and then, the information is retrieved to search for the most ordered box.It would be showed as a banner on top of the box.
• Context aware: when a users is within a 2km distance of a restaurant that publishes boxes in Foodies, the user would receive a push notification.
• Smart feature: text to speech that reads the available boxes and the content of the cart. This happens when the users presses on a megaphone-like button.
• Authentication: the app is connected to the authentication service of Firebase
• External services: the app retrieves information of the boxes from Firestore and sends the completed orders
• Business questions: registers events to complete business questions

Additional: add boxes to cart, search boxes by name, increase or decrease amount of a box in the cart, delete a box from the cart, check out or cancel an order.

5. Implementation of data pipeline and business questions

Our data pipeline is based on Firebase. Firebase allows to register events and parameters related to this events through Firebase Analytics. These events are stored in Firebase in the analytics section, that will serve as the backend. Depending on the business question, we create audiences (which are groups of users related to specific events). Also, we use the Firebase Analytics front, in which we develop graphs and reports.

Business question 1.1: We generate an event each time the user uses the search bar. Specifically, when 0.8 seconds pass, and the user hasn't typed anything else. This event is sent to Firebase Analytics, along with the parameter search_term, which is basically what the user searched for. We sent this information to the analytics Dashboard, which allows us to show various important metrics: the amount of users that have used it in the past 30 days, the average amount of time a users has used it and the average amount of times a user uses it per session. We also generated a report, which shows out of all users the amount of users that used this feature. An example of this is shown below.

Business question 1.2: In this case, we each box, or as we call it in our model, Item, has an attribute that indicates the amount of times it has been ordered. It is updated each time and order is generated. This information is updated in Firebase. When a user opens the app, all the items from Firebase are fetched and a search for the item that has been ordered the most is done. Later, an orange star is placed on top of the most ordered box, or the favorite box.

Swift:

Kotlin:

Business question 1.3: We generate an event each time the user adds a product to the cart and each time the user clicks on the button to proceed to checkout. We use the information captured in this events to calculate the average time the user takes to select his/her products and proceed to checkout. This information is sent to Firebase Analytics as a single variable with the elapsed time (in seconds) since the user first clicked a product to add it to the cart until the user is ready to create his/her order and clicks on the proceed to checkout button. We send this information to the analytics Dashboard, which allows us to show a relevant metric: the ratio of the amount of users that take more than 10 seconds to create an order as compared to the rest of the users.

Business question 1.4: We generate an event called purchased each time a user click the checkout button to register the action and the price the user spent. This information is uploaded to Firebase Analytics as an integer value.This allows to track how much is the average amount spent by an user so it can be used later to the advantage of the app or sold to third-party companies.

Business question 1.5: We generate an event each time a user places an order for a mystery box. The event is triggered when a user selects items and completes the order by clicking the checkout button. This event captures parameters such as item_name, item_cost, and item_quantity. Additionally, each item has a times_ordered attribute that is updated with the number of times the user has ordered that particular box. By using this information, we dynamically reorder the mystery boxes based on user preferences to enhance personalization and improve the user experience.

6. Architectural and design patterns

Explanation in literal 3

7. Views

Swift:

• 1. Login, Register, Profile

• 2. Home

• 3. Cart

Kotlin:

• 1. Login, Register, Profile

• 2. Home

• 3. Cart

8. Functionalities

a) Sensor

Swift

Kotlin

b) Type2

Swift

Kotlin

c) Context aware

Swift

Kotlin

d) Smart Features

Swift

Kotlin

e) Authentication

Swift

Login:

Registration:

Kotlin

f) External

9. Collaboration

*You can find more in the different projects, which links are at the top part of this Wiki. Also, you can direct to the milestones in the different repositories.

Stablished rule sets

10. Individual

• Swift Milestones

https://github.com/Moviles20242-Grupo32/SwiftSprint2/milestones

Board

https://github.com/orgs/Moviles20242-Grupo32/projects/3

• Kotlin

Milestones

https://github.com/Moviles20242-Grupo32/KotlinSprint2/milestones

Board

https://github.com/orgs/Moviles20242-Grupo32/projects/4

11. Ethical component

https://www.youtube.com/watch?v=WTW_z0KQzIY