Table of contents

1. Eventual connectivity scenarios
2. Implemented features
3. Implemented business questions
4. Connectivity strategy
5. Local Storage Strategy
6. Multi-threading Strategy
7. Caching Strategy
8. Ethical component reflection

Eventual Connectivity scenarios for UniPark

For the UniPark app, we designed connectivity solutions that address the challenges of intermittent and poor network conditions, as users may experience fluctuating connectivity on campus. Our goal was to ensure that the app remains usable even when connectivity is inconsistent, so users can rely on it to find parking spaces in real-time. It's important to note that the app also needs live feedback in order to work, which means that connectivity is a very big deal for us, however, we evaluated the following connectivity scenarios for the app:

Eventual Connectivity Scenarios:

Title/ID	Offline Mode
Event description	User is using the app and connection is lost
System response	When the app detects no network connection, it switches to offline mode. In this state, users can still view previously loaded parking data from the local cache, allowing them to make informed parking choices based on recent availability. However, they won't be able to reserve spots or receive real-time updates until the connection is restored. The app also has some default data preinstalled, which means that the information of the most common parking lots is already downloaded with the app in case there is no connection.
Possible Antipatterns	Blocked application, Non-informative message , Lost content (Blank map, user content)
Caching and retrieving strategy	Network falling back to cache
Storage type	Local > Private > Storage > Cache
Stored data type	Core Data (for essential information like parking spot details, prices, and user preferences), UserDefaults (for lightweight data like most recent parking lot view).

Title/ID	Intermittent Connectivity
Event description	The user moves between buildings, underground areas, or is in locations where the connection is not stable
System response	For situations where network connection is sporadic, the app operates in a "sync-on-availability" mode. Data is queued locally, and the app periodically attempts to sync reservations or status updates with the backend when connectivity resumes. This allows users to initiate actions that the app will complete once a stable connection is detected.
Possible Antipatterns	Blocked application, Non-informative message , Lost content (Blank map, user content), Non-existent result notification
Caching and retrieving strategy	Network falling back to cache
Storage type	Local > Private > Storage > Cache
Stored data type	Core Data, Temporary Queue Data Structure

Title/ID	Low Bandwidth/Slow Network
Event description	Users experience a slow network
System response	The app prioritizes lightweight data requests, loading essential information (e.g., available spots, prices) while deferring non-critical updates like reviews. The interface will notify users with a loading indicator and delayed content messaging.
Possible Antipatterns	Blocked application, Non-informative message , Non-existent result notification
Caching and retrieving strategy	Network falling back to cache
Storage type	Local > Private > Storage > Cache
Stored data type	Core Data, In-Memory Cache

Behavior and User Experience

• Offline Mode Experience: When users open the app with no internet, they see cached parking lot data. A notification alerts them that the data may be outdated, encouraging users to refresh the page when online. Essential actions, like making a reservation, are disabled with a tooltip explaining the need for internet access.

• Intermittent Connectivity Experience: Actions like making a reservation are displayed as "pending" with a small icon to indicate the action will complete once reconnected. If a user closes the app before syncing, the pending actions remain queued and complete when the app is reopened with connectivity.

• Low Bandwidth Experience: The app detects low network speed and adapts by loading essential data first, postponing larger content like images or reviews. Users are informed through a subtle "low connection" banner, indicating that only critical information is loading.

These solutions are designed to ensure a seamless experience, keeping users informed and the app functional even under less-than-ideal network conditions.

List of implemented features

Currently, the application has the following functionalities:

• Log in
• Log out
• Create a user as a driver
• Search locations on the map
• View parking spots near the location
• See parking spot details
• Filter by highest-rated parking spots
• View the user profile
• Make a reservation in a parkinglot
• See the details of a reservation
• See the detials of common parking lots in some universities while offline
• Notification system to alert a user there are no more parking spots available for a specific parking lot

Implemented business questions

BQ from Sprint 2:

1. Type 1: How often do users experience slow load times when searching for available parking spots? This targets performance issues related to the speed of retrieving parking spot data, a crucial aspect of user experience that can indicate server or database lag.
2. Type 2: Which parking spots have a rating higher than 4.5 around a given location?
   This is a Type 2 question as it is useful for users and is answered directly within the app. To answer it, a filtering process must be performed by the analytics engine.
