Sprint 3‐Auth & Network - G33-Moviles-2026-1/Wiki GitHub Wiki
Caching Strategies:
In this case we implemented a lightweight caching strategy for Auth using local storage to persist the user's session state. While no temporary cache is used for network requests, the application relies on persistent storage to maintain access when connectivity is lost.
Eventual Connectivity Scenarios:
| Title | Cache then Network for User Session (Cookies) |
|---|---|
| Event description | The user opens the application or attempts to navigate the app while the device has no active internet connection, or the backend server is temporarily unreachable. |
| System response | When the app initializes, it instantly retrieves the saved session state from local storage to allow immediate access. In the background, it attempts to validate the session by making a network request. If the network fails due to a lack of connectivity, the app maintains the cached authentication state. Once the network is restored, subsequent requests validate if the session has expired. |
| Possible antipatterns | • 3.3: Assuming a network drop means "unauthorized" and showing a session expired error.• 4.3: Instantly clearing the cache and blocking access to logged-in features just because the validation request failed.• 5.4: Trusting the cached session indefinitely without ever notifying the user that the background network validation is failing. |
| Caching and retrieving strategy | 5 |
| Storage type | Kotlin: 1.a | Flutter: 2.c |
| Stored data type | Kotlin: Key-value pairs <string, string> | Flutter: Key-value pairs <string, string> |
| Title | Offline Network State Monitoring and Request Halting |
|---|---|
| Event description | A user attempts to trigger an action requiring a network request while the device is offline, or the connection drops during operation. |
| System response | The application detects the offline state via the network supervisor and displays a persistent offline banner above the bottom navigation bar. Subsequent outgoing network requests are halted or immediately discarded to prevent timeouts, while the supervisor continuously monitors for the connection to be restored. |
| Possible antipatterns | • 1.1: The app crashes entirely when trying to halt network requests or update the offline UI state.• 1.2: The app UI freezes for several seconds while the network supervisor attempts to intercept and cancel an ongoing request before recovering.• 2: Showing a persistent loading spinner in the center of the screen instead of a non-intrusive offline banner when requests are halted.• 3.1: Displaying a generic toast saying "An error occurred" instead of clearly stating that the app is offline and requests are paused.• 5.4: Halting the network requests silently and showing an empty screen without displaying the offline banner to explain why nothing is loading. |
| Caching and retrieving strategy | 2 |
| Storage type | Kotlin: 1.e | Flutter: 2.d |
| Stored data type | Kotlin: Boolean network state variables | Flutter: Boolean network state variables |
| Title | Opportunistic Analytics Event Queueing |
|---|---|
| Event description | The user navigates the app or performs tracked actions while the device lacks an active internet connection. |
| System response | Analytics events are instantly intercepted and saved into a local persistent database queue instead of attempting a failed network call. When the background sync manager detects a restored connection, it sequentially flushes the queue and sends all stored analytics payloads to the backend while pruning old records to manage disk space. |
| Possible antipatterns | • 4.6: Losing the analytics payload completely because the app drops the event instead of saving it to the local database queue.• 5.2: Failing to flush the queue when internet returns but leaving no internal trace or log that the background upload failed.• 5.3: Successfully uploading the analytics queue but failing to clear the local database because the success response was not handled.• 9: Firing hundreds of queued analytics requests simultaneously the second the internet connects, causing a massive network spike that slows down the app. |
| Caching and retrieving strategy | 2 |
| Storage type | Kotlin: 1.b | Flutter: 2.a |
| Stored data type | Kotlin: JSON formatted payload strings and timestamps | Flutter: JSON formatted payload strings and timestamps |
Local Storage:
The local storage strategies for network and synchronization are applied when the application needs to maintain user access, monitor internet connectivity, and securely record analytics events during unstable or entirely offline network conditions. In these situations, the app must seamlessly preserve the user's login state, gracefully pause failing network requests, and ensure that tracked user actions are not lost into the void. To handle this effectively, the network and synchronization system uses two main storage strategies.
-
The first strategy relies on a lightweight key-value preference store. This strategy is used to persist the user's authenticated session locally and track the current network state using simple boolean variables. When a user opens the app without an internet connection, the system instantly reads the saved session from this fast storage to grant immediate access, rather than falsely assuming the user is unauthorized and forcing a logout. Additionally, by storing the network state, the app can instantly detect when it is offline, halting outgoing network requests and displaying a non-intrusive offline banner.
-
The second strategy utilizes a local persistent database to act as an opportunistic queue for analytics. When a user navigates the app while offline, their tracked actions cannot be sent to the server. Instead of dropping this data, the app intercepts the events and saves them as JSON formatted payloads alongside their timestamps as individual rows in this database. Once the device regains internet access, a background sync manager reads this queue and sequentially uploads the events to the server. Sending them sequentially prevents massive network spikes that could slow down the app, and once successfully uploaded, the local records are pruned to free up disk space.