unified warning panel for all screens - #6587
Draft
mahibi wants to merge 8 commits into
Draft
Conversation
Detects HTTP 503 responses carrying the X-Nextcloud-Maintenance-Mode header during chat message polling and surfaces a red banner in the message input area, mirroring the "Connection lost" banner and the maintenance-mode banner already shown in the conversation list. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
getRoomsFromServer() caught and only logged exceptions from the background room-list sync, so GetRoomsErrorState was never produced by the current getRooms() path (roomListFlow only observes the local database, not the network call). This made handleHttpExceptions unreachable, silently breaking the unauthorized/outdated-client dialogs and the maintenance-mode banner. Adds a getRoomsErrorFlow that the repository emits into instead of swallowing the exception, collected by the view model into the existing GetRoomsErrorState. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
…in a shared interceptor Chat and conversation list each had their own bespoke detection of server maintenance mode (HTTP 503 + X-Nextcloud-Maintenance-Mode header), each only covering their own network call. Replaces both with a single OkHttpClient interceptor that sees every request for every screen and account, and publishes status changes (maintenance mode, unauthorized, client-update-required) via EventBus for any screen to react to — mirroring how the iOS app's NCAPISessionManager.checkStatusCode works. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
…t observing late HttpStatusInterceptor only posts a ServerStatusEvent on a status transition, so a screen that starts observing after the transition already happened never learns the current status. In practice, the conversation list is usually first to detect maintenance mode; by the time a chat is opened, no new transition occurs since the account is already flagged, so the chat banner never appeared even though the server was still in maintenance mode. Adds HttpStatusInterceptor.currentStatus(accountId) so ChatActivity and ConversationsListActivity can seed their state as soon as the account is known, in addition to reacting to future transitions. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
…seActivity Centralizes maintenance-mode/offline detection into BaseActivity (account resolution, EventBus subscription, HttpStatusInterceptor seeding) instead of each screen wiring its own state, and adds the shared StatusBannerRow (moved to components/, self-padding for the status bar only when visible) to the conversation list plus the 12 other screens that are fully written in Compose. ChatActivity keeps its existing XML-based banner untouched, since it mixes XML and Compose rather than being fully Compose. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
…ntWithStatusBanner Each fully-Compose screen repeated the same isOnline/isMaintenanceMode state collection and Column-wrapping to show the shared status banner. Adds BaseActivity.setContentWithStatusBanner(content), a drop-in replacement for setContent that collects the state once and renders StatusBannerRow above content, and switches all 12 screens to use it instead of duplicating the wiring. ConversationsListActivity is unchanged: its banner is embedded inside its own Scaffold's topBar alongside the conversation list's top bar, not the generic "wrap everything" shape the helper assumes. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
ConversationListTopBar always applied statusBarsPadding regardless of whether StatusBannerRow above it was already visible and self-padding for the status bar, producing a visible gap between the banner and the search/top bar. Only pad the top bar when the banner is hidden. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Several screens apply their own statusBarsPadding()/Scaffold inset (ThreadsOverviewActivity, DiagnosisActivity, LogsActivity, ConversationCreationActivity, ContactsScreen, LocationPickerScreen) assuming they sit at the true top of the window. Once StatusBannerRow is visible it already claims that inset for itself, so those screens' own padding added a second, redundant gap on top of it (e.g. an oversized app bar in "new conversation"). setContentWithStatusBanner now marks the status-bar inset consumed for content() whenever the banner is showing, so screens' existing statusBarsPadding() calls add nothing extra in that case. Fixed once centrally since some of the affected composables (ContactsScreen, LocationPickerScreen) have no access to the banner state to guard against it themselves. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Warnings like the maintenance mode should be shown on all screens* as a warning panel without duplicated code.
*= all compose screens. Old XML screens should migrate to compose to make use of the new warning panel.
🖼️ Screenshots
🚧 TODO
🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)