• 1. Value Proposition
  • 1.1 Student-Side Value
  • 1.2 University / Athletics Value
  • 1.3 Sponsor & Merchant Value
  • 1.4 Revenue Model Supported by These Metrics
  • 1.5 The Data Loop in Practice
  • 1.6 Bottom Line
• 2. Micro-optimisations Strategies
• 3. Functionalities and design details
  • 3.1 Delivered features
  • 3.2 BQ
  • 3.3 Details for BQ of Sprint 4
  • 3.4 EC Strategies
  • 3.4 Local Storage Strategies
  • 3.5 Multi-threading Strategies
  • 3.6 Caching Strategies
• 4. Ethics Video
• 5. Contributions

1. Attendance backed by evidence
   • Every geofence trigger is timestamped, so staff can see raw counts of students who were physically “at” or “near” a venue before and after we launched alerts.
2. Targeted promotion of under-attended sports
   • A dashboard ranks sports by total bets. Disciplines with the lowest counts directly answer our Type 3 question “Which event series gather the least attention?”—giving marketers a clear list of teams to boost.
3. Operational peace-of-mind on game day
   • Weekly boards for API error frequency and endpoint latency (Type 1 questions) let dev-ops fix bottlenecks before traffic spikes, protecting the fan experience.

1. Capture – GPS pings, bet logs, product views, API telemetry.
2. Insight – Dashboards answer Type 1 (reliability), Type 2 (contextual triggers), and Type 3 (engagement gaps).
3. Action –
   • Send timely alerts → more bets → more marketplace browsing.
   • Surface low-engagement sports → targeted promos → broader fan base.
   • Fix slow endpoints → smoother UX → fewer abandoned actions.

The same data that powers user delight is repackaged as attribution proof for sponsors and as optimisation fuel for our own monetisation flows.

Campus Picks moves students from passive scrolling to active cheering by combining real-time proximity alerts, frictionless virtual bets, and an on-the-spot merch store. The university receives concrete attendance and engagement numbers, sponsors get audit-ready exposure stats, and we generate sustainable income through ads, gear sales, and a planned premium layer—all validated by the metrics already live in our dashboards.

- liveMatches     = matches.where((m) => m.status.toLowerCase() == 'live').toList();
- upcomingMatches = matches.where((m) => m.status.toLowerCase() == 'upcoming').toList();
- finishedMatches = matches.where((m) => m.status.toLowerCase() == 'finished').toList();
+liveMatches.clear();
+upcomingMatches.clear();
+finishedMatches.clear();
+
+for (final m in matches) {
+  switch (m.status.toLowerCase()) {
+    case 'live':     liveMatches.add(m);      break;
+    case 'upcoming': upcomingMatches.add(m);  break;
+    case 'finished': finishedMatches.add(m);  break;
+  }
+}

Single-pass bucketing is a micro-optimisation because it tweaks just a few statements without touching design or complexity:

• Scope – limited to one assignment block; no new classes or APIs.
• Complexity – stays O(n); logic still traverses the list once, only redundant passes are removed.
• Benefit – two extra list scans and three temporary lists are eliminated, cutting CPU time and allocations during every fetch.

Screenshots Before Micro-optimisations:

Screenshots After Micro-optimisations:

+  static const AndroidNotificationDetails _basicAndroid =
+      AndroidNotificationDetails(
+        'basic_channel_id',
+        'Basic Notifications',
+        channelDescription: 'Notifications for nearby events',
+        importance: Importance.max,
+        priority: Priority.high,
+      );
+
+  static const AndroidNotificationDetails _liveAndroid =
+      AndroidNotificationDetails(
+        'live_channel',
+        'Live Events',
+        channelDescription: 'Notifications for live events near you',
+        importance: Importance.max,
+        priority: Priority.high,
+      );
+
+  static const AndroidNotificationDetails _liveBetAndroid =
+      AndroidNotificationDetails(
+        'live_channel',
+        'Live Events',
+        channelDescription: 'Notifications for live events near you',
+        importance: Importance.max,
+        priority: Priority.high,
+        actions: [
+          AndroidNotificationAction(
+            'bet_now_action',
+            'Bet Now',
+            showsUserInterface: true,
+          ),
+        ],
+      );
+
+  static const NotificationDetails _basicDetails =
+      NotificationDetails(android: _basicAndroid);
+  static const NotificationDetails _liveDetails =
+      NotificationDetails(android: _liveAndroid);
+  static const NotificationDetails _liveBetDetails =
+      NotificationDetails(android: _liveBetAndroid);


