Say you have a table view T which shows messages,
T[ message d
T[ message c
T[ message b
T[ most recent message down bottom
Say there are 100 messages, with the bottom 4 visible in the example.
So the table view height is 700 say. You have a typical text entry underneath...
T[ message d
T[ message c
T[ message b
T[ most recent message down bottom
[enter snapped chat message!] [send]
When the keyboard appears, the new height of the visible table view is 400 say.
Of course, that will "cut off the bottom" of the messages - the most recent two will no longer be visible.
T[ message d
T[ message c
[enter snapped chat message!] [send]
[ iOS keyboard ]
[ iOS keyboard ]
(So, messages A and B are now "under" the keyboard.)
Naturally what you do is just scroll the table after the keyboard appears, for example. No problem doing it in an ad-hoc manner.
However, it would be really natural if one could subclass UITableView in such a way that, as the size of the visible area changed, the table view knew to keep the "bottom point" identical.
So, as the bottom of the table moves up and down (due to keyboard appearing - or whatever cause), the table would scroll actually based on the movement of the "base" of the table.
(Apart from anything else this would solve the "match the animation timing" nuisance.)
Could this be achieved elegantly and if so how - indeed this would seem so natural these days, perhaps it's built-in to UITableView as a flag and I just don't know?
once again the question here is
How to modify UITableView so that it moves its own scroll position, as, the view size changes...
(so as to keep the "bottom point the same")
Note that it's trivial to just scroll the table "manually" as it were from the outside.