Sprint 4

Link repo Swift: https://github.com/Moviles20242-Grupo32/SwiftSprint2.git

Link repo Kotlin: https://github.com/Moviles20242-Grupo32/KotlinSprint2.git

Swift project and kanvan board: https://github.com/orgs/Moviles20242-Grupo32/projects/8

Kotlin project and kanvan board: https://github.com/orgs/Moviles20242-Grupo32/projects/11

Kotlin apk file: https://appdistribution.firebase.dev/i/f0f5861a9c2e82ef

Everything is implemented

We explain the value proposition in terms of the following criteria.

Feature-Driven User Experience Personalized Location Awareness: Notifications are sent to users when they are within a 2km radius of a participating restaurant, ensuring they never miss out on nearby deals. Smart Box Discovery: Highlight the most-ordered surprise box from the past month as a banner to guide users toward popular choices. Voice-Enabled Interaction: A text-to-speech feature reads out available boxes and cart contents when users activate the megaphone button, enhancing accessibility and convenience.

Enhanced Shopping & Order Management Dynamic Cart Control: Users can add, remove, increase, or decrease items in their cart directly from the Home or Cart views. Quick Reorders: Add all items from the last order to the cart with a single tap, simplifying repeat purchases. Detailed Insights: View item details to make informed decisions about surprise box purchases. Real-Time Order Tracking: Access current orders and their locations on an integrated map for easy pickup coordination.

Intelligent Search & Filtering Smart Filtering: Users can filter by top-rated (5-star) boxes or based on their latest search query. Customized Query Search: Tailor results to specific preferences, making box discovery faster and more intuitive.

Seamless Account Management & Authentication Secure Firebase Authentication: Log in, log out, and register effortlessly while keeping user data secure. Profile Management: Users can view and manage their profiles with ease.

Business Intelligence & Data Insights Actionable Metrics: Firebase tracks and registers user interactions to provide insights for continuous business improvement and customer satisfaction. Order Records & Trends: Understand user preferences by tracking orders, ranking boxes, and identifying popular choices.

Sustainability & Value Support for Zero Waste: Foodies bridges the gap between surplus food and eco-conscious users by offering discounted surprise boxes, driving sustainability efforts. Affordable Dining: Customers enjoy 50% off delicious meals while helping businesses reduce food waste.

Foodies App empowers decision-making and enhances user engagement by systematically collecting and analyzing data through key business questions. These insights enable the app to continuously evolve and deliver value to both users and partner establishments.

Understanding User Behavior Search Trends and Interactions: Analyzing the most searched terms and average daily interactions with filters allows the app to refine search functionality, making it more intuitive and aligned with user preferences. Time Efficiency: Tracking the time it takes for users to complete an order journey helps optimize the app's interface for quicker transactions.

Enhancing Notifications & Engagement Location-Based Notifications: Insights on how many users received proximity notifications ensure the system's effectiveness in driving foot traffic to participating restaurants. Order Completion Reminders: Evaluating the percentage of users notified about incomplete orders highlights opportunities to convert potential drop-offs into completed transactions.

Promoting Key Features Feature Adoption Metrics: Tracking the usage of functionalities like last-order reordering, product detail views, and order tracking informs feature prioritization and improvement. Filter Efficiency: Measuring the use of advanced filters (e.g., 5-star boxes, recent searches) ensures that these tools meet user needs and drive satisfaction.

Driving Restaurant and Box Optimization Box Popularity and Ordering Trends: Identifying the most ordered boxes, restaurants, and cost-effective options provides data to refine offerings and pricing strategies. Order Timing Insights: Knowing peak order times helps participating establishments optimize their inventory postings for maximum impact.

Financial and Historical Insights Spending Analysis: Understanding the historical average spent by users helps tailor promotions and loyalty rewards. Participation Metrics: Monitoring total orders and percentage usage of app features helps measure growth and customer retention.

Actionable Data for Continuous Improvement User-Centric Evolution: By analyzing feature usage percentages and trends, the app evolves to match user expectations, creating a more engaging and efficient experience. Enhanced Restaurant Collaboration: Insights from business questions empower partner establishments to align their surplus food strategies with user demand.

Foodies' value proposition is rooted in creating a win-win ecosystem for users and partner establishments while maintaining a sustainable and competitive revenue model inspired by proven industry benchmarks.

Revenue-Generating Model Commission-Based Profitability: By retaining 30% of the price shown to consumers, Foodies aligns with industry standards, ensuring profitability while offering affordable surplus food. This approach leverages the success of Food Tech giants like Uber Eats. Efficient Cost Management: A gross profit margin of 7.8% on the commission translates to a 26.1% margin relative to the consumer price, providing a competitive edge while sustaining operational health.

Controlled Costs of Goods Sold (COGS) Packaging and Logistics: With COGS at 22.2%, the model ensures high-quality packaging and efficient logistics while minimizing waste and retaining profitability. This focus reinforces the app’s commitment to food sustainability.

Net Profit Optimization Strategic Expense Management: Based on Uber Eats’ operational metrics, Foodies anticipates a net profit margin of 5.4%, factoring in delivery compensation, marketing, vehicle maintenance, technology upkeep, and administrative costs. Focused Marketing Investment: Initial marketing efforts will represent a significant but controlled expenditure to boost visibility and user acquisition, mirroring industry best practices where marketing accounts for the majority of operational costs.

Value for Partner Establishments Revenue Sharing: The 70% share for participating restaurants and bakeries incentivizes collaboration, turning potential food waste into a revenue stream. Increased Foot Traffic: Push notifications and location-based alerts drive customers to physical locations, offering an additional upselling opportunity for establishments.

Affordable, Sustainable Options for Consumers Cost-Effective Pricing: Consumers enjoy surprise boxes at 50% off regular prices, creating a unique value proposition that aligns with the app’s goal to reduce food waste and support eco-conscious consumption.

Market Position and Scalability Sustainable Growth: By balancing competitive commission rates with controlled operational expenses, Foodies is positioned to achieve sustainable growth and profitability while scaling its operations. Proven Success Metrics: Emulating industry leaders ensures the app’s revenue model is robust, with a focus on long-term value for users, partners, and stakeholders.

Foodies' value proposition leverages robust data collection and analytics to optimize operations, enhance user experiences, and empower decision-making for both consumers and partner establishments. The data collected serves as the backbone of the platform's functionality and growth, enabling smarter and more sustainable solutions.

User Behavior Insights Search Patterns: Data on the most searched terms, filters, and categories helps identify user preferences and tailor the app’s offerings. For example, tracking which filters (e.g., 5-star ranked boxes) are most used provides actionable insights for marketing and partner engagement. Engagement Metrics: Monitoring daily interactions with filters and the average time users take to complete an order provides valuable data for improving app usability and streamlining the order process.

Operational Optimization Order Data: Collecting information about the most ordered boxes and the time slots with the highest activity allows Foodies to recommend optimal posting times to partners, improving their sales performance. Notification Effectiveness: Data on the percentage of users who respond to location-based or incomplete-order notifications enables refinement of these features to maximize engagement and conversions.

Customer Experience Enhancement Feature Usage: Insights into how users interact with features like “Last Order,” product detail views, and order tracking enable Foodies to prioritize enhancements and add new features that align with user needs. Proximity Awareness: Tracking when users are near partner establishments allows for personalized, real-time notifications, increasing the likelihood of purchase while fostering convenience.

Business Intelligence for Partners Demand Trends: By analyzing the top-performing mystery boxes and restaurants, Foodies equips partners with data to optimize their offerings and pricing strategies. Consumer Behavior: Reports on purchase frequency, average spending, and peak activity periods empower restaurants to adjust inventory and marketing tactics effectively.

Sustainability Metrics Impact Tracking: Data on the number of boxes sold and food items saved from waste provides measurable insights into Foodies' environmental impact, appealing to eco-conscious users and stakeholders.

Growth and Revenue Insights Monetization Analysis: By tracking average spending per user and the effectiveness of marketing campaigns, Foodies ensures sustained revenue growth while optimizing customer acquisition costs. Trend Identification: Historical data on user spending and order patterns enables long-term planning and expansion into new markets.

Actionable Analytics for Marketing Targeted Campaigns: Understanding user preferences, such as the popularity of specific restaurants or boxes, allows Foodies to create highly targeted marketing campaigns, maximizing ROI. User Retention: Data on incomplete orders or feature usage helps identify areas to reduce churn and improve user retention strategies.

In this first micro optimization part, we focused on the usage of for eachs, the elimination of commented code and the lifecyle of the objects. We grouped these 3 items as implementing this micro optimizations has specially an effect over the memory consumption. Therefore, including or using them would show a decrease in the usage of memory. In general what we did was use indexed loops instead of iterator and for-each loop, use the lifecycle methods properly to avoid memory/energy leaks and eliminate commented code that wasn't necessary to decrease the compilation time.

