Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added Input Accessory View Support #16

Merged
merged 9 commits into from Jan 13, 2018
Merged

Added Input Accessory View Support #16

merged 9 commits into from Jan 13, 2018

Conversation

efremidze
Copy link
Contributor

@efremidze efremidze commented Dec 12, 2017

Added input accessory view support (#15) by adding a scrollView property to track panning. You also need to set the inputAccessoryView on the textField.

Observes the input accessory view through the willChangeFrame and didChangeFrame observer.

Demo has been updated to reflect the changes.

// keyboard input accessory view support
textField.inputAccessoryView = UIView(frame: toolbar.bounds)
keyboard.scrollView = tableView

// keyboard frame observer
keyboard.on(event: .willChangeFrame) { [unowned self] options in
    let height = UIScreen.main.bounds.height - options.endFrame.origin.y
    self.bottom.constant = max(0, height - self.toolbar.bounds.height)
    UIView.animate(withDuration: 0) {
        self.tableView.contentInset.bottom = max(self.toolbar.bounds.height, height)
        self.tableView.scrollIndicatorInsets.bottom = max(self.toolbar.bounds.height, height)
        self.view.layoutIfNeeded()
    }
}.start()

Im also considering an alternative implementation like BABFrameObservingInputAccessoryView.

Copy link
Owner

@totocaster totocaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of ideas on how to minimize boilerplate on developer's side.

@@ -16,7 +16,7 @@ class ViewController: UIViewController {
didSet {
tableView.tableHeaderView = UIView()
tableView.tableFooterView = UIView()
tableView.keyboardDismissMode = .interactive // allow dismissing keyboard interactively
tableView.keyboardDismissMode = .interactive // allows dismissing keyboard interactively
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be assigned on in didSet of keyboard's scrollView, this keeping boilerplate a bit more lean on developer's part. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

keyboard.on(event: .willChangeFrame) { [unowned self] options in
let height = UIScreen.main.bounds.height - options.endFrame.origin.y
self.bottom.constant = max(0, height - self.toolbar.bounds.height)
// UIView.animate(withDuration: options.animationDuration, delay: 0, options: UIViewAnimationOptions(curve: options.animationCurve), animations: {
UIView.animate(withDuration: 0) {
self.tableView.contentInset.bottom = max(self.toolbar.bounds.height, height)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could include all of those recalculated values in options if possible? Another idea—pass toolbar configuration to keyboard and options will provide all the geometry pre-recalculated as CGRect?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main issue revolves around the toolbar height being included in the keyboard height. We need to figure out how to make this easier to handle.

@totocaster
Copy link
Owner

totocaster commented Dec 20, 2017

Another one, say we have new configuration method called toolbar(...) with all the parameters it needs to make keyboard configure itself for interactive dismissal. For example:

keyboard
    .toolbar(scrollView: self.tableView)
    .on(event: ...)
    .start()

Not sure about the name of the toolbar(...) method, but hopefully gets the point across.

@totocaster
Copy link
Owner

@efremidze Will you experiment with toolbar(...) idea? I'll experiment myself as-well and report back here.

@efremidze
Copy link
Contributor Author

Yes Ill look into it tomorrow

@totocaster
Copy link
Owner

Can you PR this to different feature/... branch? I want to work on that too. Thanks!

@efremidze efremidze changed the base branch from master to feature/interactive January 13, 2018 02:24
@totocaster totocaster merged commit 7c9a41a into totocaster:feature/interactive Jan 13, 2018
@totocaster
Copy link
Owner

Awesome, thanks! Let's carry on on this branch and I'll merge it with master when all is neat and tidy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants