SlackTextViewController: A new growing text input for iOS | Hacker News Reader

SlackTextViewController: A new growing text input for iOS

github.com

200 pointsbradya34 comments

We tried other popular text input projects for iOS, but none felt right and worked fully for our needs. We ended up spending a big portion of our time maintaining custom versions of other projects.

For that reason, we decided to build our own growing text input from scratch, and we've just released it as open source. We hope you all will find it useful!

Looks really great. Have you thought about submitting to CocoaControls? (https://www.cocoacontrols.com/) It's the second place that I look for iOS components (after a simple Google search, that is).

Thanks! We submitted and it should be up on their site soon. (Pretty sure they are still reviewing it)

Just did :)

thanks a lot @aaronbrethorst!

Thanks, Liyan :) I'm happy to hear it's useful for you!

> Inverted mode for displaying cells upside-down (using CATransform) -- a necessary hack for some messaging apps (including ours)

Care to elaborate? Sounds intriguingly crufty.

UITableView lays out cells from the top. If there aren't enough cells to fill the screen, there will be an empty area in the bottom part of the table view, between the last cell and the bottom of the table view (as you would expect).

Unfortunately, there isn't a standard way to invert a UITableView, and have cells laid out from the bottom.

So, the easiest solution for us was to set the table's transform to CGAffineTransformMake(1, 0, 0, -1, 0, 0) (flip the whole table upside down) and then give the cells the same transform (to cancel out the table view's transform).

A bit hacky, and causes indexPaths to be inverted as well (0,0 is now at the bottom), but worked for us.

Seen a few other people take this approach as well: https://twitter.com/tapbot_paul/status/461161920402563072

That's a pretty interesting approach. Wouldn't it be cleaner to use a UICollectionView with a custom layout?

Most definitely! UICollectionViewLayout should be the right answer, but the thing is: the Slack iOS app was already built using UITableView, drawing many many custom cells. We'll probably port someday to UICollectionView ;)

I've started experimenting not making cells but UIViews and just add them on top of cells. I haven't gone with that fully yet but I've planned to try it out.

The downside is you lose out on many of the out of the box stuff, like cell background highlights that you know have to define yourself.

The upside is that you can now reuse the UIView everywhere, including non-subclasses of ScrollView.

You should add your view to the cell's contentView instead of directly on the cell, which allows you to keep the default behaviors and also reuse the view.

We do the same thing, custom views, mostly drawn in -drawRect:, reused in different cells. It's actually a very nice technique but like you said, the are some sacrifices to take. Still, these cells depend of a tableViewcCell which has unique properties and special APIs that collectionViewCells don't. I think the most trikcy part here is to be able to build a custom UICollectionViewLayout allowing to display cells from the bottom. Haven't found any third-party doing it well enough yet. Do you know of any?

As someone that doesn't do iOS development it boggles my mind that you guys have to build this feature into your apps.

I'm with you. I don't do iOS development at all, but I will literally sit there and go through the entire code of every iOS control submission to Hacker News just to see how they accomplish what they do. I cannot believe how much code it takes to do something I feel you can accomplish easily in javascript.

Kudos to all the iOS developers out there. I don't know how you guys manage to do it, but I'm sure glad you do and are willing to share your code with the rest of us.

That's not really a fair comparison. JavaScript backs onto a browser that already implements a vast amount of rendering.

If we had a similar iOS control, we could do it really simply too.

I've been on the both sides of the fence: writing native iOS apps and trying to do mobile web iOS apps. From the bottom of my heart: writing native apps is far more enjoyable and productive at the moment.

With the browser engine underneath, you get nice benefits in text layouting, image handling and some inputs, but it requires a lot of work to get good performance, to get touch interaction and scrolling feel natural, to make transition animations to work well. Offline access is also PITA if you have a lot of data - indexedDB crashes left and right if not used carefully. The last 20% of the app takes 800% of the time :) and the result is still not what you wanted.

I haven't encountered many good mobile web apps. HN app by @premii is pretty good (http://hn.premii.com/), and the developer once described here in HN that he didn't use any JS library like jQuery for performance reasons, everything had to be coded manually.

Autoresizing text areas aren't supported by browsers either, you have to use Javascript to implement it. http://stackoverflow.com/questions/454202/creating-a-textare...

Indeed, on android this comes out of the box.

So I'm making iOS apps sometimes, but have not implemented a chat feature.

Why would I want to use this rather than a UITableView where I append the newest message in the end of the UITableView every time (you'd have to increase it's length +1 for each new message, but hey that may be ok)?

This implements the input box, not the rest of it. Apparently, an automatically (vertically) expanding input box does not exist for iOS in the standard libraries for it.

Apple developed Swift to make developer's more expressive and efficient yet they do not provide simple controls like this. Can't tell you how many hours I wasted in the chat portion of my app trying to get a simple growing text input to work!

Try this out and let us know what you think. It's been designed in a way where you shouldn't care about the growing text input and trivial features related to it, but to build your tableView/collectionView cells and content.

cool. I was just shopping for a new growing text view since HPGrowingTextView seemed like it was not maintained and buggy on IOS 8.

I settled on https://github.com/oseparovic/MessageComposerView.

It's nice, simple, and does the trick. However, I will definitely checkout SlackTExtViewController.

For people not in IOS development: yes this is crazy that it is not built in. But our tool chain is better :)

Wow. 192 commits. ~1.5 months of work. For a UITextInputField. This pod was made with love.

Atomic commits yo! But yes, it was built with much love and attention to details.

Agreed! Where I work, GitHub graphs make it look like I'm doing 5 times more work than everyone else. But I'm really just pushing commits more often.

I believe that atomic commits makes things easier later, if you need to roll back, stash, or branch out. It's just hard to keep the habit going and not become lazy :)

Since January I've been insisting that we make atomic commits, but now I'm looking to switching to squashing them into one before merging. This makes it a lot easier to roll back a whole feature and not half way through it.

Plus, our graphs look ridiculous, I'm easily 5-10 times over the others, but it's not that I'm doing more work, I just commit more often.

We're using atomic commits since 2009 when we moved to git. However: we very often merge features with --no-ff to make it way easier to back them out at once if needed.

That way you get the best of both worlds (very easy archeology and very easy backing out of features)

I think atomic commits can either bump or decrease your commit frequency.

If you had a giant piece of logic that wouldn't be atomic in multiple commits, but you have multiple commits on your machine for the sake of saving your butt in case you roll down a weird rabbit hole, then you'd probably squash before merging into master and end up decreasing your total quantity of commits.

If you had a lot of small changes that all were safe seperately, you might break up what could have been a single commit into several commits so that you have a more descriptive history, and increasing your quantity of commits.

If this works well, then it's enormously useful. I spent way too many hours trying to get the existing solutions to work, without success. (In the end, I had to implement the view in HTML and JavaScript!)

Will this work for just the input component with a separate table view controller? That'd make it much more useful for non-messaging apps also.

By subclassing SlackTextViewController, you'll get a tableView or collectionView, and a toolbar at the bottom containing the growing text input. That's basically it. You may decide later to override some methods for disabling or enabling more features.

Reply on news.ycombinator.com