3.1.1 Profiling before and after

In the before memory profiling scenario, that the in total 116.23 MiB were consumed, that heaps and allocations used 79.27 MiB and that all anonymous Vm used 36.96 MiB. These numbers decreased to 78.28MiB, 51.05MiB and 27.23 MiB accordingly. Specially, there is a decrease in CoreServices, CoreAnimation, Malloc and SQLite. Indexed loops reduce memory overhead by avoiding iterator creation, leading to fewer heap allocations (79.27 MiB to 51.05 MiB). Deleting commented-out code minimizes unnecessary metadata parsing, reducing CoreServices and CoreAnimation memory usage. Efficient use of lifecycle methods ensures resources are initialized, used, and disposed of appropriately, decreasing memory consumption by avoiding redundant or lingering objects. These changes collectively contribute to lower total memory usage (116.23 MiB to 78.28 MiB) and improved performance.

Also, in this image, you can see there aren't any memory leaks anymore.

3.1.2 Code before and after

Usage of loops: In this images you can see an example of how 2 frequently used methods were transformed from using for eachs loops to indexed loops.

Commented code: In the following image you can see an example on how big chunks of commented code were deleted. In this case, we just eliminated the code, that's why it wasn't necessary showing an after image.

Deleting previews: In the following image you can see an example on how previews were eliminated as they are of no use now, so that code was not running at all. In this case, we just eliminated the code, that's why it wasn't necessary showing an after image.

Eliminate unused objects: In the following image you can see an example on how we eliminated various objects that were not being used. In this case, we just eliminated the code, that's why it wasn't necessary showing an after image.

State to observed: In the following image you can see an example on how we corrected the lifecycle of many objects that was incorrect, in this case from State to observable.

We also did an extensive elimination of unused resources including libraries and dependencies. We did a profiling in CPU usage for 2 different scenarios, when we deleted everything regarding Firebase crashalitics and regarding Firebase analytics. In the case of crashalitics, you can see that there was initially a thread that consumed 33.8% of all the CPU 2.14s and specially, a FIRCLSBinaryImageRecordSlice that lasted 1.81s. All of the elements that consumed CPU in that deployment or detail of that thread, come from FirebaseCrashalitics that wasn't actually being used. In the after image, you can see that that thread disappeared entirely and that the CPU consumption related to it as well. It was installed as a library for future usage but as it was not used, it was eliminated. In the case of analytics, there was a thread that was 5.2% of CPU. Almost every element related to that consumption comes from using Firebase Analytics. We used that in the first sprint for business questions but we changed of strategy. Therefore, the libraries and the code related to it should be eliminated. By doing so, you can see in the after image that the thread in charged of managing events related to analytics disappeared. In conclusion, the observed improvements are a direct result of eliminating unused libraries and dependencies, such as Firebase Crashlytics and Firebase Analytics. These libraries, even when not actively used in the application, spawn background threads and consume CPU resources to handle their respective tasks.

3.2.1 Profiling before and after

3.2.2 Code before and after

Remove import of Firebase analytics in the CartView.swift file

Remove usage of Firebase analytics to load events in the CartView.swift file

Remove import of Firebase analytics in the Home.swift file

Remove usage of Firebase analytics to load events in theHome.swift file

Remove unnecessary file of AnalyticsView.swift

Eliminate unused packages and dependencies

This last case of micro optimizations focused on avoid creating unnecessary objects. One of the things that our app uses constantly was colors and not the pre defined in XCode but from a color palette that we decided. Therefore, we were using specific RGB codes for the color. The problem was even though we only used 4 different color, every time that we needed to use one, we created an object. This resulted in having more than a 100 objects related to colors. What we did was define a color class and it's attributed were the 4 colors that we constantly used and we just called this class every time we needed to add a color. As you can see in the image, everything related to color in the memory profiling decreased.

3.3.1 Profiling before and after

3.3.2 Code before and after

This first image shows the using color objects before the micro optimization.

This image shows that for default color we used foreground and the usage of attributes (from the color class)

We also corrected things related to off screen rendering, in this case the initial banner was generating a great consumption, so we adjusted it and simplified it.