3. Type 3: What percentage of users utilize the app's online reservation system to book parking spots in a day? This information is useful to analyze if the users are using the functionality or if it should be removed.
4. Type 2: In which parking lots around the user's location is it necessary to leave keys? This is a Type 2 question as it is of interest to users and should be answered by querying the analytics engine to identify parking spots that meet the given condition.

BQ from Sprint 3:

1. Type 2: How many people are benefiting from last minute free slots at parking lots during normal business hours? As part of our solution, parking spots that were reversed but the person didn't show up within the first 15 minutes of the established time of the reserve will be free for anyone to grab. With this question, we would like to know how many people use the notification system informing theres a free parking spot in normal business hours from 8AM until 5PM. Is it a feature people are using to make a reservation? Or do they just keep looking around in case they don't find any available slots? Author: Tomas Angel
2. Type 3: What percentage of users utilize the app's online reservation system to book parking spots in a day? This information is useful to analyze if the users are using the functionality or if it should be removed.
3. Type 5: Which parking lots around campus are most frequently booked during peak hours (e.g., 6:30 am to 9:30 am), and how can we optimize pricing or introduce incentives to encourage students to use alternative parking lots during these times?
4. Type 2: Which parking spots have a rating higher than 4.5 around a given location? This is a Type 2 question as it is useful for users and is answered directly within the app. To answer it, a filtering process must be performed by the analytics engine. Author: Ingrith Barbosa

Connectivity Strategy

Our eventual connectivity strategies focus on managing scenarios where the user has intermittent or no internet connection. The goal is to maintain the app’s functionality and user experience without depending on a consistent network.

1. Offline Mode:

   • When the app detects no connection, it switches to offline mode. In this state, users can still access data previously fetched and stored locally (such as available parking spots or last viewed parking lot details). Attempts to make new requests (like reservations) will be queued and retried when the network is restored. This is done through the Grand Central Dispatcher to manage the queue.

2. Retry Queue for Intermittent Connectivity:

   • For actions requiring immediate connectivity, such as submitting reservations, we use a retry queue. When a connection issue is detected, the app saves these actions locally, along with the intended server call. When connectivity is re-established, the app attempts to complete all queued actions in sequence, providing a smooth user experience.

Local Storage Strategy

Our local storage strategies ensure that key information is available even without a network. We use core data and UserDefaults for managing local data:

1. Core Data for Persistent Data:

   • Core Data stores essential data like available parking spots, prices, parking lot details, and user preferences. This way, the app has cached data ready, even if offline. Data is periodically synced in the background to keep it updated. Part of the app has some parkinglots preloaded so users can still view them in case there is no connectivity but they still need to know the information of a parkinlot.

2. UserDefaults for Lightweight Data:

   • Simple settings and most recently viewed parking lots, are stored in UserDefaults. This ensures that user-specific configurations persist without taking up much space.

Multi-threading Strategy

To manage multi-threading effectively, we rely on Grand Central Dispatch(GCD) and Swift’s async/await syntax for asynchronous operations:

1. Grand Central Dispatch (GCD):

   • GCD is used to handle background tasks like data sync with the server or saving data in Core Data. This avoids blocking the main thread and ensures a responsive user interface. For example, data fetches are handled in the background, then displayed on the main thread once complete. The GCD also manages the queue's of requests made while having connectivity and when there is no connectivity.

2. Async/Await for Promises:

   • For network calls or database operations where completion handlers are required, we use Swift’s async/await syntax, which simplifies managing promises and sequential async operations. This allows smooth chaining of operations, such as fetching parking data, caching it, and then displaying it without blocking the main thread.

Caching Strategy

Our caching strategy is implemented to reduce network requests and enhance speed, using a combination of in-memory caching and Core Data caching:

1. In-Memory Caching:

   • Recent or frequently accessed data, like a user’s current parking lot selection, is stored in memory. This allows instant access without querying Core Data or making network calls. We use a simple dictionary cache to store data temporarily.

2. Core Data Caching:

   • Core Data serves as a persistent cache for data fetched from the network, ensuring data is available when offline and reducing redundant API calls. This data is periodically refreshed in the background, ensuring users see near-real-time data while minimizing bandwidth usage.

Ethical video

You can watch our video here

Back to top