jsqmessageviewcontroller ios11 toolbar

问题:

I have tried the swift example of JSQMessageViewController inside iOS 11 simulator. Here is the result:screenshot

I have tried using safe area margin and modify the toolbar constraint but there is still no difference. It seems that the toolbar is outside UIWindow (UITextEffectsWindow instead). Is there any solution?

回答1:

Just add an extension for JSQMessagesInputToolbar

extension JSQMessagesInputToolbar {
    override open func didMoveToWindow() {
        super.didMoveToWindow()
        if #available(iOS 11.0, *), let window = self.window {
            let anchor = window.safeAreaLayoutGuide.bottomAnchor
            bottomAnchor.constraintLessThanOrEqualToSystemSpacingBelow(anchor, multiplier: 1.0).isActive = true
        }
    }
}

回答2:

Guys I have figured it out! Just put the following code in the JSQMessagesInputToolbar.m. It seems that the inputtoolbar is placed in its own window, you need to access its window separately.

-(void) didMoveToWindow{
[super didMoveToWindow];
 if (@available(iOS 11.0, *)) {
     [[self bottomAnchor] constraintLessThanOrEqualToSystemSpacingBelowAnchor:self.window.safeAreaLayoutGuide.bottomAnchor multiplier:1.0].active = YES;
     }
}

回答3:

This answer is based on JSQMessagesViewController version 7.3.

Note: The code below contains some messy pragma directives to avoid compiler warnings. The code itself is actually quite simple once you see beyond the pragmas.

This seems to solve the problem while still allowing the toolbar to be moved when the software keyboard is presented. I added the following code in my JSQMessagesViewController subclass:

- (void)viewDidLoad {
    [...]

    // To keep the toolbar inside the safe area on iPhone X, we need to install a new constraint that has higher priority than the one
    // JSQMessagesViewController manipulates when adjusting for the keyboard. The `toolbarBottomLayoutGuide` is a private property in our
    // superclass, so it's not straightforward to access it...
    if (@available(iOS 11.0, *)) {
    #pragma clang diagnostic push
    #pragma clang diagnostic ignored "-Wundeclared-selector"
        NSLayoutConstraint *constraint = [self performSelector:@selector(toolbarBottomLayoutGuide)];
    #pragma clang diagnostic pop
        constraint.priority = 999;
        [self.inputToolbar.bottomAnchor constraintLessThanOrEqualToAnchor:self.view.safeAreaLayoutGuide.bottomAnchor].active = YES;
}

Edit: For Swift users, the following trick should let you call the private objc method:

let constraint = perform(Selector(("toolbarBottomLayoutGuide"))).takeUnretainedValue() as! NSLayoutConstraint
constraint.priority = 999

Edit: The code that adjusts the contentInset of the collectionView is not called after this new constraint is added, so if the chat view contains more messages than fits the screen, the last message bubble is obscured by the input toolbar. I solved this by ensuring the insets are updated by adding the following code in viewDidAppear viewDidLayoutSubviews:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
[self performSelector:@selector(jsq_updateCollectionViewInsets)];
#pragma clang diagnostic pop

回答4:

Found a solution without empty space below input toolbar on iPhoneX, the idea that not the whole toolbar self should be above the safe area, but only its self.contentView:

-(void) didMoveToWindow{
    [super didMoveToWindow];
    if (@available(iOS 11.0, *)) {
        if (self.window.safeAreaLayoutGuide != nil) {
            [[self.contentView bottomAnchor] constraintLessThanOrEqualToSystemSpacingBelowAnchor:self.window.safeAreaLayoutGuide.bottomAnchor multiplier:1.0].active = YES;
        }
    }
}

回答5:

I m having same problem. I m trying to solve it by adding the JSQMessageViewController as a child view on a viewController that has safe area set up.

Being MyJSQMessageViewController a subclass of JSQMessagesViewController:

self.myJSQMessageViewController = [[MyJSQMessageViewController alloc] init];
[self addChildViewController:self.myJSQMessageViewController];
[self.view addSubview:self.myJSQMessageViewController.view];
[self.myJSQMessageViewController didMoveToParentViewController:self];
if (@available(iOS 11.0, *)) {
    self.myJSQMessageViewController.view.translatesAutoresizingMaskIntoConstraints = NO;
    [NSLayoutConstraint activateConstraints:@[ [self.myJSQMessageViewController.view.leadingAnchor constraintEqualToAnchor:self.view.safeAreaLayoutGuide.leadingAnchor], [self.myJSQMessageViewController.view.trailingAnchor constraintEqualToAnchor:self.view.safeAreaLayoutGuide.trailingAnchor], [self.myJSQMessageViewController.view.topAnchor constraintEqualToAnchor:self.view.safeAreaLayoutGuide.topAnchor], [self.myJSQMessageViewController.view.bottomAnchor constraintEqualToAnchor:self.view.safeAreaLayoutGuide.bottomAnchor] ]];
}

Not ideal solution but at least you will have input toolbar inside iOS11 safe area... Bad news is that input toolbar wont be displayed on non safe areas so graphically wont be like a default toolbar (see image)

回答6:

I am proposing a fixed fork based on the JSQ latest develop branch commit.

It is using the didMoveToWindow solution. Not ideal but worth to try while waiting for Apple's answer about inputAccessoryView's safe area layout guide attachment, or any other better fix.

You can add this to your Podfile, replacing the previous JSQ line:

pod 'JSQMessagesViewController', :git => 'https://github.com/Tulleb/JSQMessagesViewController.git', :branch => 'develop', :inhibit_warnings => true