In Kotlin, the ShoppingViewModel is critical for managing key user interactions within the GUI, but it faced performance issues related to object creation during iterations. High-level methods like forEach, find, none, and filter were generating unnecessary intermediate objects, so the first optimization replaced these methods with index-based loops to reduce overhead. Additionally, many temporary objects were created during iterations instead of reusing references, leading to increased memory usage. The second optimization addressed this by recycling temporary references wherever possible, improving efficiency and reducing resource consumption in the app.

3.1.1 Code before and after

Some of the modify codes are presented bellow

Remove for each and similar methods and replace it with index iterations

During the app development process, several libraries were tested or temporarily integrated, and some were later replaced with better alternatives. However, traces of these unused libraries often remained as imports in the codebase, inadvertently increasing the size of the APK. To address this, a second micro-optimization focused on identifying and removing these redundant imports and unused dependencies. By carefully auditing the project and eliminating unnecessary references, the APK size was significantly reduced, improving app performance, reducing download times, and optimizing storage usage for end-users. This cleanup also streamlined the codebase, making it easier to maintain and less prone to dependency-related issues in the future.

3.2.1 Code before and after

View modesl and model modifications

The optimization in the ViewModel involved exposing MutableLiveData directly to the views, eliminating the need for separate LiveData objects for data transformation and presentation. This change reduced memory allocations, as it removed the redundancy of maintaining two objects per attribute—one for modification (MutableLiveData) and one for observation (LiveData). The direct exposure of MutableLiveData simplified the codebase, improved performance by reducing object creation, and maintained functionality by allowing the views to observe data changes. However, careful attention is required to ensure that the data is not unintentionally modified by the views, preserving the intended data flow and logic.

3.3.1 Code before and after

View models modified

The microoptimizations implemented in the code primarily targeted memory usage to enhance performance by reducing unnecessary memory consumption, minimizing memory allocations, and lowering the frequency of garbage collector events. These optimizations led to significant improvements in several performance metrics. First, memory consumption was reduced by 20MB, with Java heap allocations dropping from 53MB to 28.4MB. This reduction in memory usage helps ensure that the app runs more efficiently, with less strain on system resources. Secondly, the frequency of garbage collection events was reduced, which is critical for avoiding performance degradation caused by frequent memory clean-up cycles. The number of garbage collection events decreased from 13 to 9, indicating fewer interruptions in the app's execution. Finally, the number of memory allocations was also optimized, leading to approximately 300,000 fewer allocations. The total allocations reduced from 916K to 613K, minimizing the overhead of object creation and helping to maintain smoother app performance. Overall, these optimizations contributed to better memory management, less strain on the garbage collector, and improved application responsiveness.

3.4.1 Profiling before the optimizations

Memory conssumption:

Memory usage:

3.4.2 Profiling after the optimizations

Memory conssumption:

Memory usage:

Notification of no placed order

Notification of promotion

Promotion notification

use of workers to send the notification assited with the notification manager implemented on lastest sprints

Save last order in the cache, and add the items from that last order to the cart.

Button to add the items from the last order to the cart:

When an order is made the order is saved in the cache:

The home view model calls the cache manager:

In the cache manager the order is saved in the cache:

When the button for adding the order is pressed the items saved on the cache from the last order are added to the cart:

The home view model gets the items calling the function to get the last order and adds them to the cart:

The getLastOrder function gets the items form the last order from the cache manager:

In the cache manager the last order is retrieved from the cache:

When the user uses the button, the last order is loaded from the cache using lruCaching and added to the cart.

When the user places the order, the items are saved in cache for future use and then loaded.

Save last order in SQLite, and restore the cache with it in case the cache is deleted

In the cache manager when an order is saved on the cache its is set also in SQLite:

When the order is being set first the database is cleared so there is only the register of the last order:

When the home view model tries to get the last order from the cache and it is empty it tries to restore it from the local storage:

The cache manager restores the cache with the last order in the local storage:

This function retrieves the last order from the local storage:

If there is an active order it is stored in shared preferences in order to show the track the order button.

No track orders when no internet

No use of star filter when no internet

No use of latest search filter when no internet

This feature is designed to handle scenarios where users lose internet connectivity, ensuring a smooth and intuitive experience. It dynamically adjusts the user interface based on the current connectivity state. When the app detects a loss of internet connection, it provides fallback visuals, such as a placeholder shimmer effect (ShimmerEffectMap), to inform users that certain functionalities are temporarily unavailable.

