This page gathers all deliverables expected for Sprint 4.

As in Sprint 3, the numbering of the sections in this document follows the numbering of the sections in the deliverable. However, the order of the sections differs.

• Sprint 4: Deliverable
  • 1, 4 & 7.a. Delivered Features
    • 1 & 7.a. Features from Sprint 2
    • 1 & 7.a. Features from Sprint 3
      • Post-Feedback Changes
    • 4. New Features: Sprint 4
  • 2. Value Proposition
  • 3. Micro-optimization Strategies
    • Swift App Micro-optimizations
    • Flutter App Micro-optimizations
  • 5. View Catalogue
  • 6 & 7b. Business Questions
  • 4.a & 7.e. Multi-threading Strategy for Sprint 4
    • Flutter
    • Swift
  • 4.b & 7.d. Local Storage Strategy for Sprint 4
    • Flutter
    • Swift
  • 4.c. & 7.f. Caching Strategy for Sprint 4
    • Flutter
    • Swift
  • 4.d. & 7.c. Eventual Connectivity Strategies
  • Ethics Video

This section lists all the features in the app, detailing which were implemented in Sprint 2, Sprint 3, and Sprint 4.

Subsections are included to distinguish between features from different sprints.

The following updates were made to the app based on feedback received during Sprint 3:

• All red font colors, present in many of the eventual connectivity messages, were changed to black for better readability.
• The login flow was changed to favor users maintaining their session after closing the app, instead of having to choose an account every time they open it.

The following new features were implemented in Sprint 4. They are explained in the following table.

Notice that each feature was implemented for both Swift and Flutter, which means that the number of features equals double the number of rows in the table.

UniTrade is a marketplace app made for university students. It solves their problems of finding and exchanging academic materials quickly and easily. The app uses features like AI-powered product categories and personalized recommendations to save users time and effort. For example, the "For You" section, added in Sprint 2, shows products based on each student’s preferences, making it easier to find what they need. Features from Sprint 4, like saving "Favorites" and quick "Buy Now" buttons, make shopping faster and simpler. The app also works well on both Android and iOS, thanks to its development in Swift and Flutter.

UniTrade makes money through a smart mix of charging small fees on transactions (5%-10%), offering premium features, and showing ads that match student interests. Business questions from Sprint 3 and Sprint 4, such as analyzing where users shop (Favorites or Home View) and studying purchase habits by semester, help improve these strategies. For example, knowing which semester students are most likely to buy helps target ads better. By collecting and analyzing data from features like the "Favorites" list, the app gets smarter over time, giving students a better experience while also helping UniTrade grow as a business.

• Reuse Created Categories Instead of Recreating Them

The first micro-optimization identified in the Swift application is related to the creation of unnecessary objects. Although this does not occur inside a loop, the identified method is frequently called, resulting in redundant object creation. The culprit in this case is the createCategories() method:

private func createCategories() -> [Category] {
    let forYouCount = viewModel.forYouCategories.count
    let forYouCategory = Category(name: "For You", itemCount: forYouCount, systemImage: "star.circle")
    
    return [
        forYouCategory,
        Category(name: "Study", itemCount: 43, systemImage: "book"),
        Category(name: "Tech", itemCount: 57, systemImage: "desktopcomputer"),
        Category(name: "Creative", itemCount: 96, systemImage: "paintbrush"),
        Category(name: "Lab", itemCount: 30, systemImage: "testtube.2"),
        Category(name: "Personal", itemCount: 78, systemImage: "backpack"),
        Category(name: "Others", itemCount: 120, systemImage: "sportscourt")
    ]
}

This method is responsible for generating a list of categories displayed in the ExplorerView. Each time it is called, it creates a new array of Category objects, even though the data often remains static during the lifecycle of the view. To optimize this, the createCategories() method was replaced by a computed property that calculates the categories only when needed and avoids recreating them unnecessarily.

The optimized computed property looks like this:

