Draft: improve scrolling behavior #1767
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
closes also #1691 |
|
ftr: we decided to tackle this together with the other
message-list
|
…some reason iOS fires the delegate callback multiple times)
cyBerta
force-pushed
the
missing_inserted_messages2
branch
from
af5cefe
to
de541a1
Compare
cyBerta
force-pushed
the
missing_inserted_messages2
branch
from
b5d2dcb
to
b4fcd58
Compare
|
after playing around a little, this pr does not really fix the message-list issued, it maybe mitigates them, but there is still:
we will probably go for a bit larger rewrite in #1810 therefore. |
|
closing stale draft, superseded by #1810 |
|
cmp #1737 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Trying to figure out the root cause for the weird scroll behavior. This PR is only to discuss possible changes.
The reason I started investigating this is #1691. The fix for that issue is fairly simple, see af5cefe, if we take the DC Android as an template. However the weird scrolling down and back up when sending a message always happens now. I will explain a little bit more in the comments.
Generally I've noticed that the scrolling-down and up happens, because the messageInputBar looses it's focus when the user taps on the send button. As a result normally the keyboard would disappear. We mitigate that by re-requesting the focus for the messageInputBar when the messageInputBar's UITextViewDelegate calls back textViewShouldEndEditing(). Normally that is sufficient to keep the keyboard in place, on some devices and OS versions you may see a very small flickering.
However the frame size of the UITableView immediately changes and all cells at the bottom get moved for a short moment to the bottom of the screen, before the size frame size regains it's previous size - above the keyboard.
While experimenting and reading on stack overflow for possible solutions I learned that we can use
contentInsetto avoid the content is dragged down to the bottom of the screen. I vaguely remember we already worked withcontentInsets in the past in this controller, but scratched that approach because of other issues we had with it like wrong initialization.My current idea is - contrary to what we tried in the past regarding
contentInsets - to set the content inset only temporarily at the bottom before the keyboard events are thrown / the tableViewFrame changes and reset it as soon as the reload() was done and the new message bubble appeared (but is still hidden below the keyboard).What's not yet clear to me is if any call to scrollDown would be still necessary after resetting the contentInset, or maybe after animating the contentInset value.
What I can confirm so far is that setting the contentInset in
textViewShouldEndEditing(= before the keyboard events are thrown / before the tableViewFrame size changes) indeed prevents the messages being moved down if I comment out scrolling completely.