Caching Strategies:

Bookings List — Cache Then Network

The bookings list uses a two-phase load strategy. On screen open, the app immediately reads and displays the last known bookings from the local SQLite database, giving the user instant feedback with zero perceived latency. In parallel, a network request fetches the current bookings from the backend. On success, the local database is updated and the UI refreshes. Both the local read and the local write are wrapped in non-fatal error handling — a cache failure never blocks the user from seeing data.

Eventual Connectivity Scenarios:

Title	Offline-First Bookings List Loading
Event description	The user opens the bookings tab while the device is offline or the backend is unreachable.
System response	The application immediately loads and displays the last known bookings from the local SQLite cache, giving the user instant visual feedback. In the background, it attempts a network refresh. If the network call fails due to lack of connectivity, the cached list remains visible and no error disrupts the UI. The cache write failure is also non-fatal — if saving to the local database fails after a successful network refresh, the fresh data is still shown to the user.
Possible antipatterns	• 4.6: Showing a blank bookings list because the app discarded the local cache before the network call completed.• 5.4: Displaying an empty screen with no message when the network fails and no local cache exists yet.• 2: Showing a stuck loading spinner if the network request hangs indefinitely instead of falling back to the cache.• 3.3: Showing "No bookings found" when the user actually has bookings but the device is offline and the local cache was not read.
Caching and retrieving strategy	5 Cache then network
Storage type	Flutter: SQLite / Android: SQLite
Stored data type	Flutter: Booking records (id, roomId, date, startTime, endTime, purpose, status) / Android: (id, roomId, date, startTime, endTime, purpose, status)

Title	Offline Create Booking with Eventual Sync
Event description	The user attempts to create a room booking while the device has no active internet connection.
System response	The application attempts the network request. When it detects a connectivity failure (no response from server), instead of showing an error, it enqueues the create action into an in-memory pending action queue. The user is immediately informed via a long-duration snackbar that the booking is queued and not yet confirmed, and that closing the app before connectivity is restored will discard the action. The create booking screen closes. When the connectivity monitor detects the connection is restored, the queue is flushed and the action executes against the backend. The result (success or mapped error) is shown to the user via an app-wide dialog.
Possible antipatterns	• 4.6: The booking disappears entirely because the app threw an error and did not enqueue the action.• 5.2: The queue flushes but fails silently — the user never learns whether the booking was confirmed or rejected.• 5.3: The booking syncs successfully on reconnect but no confirmation is shown to the user.• 9: The user taps "Book" multiple times while offline, queuing duplicate create actions that all fire on reconnect and create multiple overlapping bookings.• 8.1: On some offline attempts the app queues the action, on others it throws a raw network exception, depending on timing.
Caching and retrieving strategy	2 Network only
Storage type	Flutter: Other / Android: SQLite
Stored data type	Flutter: Booking request payload (roomId, date, startTime, endTime, purpose) / Android: (roomId, date, startTime, endTime, purpose)

Title	Offline Delete Booking with Eventual Sync
Event description	The user attempts to delete an existing booking while the device has no active internet connection.
System response	The application attempts the network delete request. On connectivity failure, it applies an optimistic local update: the booking is removed from the local SQLite cache and from the displayed list immediately, so the UI reflects the intended action. The delete action is enqueued into the in-memory pending action queue. The user is informed via a long-duration snackbar that the deletion is pending and not yet confirmed, and that closing the app will discard the queued action. When connectivity is restored, the queue flushes and the delete request is sent to the backend. The result is shown via an app-wide dialog. If the sync fails, the error is mapped to a user-friendly message and shown in the dialog.
Possible antipatterns	• 4.6: The booking stays visible in the list after the offline attempt because the app did not apply the optimistic local removal.• 5.2: The delete action flushes silently on reconnect — the user never learns if the deletion succeeded or failed.• 7: The booking is removed from the local UI but the network sync never fires on reconnect, leaving the booking still active on the server permanently.• 8.1: On some offline delete attempts the app removes the booking locally and queues; on others it throws a generic error with no local change, depending on timing.• 3.3: Displaying "An error occurred" instead of informing the user that the delete is queued and awaiting connectivity.
Caching and retrieving strategy	2 Network only
Storage type	Flutter: SQLite & Other / Android: SQLite
Stored data type	Flutter: Booking ID string (local removal) + delete action reference (in-memory queue) / Android: "TODO"

Local Storage:

Flutter and Kotlin:

Stores the user's active bookings locally to support offline display and optimistic deletes. Populated on every successful network fetch and cleared on logout.

Column	Type	Description
id	TEXT (PK)	Booking UUID from backend
roomId	TEXT	Room identifier
date	DATETIME	Booking date
createdAt	DATETIME	Creation timestamp
startTime	TEXT	Slot start time (HH:mm)
endTime	TEXT	Slot end time (HH:mm)
purpose	TEXT	Booking purpose enum value
status	TEXT	Booking status (e.g. active)

Lifecycle: Written after every successful network fetch. Rows deleted individually on confirmed delete (online) or optimistically on offline delete. Entire table cleared on user logout.