The Flutter rooms search flow uses a bounded in-memory cache for the last successful search only. After page 1 is fetched successfully from the backend, the app stores that page in memory and then silently prefetches pages 2 and 3 in the background. The cached pages are indexed by page number and reused only for that same last successful search snapshot.

The Kotlin rooms search flow uses a bounded in-memory snapshot cache for the last successful search only. After page 1 is fetched successfully from backend, it stores page 1 in memory and silently prefetches pages 2 and 3 in background. Cached pages are indexed by page number and reused only for that same last successful search snapshot.

This is a SparseArray-style cache in the sense that it stores a small sparse subset of integer-indexed result pages (BOTH):

• page 1
• page 2
• page 3

It is not LRU, because it does not keep multiple historical searches and does not evict by recency. It is not persistent storage either. It lives only in memory during the current app session.

Behavior summary: (BOTH)

• Cache is created only after a successful page-1 search response.
• Pages 2 and 3 are prefetched in the background.
• Prefetch failures are silent and never block the UI.
• A new successful search replaces the old cached snapshot entirely.
• Only the first 3 pages are eligible for offline fallback.

The Flutter home search form also keeps a memory-only snapshot of the user’s current search parameters so that reopening the home screen restores the latest values instead of resetting them immediately to defaults.

This is implemented as an ArrayMap-style cache because it stores a small fixed set of named key-value parameters:

• room input text
• selected utilities
• selected date
• since time
• until time
• close-to-me toggle

If no cached snapshot exists yet, the home screen falls back to its built-in defaults:

• empty room text
• no selected utilities
• today
• current time
• current time + 90 minutes
• close to me = false

This cache is also memory-only and tied to the current Flutter app session.

Kotlin home search also keeps a memory-only snapshot of the latest search configuration so reopening home can restore prior inputs instead of always hard-resetting immediately.

This is implemented as an ArrayMap-style cache because it stores a small fixed set of named key-value parameters:

• room input text (classroom)
• selected utilities (utilityDisplayNames)
• selected date
• since time
• until time

If no cached snapshot exists yet, the home screen falls back to its built-in defaults that are the same as in Flutter:

This cache is also memory-only and tied to the current Flutter app session.

Title	Offline Homepage Search Fallback
Event description	The user submits a room search from the Flutter home screen while the device has no internet connection or the backend is unreachable.
System response	Flutter: The application first attempts the normal network search. If the request fails due to connectivity and a cached snapshot of the last successful search exists, the app navigates to results, shows cached page 1, and informs the user that cached results from the previous search are being displayed. If no cached search snapshot exists, the app navigates to a dedicated No Internet screen instead of showing results. Kotlin: The application first attempts the normal network search. If the request fails due to connectivity and a cached snapshot of the last successful search exists, the app navigates to results, shows cached page 1, and informs the user that cached results from the previous search are being displayed. If no cached search snapshot exists, the app still navigates to results and shows an offline placeholder/message indicating that internet is required, instead of rendering normal result cards.
Possible antipatterns	• 4.6: The previously available search results disappear completely because the app ignores the in-memory fallback. • 5.4: The app shows an empty results state or stays on home with no explanation when the request fails and no cache is available. • 3.2: A raw network/Dio exception is shown instead of a user-friendly offline explanation. • 8.1: The same offline home search sometimes opens cached results and other times fails silently under identical conditions.
Caching and retrieving strategy	4, 6 - Cached on network response and Generic Fallback
Storage type	Both: Other
Stored data type	Flutter: In-memory room search snapshot (base query + cached result pages 1–3) ,Kotlin: In-memory room search snapshot (last successful query context + cached result pages 1-3)

Title	Offline Paging Fallback for Cached Results
Event description	The user is already viewing room search results in Flutter, loses connectivity, and continues paginating through the result set.
System response	Flutter: If the user requests page 1, 2, or 3 and that page is present in the in-memory cached snapshot of the last successful search, the application shows the cached page and informs the user that cached results are being displayed. If the user attempts to navigate to page 4 or beyond while offline, the application does not fabricate more pages and instead redirects the user to the dedicated No Internet screen. Kotlin: If the user requests page 1, 2, or 3 and that page is present in the in-memory cached snapshot of the last successful search, the application shows the cached page and informs the user that cached results are being displayed. If the user attempts to navigate to page 4 or beyond while offline, the application does not fabricate additional pages and instead shows an offline-required message/placeholder for that navigation attempt.
Possible antipatterns	• 4.6: Cached pages are discarded and the results screen becomes blank after connectivity is lost. • 5.5: The user reaches the cache boundary but receives no indication that internet is required to continue. • 3.3: The app says there are “no more rooms” when the real problem is lack of connectivity beyond the cached page window. • 8.2: Repeated offline page navigation produces inconsistent transitions between cached pages and failure screens.
Caching and retrieving strategy	4, 6 - Cached on network response and Generic Fallback
Storage type	Both: Other
Stored data type	Flutter: In-memory cached room result pages indexed by page number (1, 2, 3), Kotlin: Kotlin: In-memory cached room result pages indexed by page number (1, 2, 3)

---

None.

The current Flutter and kotlin rooms implementation does not use persistent local storage for room search results or home search parameters. Both the search-results cache and the home-parameters cache are memory-only and are discarded when the app process/provider container is destroyed.