• User authentication (sign in and sign up) requesting Uniandes email and additional students data.
• Add a product for sale with its respective information using the phone's camera sensor and accessing the photo gallery.
• List of available products with their respective details (name, description, images and seller).
• Personalized filter recommendations by category based on user searches and clicks.
• Efficient product search based on product name and description.
• Personalized notifications when a user's favorite product drops in price.

• Product recommendations during key periods of university.
• Profile page with routes to favorite products and products published by the user with the option to edit or delete that product.
• List of the user's favorite products.
• Chat page for communication between seller and buyer of a product.
• Personalized notifications to inform the user about updates on active listings.

The second Type 4 business question was changed since the one defined in Sprint 1 was not convenient since we have only one category per product.

Considering the crucial role of local storage in managing data on the device, it ensures that, in the event of a loss of connectivity, the information necessary for the operation of the app is available and does not affect the user experience. This ensures the continuity of the functionality of the applications even under offline conditions. Storage strategies were also selected that were aligned with the types of data to be saved, which was crucial in choosing the most appropriate structure. This choice not only facilitated CRUD processes, but also allowed the stored information to be easily accessible and used within the application, maximizing efficiency and performance. The following are the local storage strategies implemented:

In the Flutter implementation, SQLite (through sqflite) and Hive are used as the main local storage solutions. For structured data like user information, products, and favorites, SQLite provides efficient query management and storage, allowing the app to handle these data quickly and reliably. On the other hand, Hive is used for lighter, more easily accessible data like favorite products or featured categories, optimizing read and write speed. For sensitive data, such as user credentials, Flutter Secure Storage is used to ensure that this information is kept secure at all times.

In the Kotlin implementation, Room is used as the main persistence solution for structured data such as products, user information, and favorites. This library abstracts the complexity of SQLite and provides compile-time verification of SQL queries. Additionally, EncryptedSharedPreferences is used to securely store sensitive user data such as credentials. The local Room database enables offline access to product data, efficient querying, and synchronization with Firestore when connectivity is available, ensuring a smooth and reliable user experience.

In Flutter, concurrency refers to the ability to perform multiple operations asynchronously without blocking the main UI thread. Although Flutter is single-threaded by default, it supports asynchronous programming using tools such as:

• Future: Handles single asynchronous operations.
• Stream: Handles continuous sequences of asynchronous events.

These strategies ensure that time-consuming tasks like network calls, database operations or file access do not freeze or slow down the user interface, resulting in a smooth and responsive app experience.

The Future strategy with async/await allows you to execute asynchronous operations sequentially and in a non-blocking manner. It was implemented for tasks such as web service calls, database access, read/write operations, etc.

Features implemented with Multi-threading/concurrency Strategy

• User registration

In the user registration feature, async/await is used to handle the creation of a new user in Firebase Authentication. This ensures that the app waits for a response from Firebase before continuing execution.

