Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content reloads every time when switching between App-tabs #11

Open
tclaus opened this issue Oct 29, 2020 · 4 comments
Open

Content reloads every time when switching between App-tabs #11

tclaus opened this issue Oct 29, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@tclaus
Copy link
Collaborator

tclaus commented Oct 29, 2020

When I switch between "Stream" and a tab - lets say "Mail" and back - content reloads always.

A content caching between switching would be nice - user can swipe down to reload every time.
Invalidate cache after a period of time, maybe 1 minute or so.

Bonus: If parts of the stream is cached - update the cache with new content. Currently the screen gets black while reloading.
(It's just an eye candy, but let the client look really cool)

@jhass jhass added the enhancement New feature or request label Oct 29, 2020
@jhass
Copy link
Owner

jhass commented Oct 29, 2020

Yes, for now always reloading made sure users don't need to know how to manually reload, but of course that's just the simplest solution to the UX problem.

Another simple approach could be to show cached content when available but also always reload in the background. It's just really hard to then update with the new content without jumpy UI and the user noticing that they could scroll up to newer content now. Maybe we should inverse stream order....

I've also been considering to track the scroll position (as in last visible post) and restoring to that, inserting new content in the background above it. But it's a really hard problem, even harder than just caching. Especially since diaspora's paging API isn't really designed with that in mind, so it would need at least two requests to discover if there's new content since the remembered post, usually a lot more and thus degrading pod and client performance a lot.

@tclaus
Copy link
Collaborator Author

tclaus commented Oct 29, 2020

Cool ideas making background updates. Maybe a step-by-step approach has lower hurdles and same quick wins.

@tclaus
Copy link
Collaborator Author

tclaus commented Dec 3, 2020

On every tab switch- the view is disposed and new created.
Maybe this is an even quicker win, if the view is persistent between tab switches?
(My known apps on iOS do so)

@jhass
Copy link
Owner

jhass commented Dec 3, 2020

Mmh, how to avoid running out of memory then? More importantly I'd like to preserve current navigation behavior however, that is every item in the bottom navigation is "top-level" and empties the navigation stack, meaning going back from a "top-level" screen leaves the app.

So if you find a way that frees up memory when it comes under pressure and preserves the current navigation hierarchy, sure :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants