Forum Archive

While implementing a system to determine which text input widget has focus, and place it in the right location when the keyboard shows up, I have found some odd and inconsistent behavior in the calling of the ui.View keyboard_frame_will_change() and keyboard_frame_did_change() methods. I'm curious if anyone else is seeing anything like this?

First, it seems like they get called much more often than I'd expect when the keyboard shows up or hides or changes size. I was expecting a call to "keyboard_frame_will_change()" just before the keyboard shows or changes size, and then a call to "keyboard_frame_did_change()" just after it has finished showing or changing size.

Instead, I see at least two calls to "will change" and then two calls to "did change" all with the same keyboard frame on my iPad, but on my iPhone 7, I'm seeing even more: two "will change" calls with one frame size, then two "did change" with that same size, then another set of two calls each to "will change" and "did change" with a somewhat different size, then another set of two calls each to "will change" and "did change" back to the first frame size.

Also, on my iPhone, but not on the iPad, I see when I run my app in one orientation and then rotate to the other (so, from portrait to landscape or vice versa) and then tap a text field and bring up a keyboard, the reported frame size is either for the wrong orientation, or is invalid (0,0,0,0).

Below I'm including the debugging output I get if I just print the "frame" parameter that "keyboard_frame_will_change()" and "keyboard_frame_did_change()" are given. For each it's just a single tap in a textfield, and the keyboard coming up:

iPad, landscape orientation:
keyboard frame will change: (0.00, 370.00, 1024.00, 398.00)
keyboard frame will change: (0.00, 370.00, 1024.00, 398.00)
keyboard frame did change: (0.00, 370.00, 1024.00, 398.00)
keyboard frame did change: (0.00, 370.00, 1024.00, 398.00)

iPad, portrait orientation:
keyboard frame will change: (0.00, 711.00, 768.00, 313.00)
keyboard frame will change: (0.00, 711.00, 768.00, 313.00)
keyboard frame will change: (0.00, 711.00, 768.00, 313.00)
keyboard frame will change: (0.00, 711.00, 768.00, 313.00)
keyboard frame did change: (0.00, 711.00, 768.00, 313.00)
keyboard frame did change: (0.00, 711.00, 768.00, 313.00)
keyboard frame did change: (0.00, 711.00, 768.00, 313.00)
keyboard frame did change: (0.00, 711.00, 768.00, 313.00)

iPhone, portrait orientation:
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)
keyboard frame will change: (0.00, 451.00, 375.00, 216.00)
keyboard frame will change: (0.00, 451.00, 375.00, 216.00)
keyboard frame did change: (0.00, 451.00, 375.00, 216.00)
keyboard frame did change: (0.00, 451.00, 375.00, 216.00)
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)

iPhone, landscape orientation:
keyboard frame will change: (0.00, 181.00, 667.00, 194.00)
keyboard frame will change: (0.00, 181.00, 667.00, 194.00)
keyboard frame did change: (0.00, 181.00, 667.00, 194.00)
keyboard frame did change: (0.00, 181.00, 667.00, 194.00)
keyboard frame will change: (0.00, 213.00, 667.00, 162.00)
keyboard frame will change: (0.00, 213.00, 667.00, 162.00)
keyboard frame did change: (0.00, 213.00, 667.00, 162.00)
keyboard frame did change: (0.00, 213.00, 667.00, 162.00)
keyboard frame will change: (0.00, 181.00, 667.00, 194.00)
keyboard frame will change: (0.00, 181.00, 667.00, 194.00)
keyboard frame did change: (0.00, 181.00, 667.00, 194.00)
keyboard frame did change: (0.00, 181.00, 667.00, 194.00)

iPhone orientation change (Portrait to Landscape):
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)
keyboard frame will change: (0.00, 451.00, 375.00, 216.00)
keyboard frame will change: (0.00, 451.00, 375.00, 216.00)
keyboard frame did change: (0.00, 451.00, 375.00, 216.00)
keyboard frame did change: (0.00, 451.00, 375.00, 216.00)
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame will change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)
keyboard frame did change: (0.00, 409.00, 375.00, 258.00)
keyboard frame will change: (0.00, 0.00, 0.00, 0.00)
keyboard frame will change: (0.00, 0.00, 0.00, 0.00)
keyboard frame did change: (0.00, 0.00, 0.00, 0.00)
keyboard frame did change: (0.00, 0.00, 0.00, 0.00)
keyboard frame will change: (0.00, 181.00, 375.00, 194.00)
keyboard frame will change: (0.00, 181.00, 375.00, 194.00)
keyboard frame did change: (0.00, 181.00, 375.00, 194.00)
keyboard frame did change: (0.00, 181.00, 375.00, 194.00)
keyboard frame will change: (0.00, 181.00, 375.00, 194.00)
keyboard frame will change: (0.00, 181.00, 375.00, 194.00)
keyboard frame did change: (0.00, 181.00, 375.00, 194.00)
keyboard frame did change: (0.00, 181.00, 375.00, 194.00)