private var categories: [Category] {
    let forYouCount = viewModel.forYouCategories.count
    let forYouCategory = Category(name: "For You", itemCount: forYouCount, systemImage: "star.circle")
    
    return [
        forYouCategory,
        Category(name: "Study", itemCount: 43, systemImage: "book"),
        Category(name: "Tech", itemCount: 57, systemImage: "desktopcomputer"),
        Category(name: "Creative", itemCount: 96, systemImage: "paintbrush"),
        Category(name: "Lab", itemCount: 30, systemImage: "testtube.2"),
        Category(name: "Personal", itemCount: 78, systemImage: "backpack"),
        Category(name: "Others", itemCount: 120, systemImage: "sportscourt")
    ]
}

This computed property avoids recreating the object unnecessarily by ensuring that the categories array is only calculated when accessed. The view then references this property instead of repeatedly invoking a method.

The final optimized implementation in the ExplorerView looks like this:

CategoryScroll(
    selectedCategory: $viewModel.selectedCategory,
    categories: categories
)

Instead of calling createCategories() multiple times, the view now accesses the categories computed property.

Before this micro-optimization, every interaction that required accessing categories, such as scrolling or refreshing the view, triggered the creation of a new array of Category objects. By implementing the computed property, this overhead was removed, leading to improved CPU performance.

The following graph shows the CPU usage before the micro-optimization, where the createCategories() method was called multiple times during user interactions. Tha graph shown corresponds to the user entering the home screen, where the categories are, and then switching between that screen and another three times:

The following graph shows the memory usage after implementing the computed property. As before, the test consisted of the user entering the home screen and switching between that screen and another three times:

Naturally, the graphs have similar behaviors as they represent the same user interactions. The graph that corresponds to the main thread CPU usage is also included, as all of the operations happen on the main thread. It is important to notice that the difference between the two graphs is the scale in which the peaks happen. In the first graph, that corresponds to the operation without the micro-optimization, the peaks are higher, with the first one piking up to 192% CPU usage, while in the second graph, that corresponds to the operation with the micro-optimization, the peaks are lower, with the first one piking up to 152% CPU usage and the second peak being proportionally lower (and, therefore, lower than its corresponding peak on the first graph). This shows that the micro-optimization helped streamline the performance of the ExplorerView.

• Avoid Frequent Date Formatter Creation in Method

The second micro optimization identified in the Swift application is related to the creation of unnecessary objects. In this case, the unnecessary object creation does not happen inside a loop but rather inside a method that is called multiple times. The method that was identified as the culprit is the following:

private func updateFirebase(for product: Product, isPurchase: Bool) {
    guard let userId = Auth.auth().currentUser?.uid else {
        showAlert(message: "User is not authenticated.")
        return
    }
    
    let documentRef = firestore.collection("products").document(product.id)
    let dateFormatter = DateFormatter()
    dateFormatter.dateFormat = "yyyy-MM-dd"
    let currentDate = dateFormatter.string(from: Date())
    
    firestore.collection("users").document(userId).getDocument { [weak self] (document, error) in
        var buyerSemester: String? = nil
        
        if let document = document, document.exists {
            let data = document.data()
            buyerSemester = data?["semester"] as? String
        } else if let error = error {
            self?.showAlert(message: "Failed to retrieve user data: \(error.localizedDescription)")
        } else {
            self?.showAlert(message: "User data not found.")
        }
        
        documentRef.updateData([
            "in_stock": false,
            "buyer_id": userId,
            "buyer_semester": buyerSemester ?? NSNull(),
            "purchase_date": currentDate,
            "purchase_screen": purchaseScreen
        ]) { error in
            if let error = error {
                self?.showAlert(message: "Failed to update product: \(error.localizedDescription)")
            } else {
                let successMessage = isPurchase
                ? "Product purchased successfully!"
                : "Product rented successfully!"
                self?.showAlert(message: successMessage)
            }
        }
    }
}

