GeopJr
[Request]: Allow offline / cached mode
Describe the request
Maybe out of scope due to GTK limitations but allowing for asyncronous post updates and allow for caching so when not having network connection it will still load last defined # of posts say 15 from cache. Then update posts when network connection is reestablished to load next 15 new posts.
This refers more to persistent cache that would still be around after PC, or Phone restart and not just related to whats in Memory.
Otherwise you e get
Implementation Details
- [X] This should be an option in settings.
- [ ] This should be only available to some fediverse backends. (Include which ones on the above field).
- [X] This is client-only (and shouldn't sync with the instance).
- [X] This follows the GNOME HIG.
The above shows on a side note even when reestablishing network connection with spinning wheel, since there does not appear to be a refresh button.
The easiest to resolve is pull to refresh function or having a refresh button prominently displayed.
As a workaround restarting Tuba while connected works.
(I haven't looked into restoring from cache yet, I'll reply about it when I do)
The easiest to resolve is pull to refresh function or having a refresh button prominently displayed.
There's pull to refresh now #155 (on main)
Going from initially disconnected to connected is a bit more complex than just refreshing however, there's many other connections that need to be done prior, from instance and account information to custom emojis and notifications. Ideally there should be a queue that gets processed when internet connection is established (or keep retrying every x seconds)
Ok nice! Since restart of the app establishes the connections again currently and reliably maybe the pull to refresh could do more in certain instances when not connected to any accounts... and while that doesn't address the peristent cache issue, it would help since user wouldn't have to restart app. I am not a fan of the retrying to establish connection periodically, if the user sees a connection issue they likely will do the pull to refresh as a first attempt.
I think this would also probably speed up perceived performance quite a bit on startup, even if it needs some sort of spinner/progressbar/status indication at the top (rather than fullscreened) to say that it's still refreshing things...
