Responsibilities of a controller in MVC architecture - ios

Question

I have a current code base which I want to refactor.
The controller (or viewcontroller for people familiar with iOS) is around 2000 lines and doing lot of stuff.
Controller is responsible for :
1) Communicating between view and model
1.1) Handling callbacks / actions from view
1.2) Handling gestures.
1.3) Passing data from model to view.
2) Making web request if model is empty.
2.1) preparing URL and sending request to connection handler.
2.2) Parsing logic
3) Customizing UI
3.1) Minor UI modifications.
4) Business logic.
4.1) A little bit of code deals with business logic of calculation some reports.
I was thinking to delegate some responsibilities to Model and View.
Any thoughts on how to go about it?
Also, more specifically I want to know who is responsible for making web request model or controller ?

Answer 1

There are a couple of concepts that have been useful for me in writing easily maintained code:
In addition to the concrete model objects (e.g. if requesting weather information from a service, you might have a Weather class that represents a particular weather report, e.g., a city, a temperature, and narrative properties), I'll also employ a data controller object that coordinates the requesting of objects from either a cache, persistent storage, or from the web, as appropriate (often in that order). You want to be wary of relying solely upon simplistic requests of a web service, as caches and the like can be quite important when designing responsive UI.
The key point for me is that I rarely want either views or view controllers messing around with this level of detail (though, I confess, in trivial situations, I've done the requests directly from the controller). Ideally, the view controller will initiate an asynchronous request of my data controller, passing it a completion block with parameters of (a) the model object being retrieved; and (b) a NSError.
I'll include an example of what this might look like below.
As you might infer from above, I often also abstract the particulars of the initiation of the web requests and parsing of the responses into their own objects, themselves (because the data controller may be complicated enough, managing caches, persistent storage, etc.). I generally use a NSOperation subclass for request/parsing tasks (which lends itself to asynchronous requests with completion blocks; the ability to cancel pending requests if the UI moves on to something else, etc.). Thus, my data controller will, if it concludes that cached and/or persistent storage cannot satisfy the request, will initiate the asynchronous request/parse operation.
You list a couple of other responsibilities that you've assigned to your view controller, but might best be abstracted out, too:
1.2) Handling gestures - If a gesture gets a little complicated (e.g. horizontal only, swipe from edge, etc.), I'll actually subclass the gesture handler, greatly simplifying the view controller's own interaction with the gesture handler.
3) Customizing UI - If the UI requires much customization, I'll often subclass the appropriate view, too. Particularly with UITableViewCell and UICollectionViewCell, this can greatly simplify one's view controller code. And any views that require any material customization can often be done more gracefully in a subclass of the view itself.
Sample data controller abstraction
So, I might have a completion block defined like so:
typedef void(^WeatherRequestCompletion)(WeatherReport *weatherReport, NSError *error);
And then I might have a method in my data controller with an interface like so:
- (WeatherRequest *)requestWeatherWithIdentifier:(CityIdentifier)cityIdentifier completion:(WeatherRequestCompletion)completion;
And my view controller would use it like so:
typeof(self) __weak weakSelf = self;
self.weatherRequest = [[WeatherModel sharedController] requestWeatherWithIdentifier:self.cityIdentifier completion:^(WeatherReport *weatherReport, NSError *error) {
if (error) {
// handle error
}
if (weatherReport) {
weakSelf.cityLabel.text = weatherReport.city;
weakSelf.tempLabel.text = [weatherReport.temperature stringValue];
weakSelf.narrativeLabel.text = weatherReport.narrative;
}
}];
The view controller shouldn't be worried about how the request is formatted nor how the response is parsed (that's the job of my network request NSOperation subclass). Nor should the view controller even be too involved in the caching and/or persistent storage logic (that's the job of my data controller). The view controller should, thereby be distilled to something very logical and easy to follow.
Note, you'll notice that my data controller is returning a request object (which is, for me, frequently just a typedef to a NSOperation). I'll have my view controller maintain weak reference to this, so that I can easily cancel the request if and when needed, e.g. in the dealloc of the view controller):
- (void)dealloc
{
[_weatherRequest cancel];
}

Answer 2

Most of that seems to be typical ViewController behavior. Apple does have a nice document describing the MVC architecture in detail: http://developer.apple.com/library/ios/documentation/general/conceptual/devpedia-cocoacore/MVC.html
"When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects."
This indicates that it is appropriate for you model to handle network activity and updating. The only other thing you could change would be to put as much of the UI work as possible in the view.