According to the Model-View-Controller pattern, applied heavily in Cocoa Touch, UIViewControllers should always handle the logic behind how a concrete UIView in the scene behaves.
I am curious as to how Apple implements it's UITableView class while keeping in line with this philosophy. Especially since UITableView inherits from UIScrollView and UIView in turn.
When you add a UITableView to one of your classes, does it have a UIViewController handling the way it behaves in the background? I know that a UITableViewDelegate is in charge of telling the table how many rows it should have, etc. But what about it's inner workings?
I'm gonna take a wild shot here, because I'm not sure I really follow your question. When you add a UITableView, you HAVE to have a controller associated to it to control how it handles and renders. Either a UITableViewController or a UIViewController that implements UITableViewDelegate and UITableViewDatasource. If you don't there's no way you can control what it does.
Related
I have a UIViewController in my application that contains a UITableView. This tableView has a few different states for section 2. The rows in this section can vary by height, cell type and number of cells.
The way I used to handle this was one UIViewController with lots of different if-statements in the UITableViewDelegate and UITableViewDataSource. Now, after a while, this has given me quite a lengthy and complicated controller.
I thought about two possible routes to fix this. The first one would be different UITableViewDelegate and UITableViewDataSource classes, based on an if-statement. The other would be to load in a different UITableViewController for each of the possible states.
What do you guys think would be the cleanest solution? Or are there any other cleaner solutions?
Firstly create an extension for viewcontroller which confirms to tableView dataSource and delegate protocols.
To achieve this we can create a custom method in presenter class to handle all this code and call this method whenever required.
In my iOS app I have a view controller and a UITableView subclass on one of my views. Currently the UITableView manages it's own data (creating connections, and being the delegate which handles the callbacks).
I was wondering if this is best practice? Is it better to run this on the view controller and then pass the data into the table? Does this not matter at all?
Please explain the reasons in addition to answering my question.
Thanks!
It would be more standard to implement the delegate and dataSource methods in the ViewController.
It is quite unusual to subclass the UI*View classes, except to customise drawing. UITableViewCell is a bit of an exception to this rule.
If you find your ViewController getting a bit big you might think about implementing the delegate and dataSource in a separate class.
In addition to mcfedr's answer, views are things that interact with user and it is generally good to separate concepts (unless unavoidable). Also note that historic versions of ios (iirc) view controllers may load/unload views on demand, so any application logic in there may cease to exist.
In this scenario, I generally have only one class... The UIViewController instance that contains the following view hierarchy:
view -> myTableView
With this approach, my UIViewController will:
Have an IBOutlet to a UITableView (myTableView)
Implement methods of UITableViewDelegate
Implement methods of UITableViewDatasource
Set myTableVIew.delegate to self
Set myTableView.datasource to self
When the host UIViewController is the delegate and datasource of your UIViewContoller, all code can exist in one class. This keeps the code of your project tighter but does tightly couple your logic.
The alternative approach would be to subclass UITableView and implement UITableViewDelegate and UITableViewDatasource. This will be a desirable approach if:
You wanted to reuse the UITableView in multiple UIViewController
You wanted to encapsulate the UITableView logic from the UIViewController
Here is the thought process I use:
Am I going to reuse this UITableView and its logic?
Yes -> UIViewController class and UITableView subclass
No -> UIViewController class only
The best practice would depend on the number of programmers involved, the repeatability of the UITableView, coding patterns already established. This is often a matter of preference and I hope my answer shed some light on why you would go either way,
What all does UITableViewController get me that makes it actually useful? Is there any bonus is using it instead of just using a UIViewController for views with UITableViews in them? I ask because I want my views with UITableViews to inherit from a base view controller (which inherits from UIViewController). If I use a UITableViewController then having a base class for all my views becomes more difficult.
Not much. It provides some conveniences, but you never really need it; I often don't use it.
The main things, aside from the automatic setup when you create one in the storyboard, are the three properties tableView, clearsSelectionOnViewWillAppear, and refreshControl. But they don't do anything you can't do yourself.
Well I do think both Retro and matt's answer are correct, from personal experience it is much easier and less "hackY" to use UITableViewController with UIRefreshControl, then trying to get UIRefreshControl work with UIViewController with a UITableView.
Nothing more then the boilerplate code ready for setting the data source and connection to your tableView object, some getters and setter to make your life easy if you not want to put your effort to do the same thing which is available.
But in your case for SubClass its not fit to have UItableViewController
Maybe this is a silly question, but I've bumped into it a number of times during iOS Development.
Sometimes I'll develop a view component that I want to use on multiple screens, so I'll decide to subclass UIView and make it something I can use in multiple places.
Then, I start adding functionality to it. Maybe it needs to respond to an NSNotification, or it is supposed to respond to user touches.
At a certain point, I start wondering if I should really be making a UIViewController subclass, and add it to my UI as a child ViewController.
Is there any consensus on where to draw the line between adding some behaviors to a UIView, and when to create a full UIViewController?
I can't tell you about the consensus, but here's my opinion:
Subclass UIView only when...
You want to do custom drawing
You need to customize some behaviour of an already existing UIView subclass
You have special needs for layouting subviews. Most layouting can be done by UIViewController, though.
Maybe for special touch handling that you can't be done with gesture recognizers
Subclass UIViewController in all other cases. You almost always need a controller anyway, for writing glue code that ties together views and models, or for handling user interaction. Consequently, Apple has made it easy in UIKit to let controllers do all the work and to keep views as "stupid" as possible. For instance, it is very simple to nest controllers to create complex view hierarchies, without the need to have a single view subclass.
An indicator that subclassing UIView is not the first thing one should do is the section titled "Alternatives to Subclassing" in the UIView class reference. An indicator that subclassing UIViewController is the preferred thing to do is that there is no such section in the UIViewController class reference :-)
You should use a controller anytime that you need to handle or control data. Views are supposed to be as stupid as possible, not knowing what they are displaying but rather where. You can easily subclass and reuse ViewControllers. A good example, say you need to retrieve a string (or text) from the user throughout your app via a popover controller and a modal. Create a generic subclass of UIViewController that has a view with a textfield and a button. You can then use this view and it's controller in any capacity you need. Reusing it in the popover, modal or anywhere else (and generally passing the data back through delegation). Since you are dealing with data you should not being using a sole subclass of UIView.
From my experience I subclass UIViewControllers more often then UIViews. It is a little difficult for me to understand if you are solely talking about Containers or reuse of views in general application workflow. Either way though it should be the same.
I've used the embedded view controllers to load reusable table views from time to time. I've found that it's useful sometimes but not always. Communication between the two can be cumbersome, like if you want the embedded controller to communicate back up to the container. Delegation makes it easier but still cumbersome. It also limits you to iOS 6, if I remember right iOS 5 and lower don't support embedded controllers.
If it's just adding methods you can use a category to store some extra methods. I do that a lot on NSManagedObjects that I don't want to subclass and if I regenerate the NSManagedObject from the datamodel I don't lose the code in my categories. Gives me added functionality like calculated fields or conversion methods without having to subclass. If you don't need those methods for a particular instance just exclude the reference to the category.
Subclassing never is bad though IMO.
I have a MainViewController, and I want to add two UITableView's to it, each with different cells. But I don't want to clog up my MainViewController code by checking in the table delegate methods which table it is, and then acting on it. It gets too messy.
So I thought I would subclass UITableView and let it handle the cellForRow and other table methods by itself, and this way when I want to add a table to MainViewController, all I'd have to is
CustomTable *customTable = [[CustomTable alloc] init];
[self.view addSubview:customTable];
and all the delegate methods would be handled in that class, leaving my MainViewController clutter free.
Am I approaching this wrong? Should I be subclassing UITableViewController instead? What's the difference?
When to subclasss UITableView? Not now.
Create two classes, which are member variables of your view controller. Point the table view delegates at each of your two new classes.
In Cocoa you tend to combine classes rather than inherit from them as you usually do in Java and C#.
In 3 years of professional working as a objective-c programmer, I didn't need to subclass UITableView once, the patterns, cocoa is depending on, — MVC and delegations (with using protocols), are just simple yet strong enough. And populating a tableview is just one of the best examples.
Make sure, you understand all this topics, as otherwise you will find yourself fighting the framework constantly.