-
Notifications
You must be signed in to change notification settings - Fork 69
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
Restrict maximum number of messages, shown in a Timeline at a time #313
Labels
Comments
I really would appreciate this feature. |
yvolk
added a commit
that referenced
this issue
Jan 14, 2016
yvolk
added a commit
that referenced
this issue
Jan 17, 2016
yvolk
added a commit
that referenced
this issue
Jan 17, 2016
yvolk
added a commit
that referenced
this issue
Jan 17, 2016
yvolk
added a commit
that referenced
this issue
Jan 18, 2016
This feature already works. Currently AndStatus loads not more than 100 messages (a "page") at a time and keeps in its memory not more than 5 pages. When a User scrolls in any direction, farther pages are discarded. |
Done in v.20.0. Published to the Open Beta testing channel, please opt in here: https://play.google.com/apps/testing/org.andstatus.app at test it! |
yvolk
added a commit
that referenced
this issue
Jan 26, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think that lack of a limit on a maximum number of messages, shown in a Timeline at a time, is a major cause of performance degradation for users, who receive thousands of new messages daily.
See #310 also.
As was decided many years ago, when a User opens a timeline, the timeline opens at the same place it was viewed before. It's not bad by itself, but together with these old messages ALL newer messages are shown. A few hundreds of messages are not a problem, but showing a thousand or even more can freeze the application for a long time.
We should make the "view page" movable, so only closest "page of messages" is shown, not all since the time of the last viewed message.
I think that a page size of 200 messages will be good enough.
What is not trivial: how to load new messages from a database (and drop unneeded messages) intelligently...
The text was updated successfully, but these errors were encountered: