Keep previously synced data for offline usages?
Using Subway Tooter and at times being left in environments without stable network access, it would be great if the app could keep whatever kind of data it downloaded before cached locally to read through them while not being connected. Would that be possible to add/implement...?
ST doesn't save posts to disk because it's supposed to be quite heavy to save / load when you open a lot of tabs. And I can't decide when to erase the saved old posts.
It may not be your comfort, but… Instead of treating it as such a highly volatile one, it goes back as far as memory allows. Normally, only 400 home and list TLs are stored on the server side, but public TLs, account TLs, and tag TLs are not particularly limited.
I'm not sure whether this is a good approach at all. However, I know AndStatus does something similar, and apparently (in this case) this is fairly straightforward by "just" downloading and keeping whatever data it gets hold of up to either a certain period of time or a certain amount of storage used, both subject to configuration. Still am using AndStatus for that purpose here, but Subway Tooter has a few advanced features that are interesting too (still searching for that "one" fediverse client that has most if not all of these features baked in ... :smile: ).
Users want to scroll back indefinitely to a particular column, but they aren't as kind as pushing the reload button to clear the cache in the timeline after they're done. If the amount of cache stored is significantly high, the app will try to load the cache into RAM immediately after launching and will run out of RAM and crash. I'm afraid of this, as ST can have a particularly large number of columns. However, the question "when should the acquired data be cleared?" Is clearly not easy.
Not sure how to handle these things best on a mobile device TBH. In my environment (desktop/server), approach would probably be like:
- Cleaning stuff: Set particular limits (such as "delete everything older than XX days" or "if we consume more than XX GB, delete oldest stuff until we're below XX GB again") and handle that in some sort of listener while launching or stopping the application. Or, initially, do it manually altogether. Like Thunderbird or AquaMail did: "Compress folders" or something the like. Not sure whether doing this in a listener is possible and/or a good idea on Android.
- Caching: Maybe, too, here mail clients and/or AndStatus could serve as an example? K9Mail, here, displays a bunch of messages, newest-first, and allows you to scroll to a certain point past which you can say "load more" which causes the app to, well, load more. 😉️
But yes, I agree it's not easy, and especially more so, most likely, if the app hasn't been from ground built up around such a particular paradigm. Plus, too, I'm not at all sure this is something anyone else but me could possibly need or want.