Hacker News Reader

Comment by tejaswiy | Hacker News Reader

I see where this is coming from, but loosing the convinience of xibs + auto layout is too great to sacrifice for me. Just thinking of how much bigger my view controller code will get makes me shudder.

View on HN

Your view code shouldn't go into your view controllers, it should go into your views. This is a mistake that is very common among iOS engineers. Anything dealing with subviews, layouts, touches, etc should go into subclasses of UIView; view controllers should handle touches (delegation!), interact with the navigation controller, and act as a bridge between your views and the rest of your application code.

I'm an iOS developer and I generally do what you suggest here. I create a bunch of subclasses of UIView and do my positioning via layoutSubviews, implement sizeThatFits when appropriate, etc.

Despite this I feel like Apple makes it very difficult to keep all UI code out of your view controllers. I'd go as far to say they actively encourage shoving UI code into your UIViewControllers. Take a look at the interface for UIViewController -- it is almost all view/presentation related [0]. Most of Apple's sample code and projects have view code sprinkled all over their UIViewControllers.

I feel like it is a constant fight to keep proper view/controller separation on the iOS platform.

[0] http://doing-it-wrong.mikeweller.com/

most of apples sample code is pretty poor design for large projects, the biggest example I think is core data stack in the app delegate

But why make UIView subclasses when you don't have to? If I'm just using a tableview, and I need to lay that out, I'm not going to subclass UITableView. I'm just going to add one to my controller or use UITableViewController. If you're already making subclasses of UIView, then yes, do the layout code there, but for many applications this isn't necessary, and there's no where else to put that code.

Specifically UITableView is a bad example here, because UITableView relies heavily on the `UITableViewDelegate` and `UITableViewDataSource`.

For that, though, you should make a separate class for the TableViewModel, to keep that code out of your ViewControllers.

Well, maybe. UITableViewDelegate and UITableViewDataSource don't have anything to do with the layout of that tableview. But let's say I have a bunch of labels, or textfields, or buttons or imageViews. All of those stock classes will do a pretty good job without subclassing, and for many applications, there's no need to subclass them. If you're doing your layout in code, where else does the layout code go other than the Viewcontroller that manages all those objects.

Except UIViewController has a view property that is usually a container for a lot of other views. Sometimes it's desirable to add constraints to this view. Apple even provides API for this: UIViewController's updateViewConstraints method. I think of this as a compromise so we don't have to create a custom UIView subclass for every UIViewController subclass.

Reply on news.ycombinator.com