File: auth_repository_impl.dart

  Future<String?> signUpWithEmailAndPassword(
      String email,
      String password,
      String name,
      String career,
      String semester,
      ) async {
    final user = await _authDataSource.signUpWithEmail(email, password);
    if (user == null) {
      return 'Registration failed.';
    }

• Add product

When publishing a product, several asynchronous operations are performed, such as uploading images and saving data to Firestore. Using async/await allows these operations to be performed sequentially and in a manageable manner.

File: add_product_viewmodel.dart

Future<void> addProduct({
    required List<XFile?> images,
    required String name,
    required String description,
    required String category,
    required double price,
  }) async {
    isLoading = true;
    errorMessage = null;
    notifyListeners();

    try {
      final product = Product(
        id: '',
        name: name,
        description: description,
        category: category,
        price: price,
        imageUrls: [],
        sellerName: '',
        favoritedBy: [],
        userId: '',
      );

      await _productRepository.addProduct(images: images, product: product);
    } catch (e) {
      errorMessage = e.toString();
    }

    isLoading = false;
    notifyListeners();
  }

Benefits

• Readability: The code resembles sequential execution, making it easier to understand and maintain.
• Error handling: Allows the use of try/catch blocks to effectively capture and handle exceptions.
• Efficiency: Avoids blocking the main thread, keeping the application responsive during operations that may take time.

It represents a sequence of asynchronous events received over time. That is, data flows continuously and is listened to as it arrives, such as changes in network connectivity, without blocking application execution.

The ConnectivityService class uses a Stream<bool> called isOnline$ that emits the application's connectivity status.

File: connectivity_service.dart

Stream<bool> get isOnline$ async* {
  final result = await _connectivity.checkConnectivity();
  yield result != ConnectivityResult.none;

  yield* _connectivity.onConnectivityChanged.map(
    (result) => result != ConnectivityResult.none,
  ).distinct();
}

Code explanation

This strategy is especially useful for allowing the application to dynamically adapt to network availability, such as displaying messages or disabling certain features when there is no Internet access.

Benefits

• Reactivity: Allows the application to react in real time to changes in network connectivity.
• Efficiency: Avoids unnecessary operations by issuing only when there is a change in the connectivity state.
• Simplicity: Using Stream and async/await provides a clear and concise way to handle asynchronous operations and data flows.

Isolates in Flutter allow performing expensive computations or I/O operations in a separate thread, preventing the main UI thread from being blocked.

In the image caching system, the app needs to delete outdated images from the local cache when a product is updated. If there are many images to remove, doing so on the main thread can cause UI jank.

To avoid this, we apply the Isolate strategy using the compute() function, which offloads this task to a secondary isolate (thread).

File: edit_product_viewmodel.dart

Future<void> clearEditedImagesFromCache(List<String> oldUrls, List<String> updatedUrls) async {
  await compute(_clearImagesWorker, {
    'oldUrls': oldUrls,
    'updatedUrls': updatedUrls,
  });
}

void _clearImagesWorker(Map<String, dynamic> args) async {
  final oldUrls = List<String>.from(args['oldUrls']);
  final updatedUrls = List<String>.from(args['updatedUrls']);
  final manager = CustomCacheManager.instance;

  for (final url in oldUrls) {
    if (!updatedUrls.contains(url)) {
      await manager.removeFile(url);
    }
  }
}

Benefits

• Performance: Keeps UI responsive by running heavy logic off the main thread.
• Efficiency: Allows concurrent cleanup of cached data.
• Scalability: Suitable for larger apps with heavy I/O or processing.

In our kotlin app, coroutines are used as the primary multi-threading strategy to handle asynchronous operations such as network requests and database interactions efficiently. By leveraging suspend functions and coroutine scopes like viewModelScope, the app ensures that long-running task, such as fetching products from Firestore, are exectuted off the main thread, preventing UI freezes and improving responsiveness. The use of withContext(Dispatchers.IO) explicitly delegates these operations to the I/O thread pool, which is optimized for blocking tasks like reading from or writing to a database.

This coroutine-based approach simplifies concurrency management, ensures lifecycle awareness, and maintains a smooth user experience. The ProductRepository class makes extensive use of suspend functions and await() calls from kotlinx-coroutines-play-services to interact with Firebase Firestore and Firebase Auth. These operations are executed off the main thread, leveraging Dispatchers.IO under the hood.

This multi-threading strategy was used for the next features:

This strategy uses Kotlin coroutines within a HomeScreenViewModel to asynchronously retrieve product data and perform search filtering. All network and data fetching operations are launched using viewModelScope to ensure proper lifecycle handling. Dispachers.IO is implicitly used in suspend functions from the ProductRepository, keeping the main thread free for UI interactions. A debounce strategy is applied to the search query using StateFlow, reducing unnecessary calls while typing.

HomeScreenViewModel

DataLayerFacade

ProductRepository

Following the same logic explained for "Product Retrieval and Searching Filtering Using Coroutines" the list of product changes based on the filter aplied by the user. So the HomeScreenViewModel uses coroutines to asynchronously retrieve the product data. Dispachers.IO is implicitly used in suspend functions from the ProductRepository, keeping the main thread free for UI interactions.

Implemented by: Sara Benavides Mora

HomeScreenViewModel

ProductRepository

This strategy is implemented in FavoritesScreenModel using coroutines and StateFlow. It collects search input changes and filters favorited products accordingly. The debounce(300) operator is applied to delay execution while the user is typing, preventing excessive backend calls. This approach ensures a smooth user experience and optimal resource usage.

Implemented by: Sara Benavides Mora

FavoritesScreenViewModel

It is a strategy that loads images from the Internet and automatically stores them in the device's memory for reuse without having to download them again.

To enhance performance and reduce data usage, SeneMarket implements a robust image caching strategy using the cached_network_image package. This approach ensures faster load times and an improved user experience by storing images locally after their first download.

Libraries used

• cached_network_image: Loads and displays images from the network with automatic caching.
• flutter_cache_manager: Provides advanced file caching management, used internally by cached_network_image and extended for custom logic.

Modified and added files for Caching Strategy

These changes implement a consistent and efficient caching strategy using cached_network_image and flutter_cache_manager.

Custom Cache Manager Configuration

Create a custom cache manager with the following configuration to control caching behavior more precisely:

This configuration ensures that cached images older than 30 days or exceeding 100 items are automatically removed.​

Handling image updates

When product images are updated or deleted (for example, during product edits), outdated images must be cleared from the cache to avoid displaying stale data.

Implement a method clearEditedImagesFromCache to remove specific images from the cache when they are no longer valid. Call this method after updating images to ensure that the cache reflects the latest content.​

Benefits

• Faster load times: Cached images are loaded locally.
• Lower data usage: Avoids redundant downloads.
• Better UX: Users experience smooth scrolling and reduced loading spinners.

In our Kotlin application, an LRU (Least Recently Used) caching strategy is employed for loading product images efficiently. This approach ensures that the most frequently accessed images are kept in memory, while older, less-used images are evicted when the cache reaches its capacity. By leveraging LRU caching, implemented by the library of Coil, the app minimizes redundant network requests and accelerates image loading times, especially when users scroll throug product lists or revisit previosly viewed items. This improves overall performance and provides a smoother, more responsive user experience, particularly in resource-constrained environments.

Based on our architecture, which separates responsibilities across the View, ViewModel, DataLayerFacade, and Repository layers, the implementation of an LRU caching strategy is applied specifically at the View layer, where images are loaded for product display. The image caching is handled using the Coil library, which internally leverages an LRU cache mechanism to store and reuse image bitmaps efficiently. This ensures that frequently accessed product images, such as those shown on the Home screen, Favorites, or as search results, are quickly loaded from memory instead of being re-downloaded from the network, resulting in faster performance and reduced data usage. In the UI, product images are loaded using Coil’s AsyncImage composable. The next example applies for every section of the app where the product image is shown such as HomeScreen, ProductDetailScreen and FavoritesScreen.

Ethics Video S3 G22