-Future<void> _showNotification({
-  required String title,
-  required String body,
-}) async {
-  const AndroidNotificationDetails androidDetails = AndroidNotificationDetails(
-    'basic_channel_id',
-    'Basic Notifications',
-    channelDescription: 'Notifications for nearby events',
-    importance: Importance.max,
-    priority: Priority.high,
-  );
-  const NotificationDetails details = NotificationDetails(android: androidDetails);
-
-  await flutterLocalNotificationsPlugin.show(0, title, body, details);
-}

+Future<void> _showNotification({
+  required String title,
+  required String body,
+}) async =>
+    flutterLocalNotificationsPlugin.show(0, title, body, _basicDetails);

-Future<void> _showLiveMatchNotification({
-  required MatchModel match,
-  required double distanceInKm,
-  required bool withBetNow,
-}) async {
-  AndroidNotificationDetails androidDetails;
-  if (withBetNow) {
-    androidDetails = const AndroidNotificationDetails(
-      'live_channel',
-      'Live Events',
-      channelDescription: 'Notifications for live events near you',
-      importance: Importance.max,
-      priority: Priority.high,
-      actions: <AndroidNotificationAction>[
-        AndroidNotificationAction('bet_now_action', 'Bet Now', showsUserInterface: true),
-      ],
-    );
-  } else {
-    androidDetails = const AndroidNotificationDetails(
-      'live_channel',
-      'Live Events',
-      channelDescription: 'Notifications for live events near you',
-      importance: Importance.max,
-      priority: Priority.high,
-    );
-  }
-  NotificationDetails details = NotificationDetails(android: androidDetails);
-
-  ...
-
-  await flutterLocalNotificationsPlugin.show(
-    withBetNow ? 1 : 2,
-    withBetNow ? 'Live Event - Bet Now!' : 'Live Event Nearby',
-    '${match.homeTeam} vs ${match.awayTeam}\nDistance: ${distanceInKm.toStringAsFixed(2)} km \n coords: ${match.location.lat}, ${match.location.lng} \n location: La caneca',
-    details,
-    payload: jsonEncode(payloadMap),
-  );
-}
+Future<void> _showLiveMatchNotification({
+  required MatchModel match,
+  required double distanceInKm,
+  required bool withBetNow,
+}) async {
+  final NotificationDetails details =
+      withBetNow ? _liveBetDetails : _liveDetails;
+
+  final payloadMap = {
+    'match': match.toJson(),
+    'userUID': authService.value.currentUser?.uid,
+  };
+
+  await flutterLocalNotificationsPlugin.show(
+    withBetNow ? 1 : 2,
+    withBetNow ? 'Live Event - Bet Now!' : 'Live Event Nearby',
+    '${match.homeTeam} vs ${match.awayTeam}\nDistance: '
+        '${distanceInKm.toStringAsFixed(2)} km',
+    details,
+    payload: jsonEncode(payloadMap),
+  );
+}

Rationale: Cached AndroidNotificationDetails as a micro-optimisation

• checkProximityAndNotify() iterates over every match and invokes the notification helper once per item.
• In the original code each call allocated a fresh AndroidNotificationDetails and wrapped it in a new NotificationDetails; those objects are large and must be marshalled across the platform channel.
• Replacing the per-call construction with class-level static const singletons means a single allocation per notification type at app start-up, then mere reuse inside the loop.

This confined, statement-level change that removes redundant object creation—without altering design or architecture—fits the formal definition of a micro-optimisation.

Screenshots Before Micro-optimisations:

Screenshots After Micro-optimisations:

What the numbers mean

• With per-call object creation removed, checkProximityAndNotify itself runs ~3× faster.
• Allocation time nearly halves, showing lower GC/heap pressure.

-return ListView.builder(
-  itemCount: liveMatches.length,
-  itemBuilder: (context, index) {
-    final match = liveMatches[index];
-    return MatchCardFactory.createMatchCard(match);
-  },
-);
+return ListView.builder(
+  key: const PageStorageKey('liveList'),  // keeps scroll offset
+  itemCount : liveMatches.length,
+  itemExtent : 160,   // fixed card height (adjust to real value)
+  cacheExtent: 800,   // pre-fetch ≈ 5 cards beyond viewport
+  itemBuilder: (ctx, i) =>
+      MatchCardFactory.createMatchCard(liveMatches[i]),
+);

Why this counts as a micro-optimisation

• Change is local to one widget-builder call; no new classes or structural refactor.
• Overall algorithmic complexity is unchanged; only hints are provided to the framework.
• itemExtent avoids per-item height measurement during scroll, and cacheExtent instructs the engine to build a handful of off-screen items in advance.
• Net effect: less layout work and smoother scrolling with zero impact on app logic—precisely the intent of a micro-level performance tweak.

Screenshots Before Micro-optimisations:

Screenshots After Micro-Optimisations:

Screenshots Before Micro-optimisations:

Screenshots After Micro-optimisations:

Results:

• Real-Time Betting prompt Trigger

  • Uses geofence events and live-game status to display a lightweight “Quick Bet” overlay as soon as a user enters or approaches a stadium during a match.

• Context-Aware notifications about ongoing or upcoming sports events

  • Monitors the synced sports calendar and GPS proximity; sends push alerts for upcoming or ongoing events when the user is within 500 m of a venue.

• Smart Bet Recommendations identifying repeated bets on the same team and generate personalized bet recommendations

  • Counts a user’s repeated bets per team and surfaces a “Recommended for you” card before that team’s next fixture, based solely on their bet history.

• User authentication

  • Secure email/password signup and login with token-based session management, persisting credentials in encrypted local storage.

• External Sports Calendar integration

  • Fetches and merges varsity schedules from third-party APIs into the in-app calendar on a daily sync, keeping all game times up to date.

• Bet selection & Bet Slip Confirmation

  • Tapping a match opens a slip where users pick odds and wager details; a single “Confirm” tap stores the bet locally and queues it for sync when online.

• Bookmark support for favorite matches.

• Allows users to “star” matches in the calendar; starred items can be filtered to locate favorite matches faster.

• User bet History

  • Displays a list of every wager (team, sport, date).

• Implemented In-App Merchandise Marketplace:

  • Displays a native catalog of official university gear and items.
  • Displays product name, price, image, and category for each item in a scrollable list.
  • Retrieves product listings from the backend API and renders them in-app.

• Implemented Product Detail View:

  • Displays product information including images, price, description, and view count. Leverages view count visibility to reinforce purchase intent.
  • Tracks each user's product views locally enabling personalized recommendations and improved product relevance.

• Shopping cart:

  • Allows users to mark products they intend to buy, storing those selections locally on the device.

The Team Popularity Dashboard presents a consolidated overview of student betting behavior by ranking university teams according to both total stakes and bet frequency. It features two side-by-side tables: the first orders teams by cumulative wagered amounts and shows the corresponding number of bets, while the second ranks teams by the total count of individual bets and displays the aggregate stake for each. This dual-perspective analysis highlights which university brands command the greatest engagement in the marketplace and informs strategic decisions about the selection and promotion of branded merchandise. The dashboard is accessible at the /analytics/dashboard/team-popularity/ endpoint.

The Product Views Dashboard provides two clear, side-by-side bar charts that surface exactly which items and categories students interact with most in the marketplace—ranking the top 10 products by individual view count and aggregating views by category (e.g. Ropa, Hogar, Juguetes). These insights empower our partnerships team to demonstrate real engagement metrics to third-party vendors and sponsors, enabling more targeted co-promotions and revenue-share agreements. You can access it at the /analytics/product-views/ endpoint.

