

Implementing a Sticky Input Field in iOS - ayrkm
https://medium.com/@meiwin/a-stickler-for-details-implementing-sticky-input-fields-in-ios-f88553d36dab

======
jtreanor
Interesting work, thanks for sharing.

    
    
      The input field is subview of the keyboard’s window. This is likely undesirable, especially for chat applications.
    

I am curious as to why this is undesirable. It makes sense to me that
something docked to the keyboard would be in the same window.

~~~
ayrkm
It's because the input field will always appear at window level above the
level of key window. So, if you need to show overlay in key window, the input
field will appear above the overlay. Example for such overlay could be a
loading indicator.

------
tasteup
I love this. I've actually been using
[https://github.com/AlexLittlejohn/ALTextInputBar](https://github.com/AlexLittlejohn/ALTextInputBar),
but this is a well written explanation and solution to the problem.

~~~
ayrkm
Thanks, glad you find it useful.

------
aaronbrethorst
Or you can use Slack's open sourced version:
[https://github.com/slackhq/slacktextviewcontroller](https://github.com/slackhq/slacktextviewcontroller)

~~~
ayrkm
hi Aaron, I did briefly look at SlackTextViewController. But decided not to
use it because the project contains many features that we do not need.
Furthermore, it doesn't support usage on iPad.

------
sandofsky
There's no mention in the article that since iOS 7, there's been a
"UIScrollViewKeyboardDismissMode", which allows "interactive" dismissal. It
isn't perfect, but the last time I investigated, too many solutions out there
involved touching private APIs.

~~~
ayrkm
I could've more explicit.

Interactive dismissal only made possible with
UIScrollViewKeyboardDismissModeInteractive introduced since iOS 7.

This article described solution for interactive dismissal with `sticky` input
field atop the keyboard.

~~~
sandofsky
In 2015, most apps shouldn't support anything below iOS 7.

Create a constraint that attaches the input field to the bottom of the
scrollview.

One tradeoff is that dismissal doesn't start until your touch enters the real
keyboard area. I'll take it, since it's safer than using KVO to observe
private APIs.

~~~
ayrkm
Hi sandofsky, that was our previous implementation (dismissal starts only when
user's touch enters the real keyboard area) - it doesn't feel 'right'.

The library is not really using KVO to observe private APIs, bounds/center of
UIView is public property.

~~~
sandofsky
You're observing the superview in a hierarchy you don't own. In your code, you
have an iOS version check, presumably since the property you're looking for
changed between iOS versions.

~~~
ayrkm
yes, that I agree, it may break between iOS versions. i'm all ear to other
approach if any

~~~
sandofsky
You file a ticket with Apple and stick with documented APIs.

~~~
ayrkm
will do and hope Apple may do something about that.

until then, will stick to current solution and test ahead of any new iOS
release.

~~~
sandofsky
You've decided on the path of higher maintenance, and you've increased the
risk of Apple rejection.

Maybe this decision won't bite you, but this mentality will.

~~~
ayrkm
i keep my options open until I find a better solution.

i'm assuming engineers that build FB messenger, WhatsApp, Twitter etc. could
be using similar approach, but I am more than happy to be proven wrong.

------
andkon
This is such a great writeup, thank you for digging into it. Have you tried
this out with iOS 9? I know JSQMessagesVC, which does a really solid
interactive dismissal, has some problems with that.

~~~
ayrkm
Hi, it works in iOS 9. The Pie for iPad screenshot in the post is running in
iOS 9.

