Implements an alternative technique for dragging the keyboard on iOS 9

[dzenbot]

Because the keyboard is on its own view hierarchy since iOS 9, we needed to lookup for its view so we could move the keyboard view following the text input using a panning gesture, using private APIs. We no longer use private APIs, but we needed this feature back.

This is an alternative technique, working in the following way:

• Whenever the panning gesture recogniser changes state to Began, we take a snapshot of the keyboard window and add it as a subview of the textInputbar, just below, at the same position the keyboard is.
• We then hide the window keyboard since it overlaps the app's window.
• Then, when dragging the textInputbar, the user will have the impression the keyboard is following, accomplishing the effect we wanted. After all, we don't need interactivity on the keyboard.
• Whenever the panning gesture recogniser changes states to either Possible, Cancelled, Ended or Failed, we remove the keyboard mockup and unhide the keyboard window, going back to the original layout.

This works great on iPhone and iPad. It is not needed on iOS 8 and 7, since we are able to access the keyboard view like we use to, without any private API usage.

Here's the result:

[mpanoff]

Crazy idea. Have you tried grabbing the keyWindow from the UIApplication after the keyboard notification event has fired?

[dzenbot]

Yes. Unfortunately, the key window doesn't change. It's always the app window.

The keyboard window should always be above any other window from the view hiearchy, since it needs to overlap any piece of UI. But still, this could eventually break on future iOS releases. It is not reliable, but so far, the best way to access its view "legally".

[mpanoff]

👍

[rounak]

Why not create an input accessory view of the same height as the text view, and get its frame and move the actual text view?

[dzenbot]

We used to do that, some time ago. We moved away from that approach since it wasn't satisfactory enough (dragging lags, UI issues, firing more keyboard notifications than expected, etc.).
See #243

On iOS 7 and 8, it seemed more reliable to be able to drag the keyboard view guaranteeing the sticky effect of the text input. We never anticipated that huge change on iOS 9. Moving back to the old approach would mean a huge refactor.

[rounak]

@dzenbot how do you think the other people (FB, Insta etc.) do it?

[dzenbot]

I sincerely have no clue.
I know that the Telegram app used to access the keyboard's window using the same technique we did, just camouflaging the private class names by encoding them, and decoding when needed.

[iosdeveloper]

Why don't you use keyboardDismissMode set to interactive to achieve this?

[dzenbot]

@iosdeveloper please see #361 (comment)

[dzenbot]

Closing/Reopening to run tests again.

[aryaxt]

I Might be a little late but, this can be done by setting an invisible view as an InputAccessoryView of the textView, and then using KVO to observe frame and center changes.
https://github.com/aryaxt/TextInputBar/blob/master/TextInputBar/Source/TextInputAccessoryView.swift

The only challenge I had with this solution was handling and calculating offsets when running in a modal form-sheet in an iPad landscape mode. I believe SlackTextViewController has this issue as well

[dzenbot]

That is exactly what we used to do before. It's a well known and clean technique.
Problem is that it didn't work on iOS 9, thus we started using private APIs to access the keyboard's window to be able to listen to the center property's update.

On iOS 9, this call will never work:

for path in keyPathsToObserve {
    newSuperview?.addObserver(self, forKeyPath: path, options: .New, context: myContext)
}

https://github.com/aryaxt/TextInputBar/blob/master/TextInputBar/Source/TextInputAccessoryView.swift#L67-L77

[aryaxt]

@dzenbot Not quite sure what the issue is. I'm currently using this technique in production with no issues on iOS9. I just tested and verified (iOS 9.2.1) that willMoveToSuperview get's called and sets the observer, and as I'm pulling the keyboard down observeValueForKeyPath is called.

the one thing I noticed is that only center is called, and not frame

willMoveToSuperview
addObserver:forKeyPath frame
addObserver:forKeyPath center
observeValueForKeyPath Optional("center")

[dzenbot]

What is newSuperview for you, on iOS 9?

[aryaxt]

it returns <UIInputSetHostView: 0x129431860; frame = (0 667; 375 0); layer = <CALayer: 0x129414d30>)

[dzenbot]

I will give it a try to https://github.com/aryaxt/TextInputBar/ but it might just not apply much for this project, since we don't layout the textInput as a text input accessory view any more. Switching back will mean a huge refactor.

[aryaxt]

@dzenbot 👍
FYI: my input bar is not set as an accessoryView, it's added as a view of the controller. The accessoryView is TextInputAccessoryView which is just a hidden view is only used for tracking the movement of the keyboard

[ashare80]

@dzenbot Man I feel your pain here haha.

Did you every try using the accessoryView and overriding addConstraint: to capture and modify the height constraint? If so any issues?

I'm using the auto-created height constraint to update the height of the accessoryView to allow for the interactive dismiss to still work. Since that internal constraint is not animatable, I animate the content to the new height before setting the internal constraint.

Check out my project here https://github.com/ashare80/ASTextInputAccessoryView

[dzenbot]

That looks very interesting! Will have a look real soon.

[AYastrebov]

@dzenbot thanks for this solution!
Will it be merged in nearest release?
When should we expect this fix in master?

Thanks!

[dzenbot]

We will eventually revisit this solution with a different approach after all.

[felixchan]

Has this issue been abandoned? How do we enable this behavior?

[joihelgi]

@dzenbot Is this still a problem? or what do you use in slack today to achieve keyboard dragging?

[christiansoe]

@aryaxt's solution worked for me!

[hipwelljo]

Super interested in the different approach, keyboard panning to dismiss is sorely missed.

[diegogarciar]

tableView.keyboardDismissMode = .onDrag does the trick