Incorrect Behavior of Library?

[royherma]

I might be wrong, and don't want to sham on all the hard work of the library creator and contributors, but it seems that this project is missing some key functionality of the interactive keyboard + custom inputAccessoryView:

I ran the example and I noticed:

• The content inset / visible cells aren't adjusted when the keyboard is shown/hidden as in Facebook/WhatsApp
• The input accessory view's animation lags when dragging the keyboard up and down

Am I missing something here?

Thanks

[nathantannar4]

Hi @royherma. An InputAccessoryView has no knowledge of what lies within a UIViewController and thus cannot adjust the bottom inset automatically. You need to use the delegate method to adjust the bottom inset.

Not sure what you mean by laggy. I have never experienced lag using the InputAccessoryView.

_{Sent with GitHawk}

[royherma]

Sure makes sense, but I think it would be extremely valuable to offer an example of how the InputAccessoryView (and ios's .inputAccesoryView properties in general) can be leveraged to correctly adjust content offset and inset of scrollviews/tableviews/etc

I'll try to get a video up of laggyness - could be just the simulator but i'll also check on a real device.

[nathantannar4]

@royherma have you looked at the example source code? I do show this. https://github.com/nathantannar4/InputBarAccessoryView/blob/master/Example/Example/CommonTableViewController.swift

_{Sent with GitHawk}

[royherma]

I've tried all examples - none of them adjust the content offset of the tableview to display the correct row when the keyboard appears (as in Messenger, WhatsApp).

Hopefully you understand the functionality I'm talking about, but if not let me know and I'll send video.

[nathantannar4]

What do you mean by "correct row"? Adjusting the bottom inset **will not ** scroll the scrollview. That's fundamentally how it works in UIKit. You just need to add some logic to scroll to the row you want.

_{Sent with GitHawk}

[nathantannar4]

Still need help @royherma ?

_{Sent with GitHawk}

[royherma]

Thanks for the responsiveness @nathantannar4, I ended up figuring it out on my end. I think this is relatively desired functionality to work alongside accessory input views in this day and age (for chat/message UIs). Would you like me to add an example and make a PR?

[nathantannar4]

@royherma I still don't understand the issue your having as you left out key details. You can make a PR so I can see. I don't understand if your citing a problem with the library or just the demo example.

_{Sent with GitHawk}

[royherma]

The animation lag seems like a problem, but the functionality I was talking about is more about the demo. I'll close (you can delete this if you'd like) and add the functionality in the PR I create.

[nathantannar4]

I asked earlier @royherma where does it lag? Are you sure you are not using the subview version? I would be happy to help but your comments have been very vague with no instructions on how to reproduce.

_{Sent with GitHawk}

[Jarred-Sumner]

I'm running into a similar issue that I've been trying to debug for the past five hours or so. I'm pretty confident that its my fault (2nd day using Swift!) though, not the library

The two issues are related but not precisely the same:

• When InputBarAccessoryView becomes first responder / focused, the scroll view should scroll to the bottom. When you tap the text input on iMessage or Messenger, it scrolls to the bottom of the chat. The scroll view doesn't stay in the same position (unless it was already at the bottom). I don't think it's plausible that the library does this automatically – but it would be great if there was an example that did it.
• The top and bottom of the scroll view is the height of the screen, ignoring the safe area and the dimensions of the InputAccessoryView. This is after the layout constraints from the examples are set (with code nearly identical).

It seems that contentInsetAdjustmentBehavior isn't working as advertised when inside of a UIViewController. Activating the NSLayoutConstraints from the examples leaves additional space where the safe area is at the top (where the status bar is) and the bottom, ignoring the height of the InputBarAccessoryView.

The solution to this, I think, is manually setting the content inset. The other solution is using KeyboardManager instead of canBecomeFirstResponder, however that results in the lag that @royherna hinted at

Edit: The solution I ended up going with was copy-pasting MessagesViewController and editing it a bit

[lm2s]

@royherma did you ever discovered the animation lag reason while using KeyboardManager? I'm experiencing that now and can't pin-point the cause. It's more confusing that if I send the app to background and foreground while the keyboard is open, for a moment the lag stops but as soon as I try to drag again after releasing the lag comes back.