The method above has the responsibility of updating a product in the Firebase Firestore database. The method is called every time a user buys or rents a product. The problem with this method is that it creates a new DateFormatter object every time it is called. This is unnecessary because the DateFormatter object is not dependent on any other object in the method. A solution to this problem is to create the DateFormatter object as a class variable and use it in the method. However, an even better solution And the one that was implemented was to create a lazy property to avoid repeated creation.

The lazy property that was created is shown below:

private lazy var dateFormatter: DateFormatter = {
    let formatter = DateFormatter()
    formatter.dateFormat = "yyyy-MM-dd"
    return formatter
}()

The code snippet below shows the final optimized version of the method, where the object is not created each time the method is called but rather is created only once when the class is instantiated.

private func updateFirebase(for product: Product, isPurchase: Bool) {
    guard let userId = Auth.auth().currentUser?.uid else {
        showAlert(message: "User is not authenticated.")
        return
    }
    
    let documentRef = firestore.collection("products").document(product.id)
    let currentDate = dateFormatter.string(from: Date())
    
    firestore.collection("users").document(userId).getDocument { [weak self] (document, error) in
        var buyerSemester: String? = nil
        
        if let document = document, document.exists {
            let data = document.data()
            buyerSemester = data?["semester"] as? String
        } else if let error = error {
            self?.showAlert(message: "Failed to retrieve user data: \(error.localizedDescription)")
        } else {
            self?.showAlert(message: "User data not found.")
        }
        
        documentRef.updateData([
            "in_stock": false,
            "buyer_id": userId,
            "buyer_semester": buyerSemester ?? NSNull(),
            "purchase_date": currentDate,
            "purchase_screen": "home"
        ]) { error in
            if let error = error {
                self?.showAlert(message: "Failed to update product: \(error.localizedDescription)")
            } else {
                let successMessage = isPurchase
                ? "Product purchased successfully!"
                : "Product rented successfully!"
                self?.showAlert(message: successMessage)
            }
        }
    }
}

The micro-optimization surprisingly was able to substantially optimize the memory usage of the application when buying successive products. This can be attributed to the fact that the object is now created once instead of being created for each product upload.

The following graph shows the memory usage when three different products are bought before the micro-optimization was implemented:

The following graph shows the memory usage when three different products are bought after the micro-optimization was implemented:

For the first micro-optimization, we decided to take a look into the package that the application is currently using for checking whether the device has connection or not (connection meaning either wifi or mobile data). Previously, our application was using connectivity_plus package in order to constantly monitor internet connection changes. However, we noticed during our development process that this service sometimes taking some time before actually notifying changes in the connection status of the devices. We did some tests inside the app to see how the package was performing and when toggling on/off the mobile data for the phone we got the following results:

This means that when the mobile phone experiences some sort of change in the connection status, the app takes about 10 seconds before it registers the change. This value should be taken with a grain of salt, because the process corresponds to an operation done by another package it did not appear in the CPU profiler as a process, because of this we had to manually record the start/end time of the process using Flutter logging tools which means that the raw duration of getting the internet status is lower than 10 seconds. Either way, we opted for a different connectivity package called internet_connection_checker_plus which is faster and lighter flutter package built on top of our previously used connectivity_plus package. When executing the same tests in the flutter app but with the new package we got the following results:

Same as before, these values are higher than what the raw connection status checking time actually is but it does show a mayor improvement in performance. Furthermore, when using the app we found that new package consistently exhibited faster response times when detecting changes in internet connectivity. As before, the recorded values include overhead, but the relative improvement in performance is clear.

We also did a number of micro-optimizations in different parts of the application; a list of this micro-optimizations is presented below:

• Avoid Creating Unnecessary Objects

