Skip to content

v0.1.2 — Automatic keyboard avoidance

Choose a tag to compare

View all tags
@Sajjon Sajjon released this 03 May 18:36
· 43 commits to main since this release
v0.1.2
89a884e
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Patch release adding automatic keyboard avoidance for every scene built on `AbstractSceneView` / `BaseScrollableStackViewOwner`.

What was broken

Default `setupScrollViewConstraints()` previously pinned the scroll view's bottom to `self.bottomAnchor`. When the on-screen keyboard appeared, the scroll view stayed full-height and the keyboard covered the lower portion of the form — including primary CTAs (e.g. the "Continue" button on a sign-up / set-password screen). The user had no way to scroll to reveal the covered content.

The fix

The default scroll-view bottom now pins to `keyboardLayoutGuide.topAnchor`, with `keyboardLayoutGuide.usesBottomSafeArea = false` set in `setupAbstractSceneView()`:

  • No keyboard on screen → the guide's top sits at `self.bottomAnchor` (under the home indicator). Resting layout is identical to the previous `self.bottomAnchor` pin — non-text-input scenes are unaffected.
  • Keyboard appears → the guide's top sits at the keyboard's top edge; the scroll view shrinks; existing `contentLayoutGuide` / `frameLayoutGuide` machinery handles the reflow so the focused field stays visible and the rest of the form is reachable by scrolling.

`BaseScrollableStackViewOwner`'s content-view bottom anchor is split per mode to keep the auto-applied content-inset coherent:

  • `PullToRefreshCapable` scenes pin the content view to `safeAreaLayoutGuide.bottomAnchor`. Those scenes use `contentInsetAdjustmentBehavior = .always`, which auto-adds a safe-area bottom inset; pinning here keeps the inset and content-end aligned (no blank scrollable strip) and lets the refresh spinner clear the home indicator when pulled.
  • Other scenes pin the content view to `keyboardLayoutGuide.topAnchor` (= `self.bottomAnchor` at rest).

What you don't have to do

  • No `NotificationCenter.default.addObserver(forName: UIResponder.keyboardWillShow…)` boilerplate.
  • No `IQKeyboardManager`-style global swizzling.
  • No `viewWillAppear` / `viewWillDisappear` keyboard registration dance.

Subclasses overriding `setupScrollViewConstraints()`

If you override the default constraint setup, propagate the change:

```swift
override func setupScrollViewConstraints() {
NSLayoutConstraint.activate([
scrollView.leadingAnchor.constraint(equalTo: leadingAnchor),
scrollView.trailingAnchor.constraint(equalTo: trailingAnchor),
scrollView.topAnchor.constraint(equalTo: topAnchor, constant: 60), // sticky header
scrollView.bottomAnchor.constraint(equalTo: keyboardLayoutGuide.topAnchor), // ← was: bottomAnchor
])
}
```

Migration from 0.1.1

Trivial. No source-breaking changes. Existing scenes get keyboard avoidance for free; full-bleed-under-home-indicator layouts still work as before. Bump the pin:

```swift
.package(url: "https://github.com/Sajjon/NanoViewController.git", exact: "0.1.2")
```

Full changelog: v0.1.1...v0.1.2

Assets 2
Loading