Initial eventual connectivity scenarios - ISIS3510-202510-T14/Documentation GitHub Wiki
The following eventual connectivity scenarios (Scenarios 1–7 listed above) are deprecated and must not be considered for grading purposes in Sprint 3.
Only the eventual connectivity (EC) scenarios explicitly described here should be considered for evaluation in Sprint 3.
| Scenario ID | Event Description | System Response | Possible Anti-Patterns | Caching and Recovery Strategy | Storage Type | Stored Data Type |
|---|---|---|---|---|---|---|
| 1 | The user attempts to place a bet without an internet connection. | The application notifies the user that the bet could not be processed due to connectivity issues and stores the bet amount along with the selected team. When the user returns, the information will be pre-loaded so they can manually retry the bet. | - #4 (Lost Content): if the bet is not properly stored or is lost without notification. - #9 (Unexpected Result): if the information is not presented to the user for retry. |
#3 Network fallback to cache | SQLite (e.g., using the sqflite package) | JSON-formatted bet data (amount, selected team, etc.) |
| 2 | The user accesses the list of matches without an internet connection. | The application attempts to fetch the latest data from the backend to display up-to-date information. Since there is no connection, it falls back to the most recent cached version, prioritizing the latest matches. The user is notified that offline content is being displayed. | - #4 (Lost Content): if nothing is shown or the information is incomplete. - #5 (Non-existent Result Notification): if the user is not informed about the offline mode. |
#3 Network fallback to cache and #4 Cached on network response | SQLite (e.g., using the sqflite package) | JSON-formatted list of matches, ordered by descending date. |
| 3 | The user attempts to log in online by sending credentials to Firebase for authentication. | The application sends the login data to the backend. If authentication is successful, the session is initiated and the token is stored; if connectivity issues cause the authentication to fail, the user is notified and allowed to retry. | - #8 (Unclear Behavior): if the connectivity failure is not clearly communicated; potential issues with timeouts or uncontrolled retries. | Network only: A connection is required for initial authentication, with no local cache used for credential validation. | N/A | Securely stored session token and user data. |
| 4 | The user opens the application offline after having previously logged in. | The application securely retrieves the stored credentials and allows offline access with limited functionality, displaying a notice about the restrictions. | - #8 (Unclear Behavior): if the limitations of offline mode are not clearly communicated; potential security risks if credentials are not stored securely. | #3 Network fallback to cache | flutter_secure_storage (or another secure mechanism) | Securely stored session token and user metadata. |
| 5 | The user is near a sports event location. | The application detects the user's proximity to an upcoming sports event using geofencing and pushes a notification reminding them about the event. | - Potential issues: notification fatigue if reminders are too frequent, or inaccurate geofence detection. | Cache event details locally to generate notifications promptly, even without a network connection. | SQLite or local storage | JSON-formatted event details (e.g., event ID, name, location, time). |
| 6 | The user is at an ongoing sports event. | Upon detecting the user's presence at the event via geolocation, the application sends a push notification featuring a bet button to encourage immediate betting actions. | - Potential issues: confusing user experience if the bet button is not clearly interactive or if the geolocation trigger is inaccurate. | Ensure the latest event data is available via local caching; if network connectivity is poor, fallback to cached event and betting options. | SQLite (e.g., using the sqflite package) or other local storage mechanisms | JSON-formatted event betting options, including current odds and bet details. |
| 7 | The user accesses the Recommended Bets section without an Internet connection. | The app tries to fetch the latest recommendations from the backend; if no network is available, it shows the cached recommendations (sorted by descending date) and notifies the user of offline mode. When connectivity is restored, it syncs in the background and refreshes the view. | #4 (Lost Content): if no recommendations are displayed or they are incomplete. #5 (Non‑existent Result Notification): if offline mode is not communicated. |
#3 Network falling back to cache + #4 Cached on network response | SQLite (sqflite package) | Betting recommendations in JSON (id, eventId, type, description, timestamp) |
|
-
Scenario 1 Diagram:
-
Scenario 2 Diagram:
-
Scenario 3 Diagram:
-
Scenario 4 Diagram:
-
Scenario 5 Diagram:
-
Scenario 6 Diagram:
