Show "Connecting…" banner (or equivalent) when server data is stale

[gnprice]

When we lose our real-time stream of events from the server, either because of network failures or because the server has expired the event queue and we need to request a new one:

• Retry long-poll failures, with backoff #184
• Start new event queue when old one has expired #185

we continue to show the latest server data we had, but it may now be stale. We should communicate to the user that that's what's happening.

In the existing zulip-mobile app, we do this with a banner that reads "Connecting…" and appears just under the app bar.

In this app, we could do the same thing, or we could find a different design. One downside of the "Connecting…" banner is that it occupies some vertical space, which means the rest of the content needs to move down to make room (or else let its top portion be obscured by the banner). Nevertheless it might be the best available option.

Even if we use the same design concept, we'll want to pin down the details: the text style, the layout, the banner's background, the specifics of how it animates in and out.

(In zulip-mobile the details are in src/common/LoadingBanner.js; there's no animation. But the conceptually similar "No Internet connection" banner, found in src/boot/OfflineNoticeProvider.js, does have an animation… on iOS only, because React Native's implementation breaks on Android. Here on Flutter, we should have no such trouble implementing whatever animation we choose.)

[gnprice]

Bumping this in priority because even after #185 and #184, we're still sometimes showing the symptom of lacking an event queue, even when the device has a fine internet connection:
https://chat.zulip.org/#narrow/stream/48-mobile/topic/Only.20.22all.20messages.22.20updating/near/1754151
(I guess Alex didn't explicitly say the last part, but I definitely had a fine connection when I observed similar symptoms the other day.)

And as Alex said there:

silently not having updates means I cannot trust the app. Having some user feedback seems very important, here.

[chrisbobbe]

Maybe something like a toast?

Or a thin, linear indeterminate progress indicator at the bottom of the app bar (LinearProgressIndicator), like we do when logging you in? (It disappears quickly in this video, but it's there.)

RPReplay_Final1709858536.mov

(Huh, the screen capture seems to have included audio, so you can hear the music I was listening to at the time. 😆)

[gnprice]

a thin, linear indeterminate progress indicator at the bottom of the app bar (LinearProgressIndicator), like we do when logging you in?

Yeah, that sounds like the easiest thing to do that remains pretty clean-looking. We can always revise it to another design later.

(Going with either LinearProgressIndicator, or a toast, for now will mean we spend basically zero effort on implementing the specifics of the UI — so there'll be essentially zero wasted work if we later go with another design.)

I'm about to file another issue (→#555) for a toast with more detailed information, which might be too technical-looking for a general release but is fine for this beta and may help us pin down remaining issues in failing to connect.

[chrisbobbe]

A toast might be easier to apply in all the right places than the LinearProgressIndicator solution.

The toast solution requires fewer things of the surrounding UI, I think. To show a toast, you just need to know which account (if any) the foregrounded page belongs to and whether its data is stale. But to show a LinearProgressIndicator, you need to know that plus (if the page is per-account) you need the page to have an app bar. And for a nice experience, you might need to adapt to specific things about the app bar, like what color it is. Also I could imagine a future where some app bars use Material widgets and some don't, and that sounds potentially annoying to manage.

I guess concretely, consider the lightbox, which is a per-account page: a saturated blue loading indicator might look jarring on the gray, semitransparent surface of the lightbox app bar, so we might want to tone that down, which might an annoying obstacle to making cleanly reusable code. Also, the lightbox app bar isn't even always visible, because you can tap it to make it go away. I think something like a toast might be the only thing that really works on the lightbox page, actually. And if we're doing it on that page, we might as well do it everywhere; what do you think?

[gnprice]

The toast solution requires fewer things of the surrounding UI, I think. To show a toast, you just need to know which account (if any) the foregrounded page belongs to and whether its data is stale. But to show a LinearProgressIndicator, you need to know that plus (if the page is per-account) you need the page to have an app bar. And for a nice experience, you might need to adapt to specific things about the app bar, like what color it is.

True, yeah.

[satyam372]

"Hi gnprice,

Below is the proposed solution for issue #465. Please have a look at it and let me know so that I can move forward in integrating it with the Zulip beta application.
https://github.com/zulip/zulip-flutter/assets/112092492/49670e0e-53ae-47bb-94c2-f1d1d2214306