By proactively addressing connectivity interruptions, the feature ensures that users are never presented with blank or unresponsive screens. Instead, they are provided with clear feedback, maintaining confidence in the app’s reliability. This real-time responsiveness enhances the user experience, ensuring usability even during periods of network disruption.

Business questions from Sprint 2: Type2: 2 Type3: 2 Type4: 1

Business questions from Sprint 3: Type2: 2 Type3: 2 Type4: 2

Business questions from Sprint 4: Type 1: 0 Type2: 0 Type3: 2 Type4: 1 Type 5: 2

Total business questions: Type 1: 0 Type2: 4 Type3: 6 Type4: 4 Type 5: 2

Looker studio dashboard link: https://lookerstudio.google.com/reporting/39517ad3-1145-4436-b807-8f79cbf5265b

SS of the dashboard:

Is a Type 4 question as it leverages internal data (search terms) to generate insights that primarily benefit the business or third parties rather than the users directly. The business can use this data to identify trending food items, restaurants, or categories, enabling collaboration with third-party stakeholders such as advertisers or supermarkets, monetizing trends, and developing targeted marketing strategies.

To implement this, a debounce mechanism in the ViewModel prevents redundant writes to Firebase by delaying term registration until 800 ms of inactivity. Filtered search terms are stored in the searchUse collection using batch writes in the ServiceAdapter, including details like the term, timestamp, and user ID.

In GCP, BigQuery processes this data, extracting terms (finalValue) from the JSON structure in the DATA column, counting occurrences (COUNT(*)), grouping by term, and ordering by frequency. The query ultimately returns the most searched term and its frequency, empowering the business to capitalize on search trends for strategic decisions.

This is a business question type 5 as it mixes type 3 and 4. First, type 3 as it indicates developers how many notification are actually sent, measuring the usage of this feature. Finally, it is type 4 as it indicates Foodies and even the establishments how well they are placed, if they are near where the users are located.

This is a business question type 5 as it mixes type 3 and 4. First, type 3 as it indicates developers how many notification are actually sent, measuring the usage of this feature. Finally, it is type 4 as it indicates Foodies and even the establishments how likable their products are as less notifications the fastest are the users placing an order without they being reminded of it.

This is a tyoe 3 question because is directly related to a feature from the app. Based on the answer to this question developers can decide whether to keep or remove the feature depending on how many users have used it.

This is a Type 4 question because it allows restaurants to see what percentage of users are viewing the details of their products. This information helps them understand if their products are getting significant attention from users, which they can then compare with the sales figures of those products. It provides valuable insights for the restaurants to assess product engagement and make more informed decisions.

To estimate the percentage of users who looked at the details of a product, the data from Firebase Firestore (stored in the "item_detail" collection) can be analyzed through SQL queries in BigQuery. This collection captures user interactions, specifically when a user clicks to view the details of a product, and records which product has been reviewed.

Below is an example of an SQL query that calculates the percentage of users who have viewed the product details:

6.6.1 Type justification: This question is type 3 because it evaluates the utilization of a feature, indicating the developers how it is used and how could they make the app features better.

6.6.2 Development:

In the first place, the logic for the business question was implemented in the app. The logic was first added to the singleton DatabaseManager class, then to the HomeViewModel class, and finally to the OrdersHistoryView. The following three images show the changes made in each file.

Changes to the DatabaseManager:

Changes to the HomeViewModel:

Changes to the OrdersHistoryView:

After the implementation of the business question logic, we proceeded to create a collection to store the BQ data in our Firestore Database. We then connected this collection with big query through a firebase extension for the automatic streaming of the data.

Finally, we wrote and executed the following sql query to obtain the answer for our business question:

Sprint 2

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

Add and remove items from the cart in the home and in the cart view

Increase and decrease the quantity of a box in the cart

Place an order

View profile

Filter by a query

Log in and out out

Register

Sprint 3

Filter by the 5 star ranked boxes

Filter by the the latest search

Sprint 4

Add all the items of the last order to the cart

View the detail of an item

View all the current orders

View in the map the order

Referred in literal 6

• The dashboard has a page for the questions of each sprint

Referred in literal 4.d

Referred in literal 4.c

Referred in literal 4.a

Referred in literal 4.b

APK file:

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

Gitflow

Swift

Kotlin

12. Individual

12.1 Milestones

Swift

Kotlin

12.2 Boards

An issue is always assigned to a milestone and a team member.

Swift

Kotlin