For all the above, this is python2.7, and the iPad is running iOS 11.4.1 and the iPhone is running 12.0.1

See https://forum.omz-software.com/topic/2701/keyboard-hiding-textview/8

It used to be these methods were all wonky, and didn't use orientation properly. It has been a while since I tested this stuff, but I had a replacement method that fixed some of the errors. I think my fixes don't work anymore, but possibly this thread might spark some ideas.

https://forum.omz-software.com/topic/2701/keyboard-hiding-textview/8

@JonB well, I guess these issues still exist. Honestly, the situations where this is an actual problem are relatively unlikely to occur in the real-world use of my app, especially when I just ignore the repeated calls by comparing stored state and discarding superfluous ones.

It's good to know that it isn't something I'm doing wrong, and I'll just hope that the next release of Pythonista fixes the issue. Thanks for the info, though!

@shinyformica, reminder: the keyboard change events keep firing after your script ends, so be sure to check ui.on_screen before doing anything.

So now that I'm a little less timid about reaching into objc when necessary...looks like if I just register to be notified of the:

UIKeyboardWillChangeFrameNotification
UIKeyboardDidChangeFrameNotification

they are delivered in a much more reliable fashion than the window change methods available in ui.View. You get a single pair of notifications for each change in keyboard size, which means as long as you know which widget is receiving keyboard input, you can easily place it at the right location with a nice ui.animate().

Seems to work reliably.

@mikael I am definitely tracking whether my app is active or not, but important safety tip there.

I am only seeing one keyboard_did_change call -- however if you run multiple views, or run a a script multiple times, you can seem to get multiple call backs.

The bug seems to be related to how the view is first presented -- it is right when first presented, but after rotation it is wrong.

I started writing up a UINotifocationCenter approach. Seems to be reliable. The trick is you need to make sure you unregister your observer when the python object is deleted -- I'm playing around with some ideas that uses a "canary" object and a weakref.finalize-r to deregister observers in a more robust manner..

By the way, you might also consider using

UITextViewTextDidBeginEditingNotification
UITextFieldTextDidBeginEditingNotification

in leui of delegates to keep track of which control asked for the keyboard.

I'm not sure which order these get called, but you can use objc_setAssociatedObject(app, ns('currentTextField'), current_textfield_objcinstance, 0) to basically store the current field at the UIApplication.sharedApplication() level, making it easy to retrieve whenever. You could also store the kb frame in a similar way, to allow a working get_keyboard_frame method.

@JonB yep, I traced it to the multiple-run issue as well...which meant my unregister wasn't properly happening either. I've gotten that mostly fixed, but I still actually prefer the NSNotificationCenter way of receiving keyboard change notifications better...since it's more app-global, and not view-specific.

I am using UITextViewTextDidBeginEditingNotification, UITextFieldTextDidBeginEditingNotification, etc. to track which widget is the active one, that seems to be really the only way...without iterating over views to find the firstResponder view. What I have now works quite well, but I need to make the unregistering part more robust.

Actually, to be clear, it seems like the multiple-keyboard-change call thing was not simply multiple-run, but also having multiple views which implement those methods. The combination made it so more than one view would end up fiddling with global state, using the plain notifications and a single receiver for them, I am guaranteed single notification.

@shinyformica, would be much appreciated if you package this up as something reusable. The lack of reliable keyboard size notifications has always been a pain.

@mikael yes, I think it would be good to package it. Or at least post template code for how to do it. I'll do that when I get a moment to this thread. What do we normally use to put up reusable code snippets? Is it this Gist thing I keep seeing?

@shinyformica, gist seems good if it is clear that it is not going to need many revisions, issues, a Readme or collaboration. Otherwise, a git repo is not that much more work.