In components where an object was instantiated multiple times, we instead created a single instance as a member variable of the corresponding class to repeat object creation. The following snippet illustrates the code before the micro-optimization

  MyOrdersViewmodel() {
    fetchProducts();
  }

  Future<void> fetchProducts() async {
    isLoading = true;
    isOfflineData = false;
    notifyListeners();
    try {
      var connectivity = ConnectivityService();
      hasConnection = await connectivity.checkConnectivity();

      if (hasConnection) {
        await _fetchProductsFromFirebase();
      } else {
        isOfflineData = true;
        await fetchProductsFromHive();
      }
    } catch (e) {
      print("Error fetching products: $e");
    } finally {
      isLoading = false;
      notifyListeners();
    }
  }

The problem in this case is that the object is instantiated inside the fetchProducts method every time it is called. Instead, what we can do is just to create a single instance of the ConnectivityService object and use it inside the method. Here is the code snippet after micro-optimization:

  final ConnectivityService _connectivityService = ConnectivityService();
  MyOrdersViewmodel() {
    fetchProducts();
  }

  Future<void> fetchProducts() async {
    isLoading = true;
    isOfflineData = false;
    notifyListeners();
    try {
      hasConnection = await _connectivityService.checkConnectivity();

      if (hasConnection) {
        await _fetchProductsFromFirebase();
      } else {
        isOfflineData = true;
        await fetchProductsFromHive();
      }
    } catch (e) {
      print("Error fetching products: $e");
    } finally {
      isLoading = false;
      notifyListeners();
    }
  }

• Use Indexed Loops Instead of for-each Loops

In the application we found some instances in which we iterated over an object, an example of this is when we are saving products in local storage in which case we use a for-each loop to iterate over the array and save each product, the code snippet for this is shown below:

final box = await Hive.openBox<ProductModel>('myOrders');
await box.clear();
for (var product in products) {
  box.put(product.id, product);
}

Instead, we changed this loop to a indexed loop which is the recommended implementation for better performance in memory-intensive scenarios. The code snippet for the new implementation goes as follows:

for (int i = 0; i < products.length; i++) {
  final product = products[i];
  box.put(product.id, product);
}

• Use Transparent Backgrounds

Although we did not find any overdraw In the application as every screen was in X1 Overdraw (Blue color) we still discovered some instances in which containers and other widgets were painting the background with the same color as the surface, we decided to change the background color the containers to transparent in order to avoid instances that may cause overdrawing. The change is as follows:

color: Theme.of(context).colorScheme.surface, changes to color: Colors.transparent,

-- Use Lifecycle Methods Properly to Avoid Memory Leaks

In files where functionalities such as local storage with Hive are used and Boxes are opened, it is important to take care of the life cycle of the objects that help use handle local storage. Because of this, it is important to add a way to dispose of these objects in the appropriate way. The dispose() method was overridden in the classes were it is necessary. The code snippet added is shown below:

@override
void dispose() {
  Hive.close();
  super.dispose();
}

Now, since all of the changes made are such small changes it was not worth comparing what the profiler shows for each of the changes. Instead, we navigate through the application before the changes and compare to the same navigation process after the micro-optimizations are made. First off, here we can see some of the data the profiler shows before the micro-optimizations:

• App performance and GUI rendering

• Build time when changing views

• Memory allocation in the application

• Memory chart when navigating the app Home view

Now when comparing to after we made the micro-optimizations we see the following results:

• App performance and GUI rendering

• Time for build when changing views

• Memory allocation in the application

• Memory chart when navigating the app Home view

All in all, we see slight improvements in UI build time for some of the slow frames of the application which go down from 28ms to just a little more than the 16ms rendering threshold. We also see improvements in the total size of the memory being used by the app going down by 8MB as well as reducing instances of certain classes most notably ProductModel. In terms of the memory chart there is also a slight improvement as we see a more stable line for the RSS which indicates the total memory consumed by the app.

The following table lists all the views in the app. The features available in each view have been detailed in the Delivered Features section above.

Notice that, obviously, each view is implemented in both the Swift and Flutter apps.

View implemented in Sprint 4 are flagged.

The following table contains the business questions that were implemented for this sprint, with their respective type, rationale, and the view in which they were implemented.

