Messagekit: How to keep the inputBar inside the DetailViewController for iPad layout's SplitViewController

[erichsu]

General Information

• MessageKit Version:
  0.12.1

• iOS Version(s):
  iOS 10 and above

• Swift Version:
  Swift 4

• Devices/Simulators:
  Simulator iPad Pro

• Reproducible in ChatExample? (Yes/No):
  No

What happened?

I am trying to implement iPad's layout as iMessage App, but I am getting the InputBar cross to the whole window not just in DetailViewController at the right side, please refer to the attached screenshots.
Could I change the input bar frame or constraints to achieve that?

Example App

What did you expect to happen?

iMessage App

[nathantannar4]

This would be due to how iOS is handling the input accessory view. So done change any constraints as it won’t help. I would try subclassing the split view controller and make sure it can’t become the first responder, as you only want your messages view controller to be the first responder in order to show the MessageInputBar. Don’t have an exact answer at this time though

_{Sent with GitHawk}

[SD10]

We actually have a PR open for this. I would have to review the logic and make sure it doesn’t cause any regression on iPhone

_{Sent with GitHawk}

[brianb7590]

I have a similar request. Mine is a bit different because I have a TabBar across the bottom. On iPad, the MessageInputBar sits over the TabBar, so my users cannot click on to different tabs.

This is not a problem on iPhone since I hide the TabBar when the user enters the conversation view.

[erichsu]

297

[SD10]

Duplicate of #296 and has a PR open in #297

[tamastimar]

@SD10 @nathantannar4 have you ever thought about using MessageInputBar next to the collection view (e.g. via view controller containment) instead of being an input accessory view? Would that have any drawbacks or issues?

[nathantannar4]

If we force it within a UIViewController it becomes locked to that functionality. For instance I use the bars on screens that don't have a MessagesCollectionView. As an InputAccessoryView we can abstract it's functionality, putting less constraints on its applications.

I would also argue that as an InputAccessoryView it is held within the UIWindow and thus when the size changes we do not have to trigger layout updates on the UIViewController.

If you want to use it as a subview of a UIViewController it is possible you just need to add the constraints for it an manage them when the size changes. See my example for where MessageInputBar features are forked from https://github.com/nathantannar4/InputBarAccessoryView

Also see #929

_{Sent with GitHawk}