@mikael Thanks, Mikael! That was a very helpful hint. I've proceeded quite a bit with my implementation. I've created a view called
EnhancedView which can serve as a drop-in replacement for
ui.View in layouts that have at least one
ui.TextField in them. See here. The view does the following:
- It overwrited the method
keyboard_frame_did_change to hook into the changes of the keyboard frame (as suggested by you).
- Upon first call of the method it scans all subviews recursively to find all
- The default
delegate method of all these subviews is replaced by a delegate listening to the
- When editing is started in one of the subviews, this subview stores itself as current view in the
- When editing is finished the view removes itself again.
- For each call to
EnhancedView checks if a) the keyboard is visible, b) it has an active editing subview and c) the subview is at least partially hidden by the keyboard. If so, it computes a delta y offset for its
bounds attribute and thus moves itself upward. In all other cases it restores the
bounds to its original value (which is
The only little problem left is that even the recursive scan of the delta offsets for the y coordinate does not yield the correct value on the iPad. For some reason the topmost view has an offset of
y=0 according to its
frame. However, it is NOT at the top of screen but underneath the status bar which seems to have a height of 20 pixels. If I add those 20 extra pixels on the iPad it works fine. But on my iPhone, it actually shifts the the view to hight, although the status bar is visible there, too.
Is there a way to distiguish between these cases? Thanks a lot!