Adds an optional configuration property for a background color that appears behind the keyboard

[nateansel]

This PR adds a configuration property to SheetConfiguration that allows a developer to setup a background color that appears behind the keyboard when the sheet is presented in the .fittingSize style and the keyboard is present. This prevents the view behind the SheetView from peeking through when dismissing the keyboard. See the screenshots below to see an example of both using and not using this new property and dismissing the keyboard.

The new example titled "Keyboard - Interactive Dismiss" uses this new feature.

[paulhimes]

Not loving the use of the word "shim" for this. Makes me think of this: https://en.wikipedia.org/wiki/Shim_(computing)

[nateansel]

Oof! Good catch, I should change that to "keyboard background".

[mattczech]

Thanks for the contribution, Nathan! I'm curious what you think about trying to pin the bottom of the sheet to the keyboard as it is being interactively dismissed. So as you drag down on the keyboard, a fitting sized sheet would slide down in unison with the keyboard (similar to when the keyboard is dismissed non-interactively). The Messages app behaves similarly with the text view for composing a message. I think this would prevent your presenting view from peeking through as well. I'm happy to chat through this approach if you're interested.

[nateansel]

@mattczech You're right, that would be a much better solution for this problem and would look super slick! I've been looking into getting that set up with Duvet, but I'm stuck trying to get a view to follow the keyboard as it is dragged interactively. Do you have any pointers to help me get started with this solution?

[mattczech]

@nateansel As far as I know, iOS doesn't give us a great way to handle getting the keyboard's frame as it's being interactively dismissed. But I've had luck in the past by setting a custom (empty) view as the view's inputAccessoryView. Typically this is used to show a custom control above the keyboard. Since this view is shown with the keyboard, it ends up being a subview of the keyboard, so you can use KVO to observe the keyboard's frame 😬 🤷‍♂️.

/// A view that listens for changes to its superview's center property and publishes the superview's
/// frame via an optional closure.
///
class KeyboardFrameDetector: UIView {

    /// An optional closure that is called when this view's superview's center changes with the
    /// superview's frame.
    var keyboardFrameChanged: ((CGRect) -> Void)?

    /// A token by which we can cancel our KVO observation.
    var token: NSKeyValueObservation?

    override func willMove(toSuperview newSuperview: UIView?) {
        if newSuperview == nil {
            token?.invalidate()
            token = nil
        }
    }

    override func didMoveToSuperview() {
        token = superview?.observe(\UIView.center) { [weak self] (view, _) in
            self?.keyboardFrameChanged?(view.frame)
        }
    }
}

If you add that as SheetView/SheetViewController's inputAccessoryView, you should get callbacks on that closure with the keyboard's frame. And then you should be able to adjust the sheet's constraints to account for it.

One concern with this approach being in a framework is that I'm not sure how it would affect a view that was shown in a sheet with a custom input accessory view (or if this approach would break if you had an input accessory view 🤔). But maybe this is a fair tradeoff for now.