The Incomplete Actions Dashboard highlights exactly which flows users begin but don’t finish—showing, for example, counts of incomplete_bet and incomplete_registration over the last day. By surfacing these abandonment metrics in a simple bar chart, the product team can pinpoint friction points (e.g. a confusing bet slip UI or a cumbersome signup form) and prioritize targeted UX fixes. Reducing these drop-offs boosts overall engagement, completed bets, and user acquisition—making the app more valuable for both students and our institutional partners. You can view it at the /analytics/incomplete-actions/ endpoint.

• Product View Synchronization:
  Product view events are captured locally when the user is offline and synchronized with the backend as soon as connectivity is restored. This synchronization occurs automatically upon detecting network reconnection.
• Product Data Caching:
  The app checks connectivity status before making network requests. If offline, it fetches product data directly from local storage instead of making HTTP requests. Product data fetched from the backend is cached locally using SQLite. Cached data is displayed when offline in the Market Place View, ensuring continuous user experience and reducing backend requests upon reconnection
• Prevent Failed Checkouts in Cart Screen: - We use an offline-first, connectivity-aware flow: all cart actions (add/remove/clear) write immediately to SQLite, and the “BUY NOW” button is disabled when offline—showing a friendly snackbar instead of attempting checkout—so we prevent failed network calls, avoid data loss or duplicate orders, and keep the UI predictable even on flaky connections.

• Product Views Local Storage:
  Product views are initially stored in an SQLite database on the device. A synced flag is maintained in each record to track synchronization status with the backend. Data remains persistent until synchronization is successfully completed.
• Persistent Storage with SQLite:
  Product data is persistently stored using SQLite via the sqflite package. This ensures products are accessible offline and improves app resilience.

• Asynchronous Task Handling for product views:
  Long-running tasks, such as syncing product views and database operations, are managed asynchronously to ensure the UI remains responsive. Operations leverage Flutter’s built-in async/await mechanism to handle tasks without blocking the main thread.

• Asynchronous operations for products Handled using Futures with async/await for network requests (fetchProducts()), database operations (insertProduct()), and caching mechanisms (in-memory caching in ProductRepository). Background JSON parsing is offloaded to isolates using compute() to maintain UI responsiveness during heavy data processing tasks. Error handling (try-catch-finally) ensures robustness, proper fallback to local storage on connectivity failures, and detailed API metrics logging.

• Asynchronous I/O for Cart Items: Asynchronous I/O: all database reads/writes (_loadCartItems(), addToCart(), removeFromCart(), clearCart()) and HTTP checkout calls (create()) use async/await, keeping the main thread free for a responsive UI.

• In-memory Cache for Product Data:
  Implements a time-based caching mechanism with a 10-minute expiration to quickly retrieve product data without unnecessary network requests. The cache is invalidated after the defined period to maintain data freshness.

• Image caching strategy for Products : Uses cached_network_image to locally cache product images in the ProductDetailPage, enhancing performance by avoiding redundant network requests and improving offline experience.

Ethics video

• David:

  • Implement BQ question "What are the most popular university teams among students based on their betting activity "
  • Implemented Cart View for marketplace
  • Local Storage for Cart items
  • Modified Product Detail to add products to the Cart
  • EC Strategy for items of Cart View
  • Uses asynchronous operations for CartViewModel

• Sebastián:

  • Implemented BQ "Which features do users attempt to access but abandon before completing an action, and what might be causing this behavior?"
  • Implemented Marketplace view.
  • Implemented caching and Local Storage Strategies for Market Place
  • EC Strategy for Market Place
  • Uses asynchronous operations for MarketPlaceViewModel.

• Federico:

  • Implemented Product Detail for market place
  • Implemented local Storage and Caching Images for the ProductDetailView
  • Implemented BQ "Which marketplace brands or product categories receive the highest number of product views"
  • Use asynchronous operations for ProductDetailViewModel
  • EC for views of ProductDetail