• Some questions are a subset of those presented in the Sprint 1 Deliverable.
• They differ from the Business Questions implemented for the Sprint 2 Deliverable.
• They are also different from the Business Questions implemented for the Sprint 3 Deliverable.

In the Flutter app, we implemented a new class similar to the previous multithreading solution. We created the class favorites_service.dart that is designed as a singleton to petition the favorite product data using a secondary thread, this helps the performance by giving this task to a separate isolate. It can only have one instance of the class due to the private constructor, providing a centralized way to load and access product data across the app. It starts with the function loadFavoritesInBackground that spawns a new isolate to fetch the data from Firebase, when the user goes to the favorites screen, it checks the thread if the products are loaded with the line FavoritesService.instance.favoriteProducts. This helps the app performance because the process of retrieving products is a costly one. Due to the storage of the userID this fetch can be executed at the start of the app.

In the Swift app, we implemented a similar multithreading strategy to enhance performance as the one for the last Sprint. A new method, fetchFavoritesInBackground, was added to the ExplorerViewModel to handle data fetching using a secondary thread. This method leverages DispatchQueue.global with a quality-of-service level set to .userInitiated, ensuring priority for tasks critical to user experience. Initially, it loads the "IDs" for all favorites of an user in the background, updating the isFavorite of each of these producta upon success. Simultaneously, products are fetched asynchronously from Firestore with the method loadProductsFromFirestore. This approach centralizes data loading while maintaining UI responsiveness, marking isDataLoaded as true once both processes (products and favorites ids) completes.

For the Flutter application, we will use Hive as a NoSQL database to store products that will be shown when the user has no internet connection. This implementation will be done mainly for the MyOrders view in which the user can see all of the products he has rented/bought over time. Hive uses a concept called boxes which is basically a data storage unite which could be equivalent to a table in a traditional database. For this strategy we have created a new box in which we save and extract the products by products id. It uses key-value pair storage and also allows for persistent storage and uses thread-safe mechanisms, making them suitable for background operations. This implementation is useful as it allows us to show the user information even when no connection is available, and maintain a smooth flow throughout the app.

For the Swift application, the MyOrdersView implements a local storage strategy using UserDefaults to ensure a seamless user experience, even in offline scenarios. When the user has an internet connection, the app retrieves the latest order data from Firestore and saves it in UserDefaults for future access. If the user is offline, the app automatically retrieves and displays the orders stored in UserDefaults, ensuring data availability regardless of connectivity.

For the flutter application we used a library for storage and caching of images, we used especially cached_network_image, so the images from the network are stored in a local directory for easy access and rendering. This change helps the app to load and run smoothly, because it doesn't need to fetch multiple times the same image from the network every time we load the same screen, also, it helps different screens that access the same image, for example after loading the home page if the user enters the detail view of a product the image is already loaded in the cache so it doesn't need to make another request for the image. Inside the app we only need to change all the Image.network to CachedNetworkImage, we can also personalize the placeholder while it loads and an error widget if the request failed.

For the Swift application, we implemented a caching strategy to improve performance and reduce network usage by caching images of products. We utilized the Kingfisher library, which provides an efficient way to download and cache images from the network. Kingfisher stores images locally in a cache directory, ensuring that the app doesn't repeatedly fetch the same image from the network when navigating across screens. This significantly enhances the app's responsiveness. For example, if a product's image is loaded on the home screen, it will already be available in the cache when the user navigates to the product detail view, eliminating the need for additional network requests. In our implementation, we replaced direct calls to UIImageView with Kingfisher's kf.setImage method, which handles downloading, caching, and displaying the image seamlessly. Additionally, placeholders can be customized to show while the image loads, and fallback images are displayed in case of a failed request. This approach aligns with the goals of Flutter's caching strategy, ensuring a smooth user experience and optimized performance.

Every single view in the application was implemented with an eventual connectivity strategy. For all existing views, eventual connectivity strategies have been described in previous deliverables. The following table summarizes the eventual connectivity strategy for each new view implemented in Sprint 4.

Video.