Need help to understand MVC better in Objective C

Question

I'm actually kind of new in Objective C. I'm doing some projects in Objective C for only 4 months now. And I've tried to implement MVC in my projects as best as I can, although it's probably quite shabby.

So basically what I've learned so far is (to put it in simpler terms): Model : data & logic. View: graphical output. Controller: input and updating model / view. CMIIW. So basically controller is the middleman that just delivers the inputs for the logic inside the models and then receive the output of the model to be translated into a graphical representation in the view, correct? And the information will be carried over into one another with the use of delegates, right?

So if there were this case study:

I have a controller which have a view (which will be created automatically from the storyboard) and lots of subviews in it. Let's call these subviews (and their models) A, B, and C.

So I will have these classes:

A_Model, B_Model, A_View, B_View, and a ViewController

And these delegates:

A_ModelDelegates, B_ModelDelegates, A_ViewDelegates, B_ViewDelegates, which all should be put into the ViewController class.

And, say, if there's a UITextView and UIButton in A_View, and a UITableView and UIImageView in B_View.

The flow of the application would go like this: The textView from the A_View object will get the input and and in there's an IBAction method for calling one of the delegates in A_ModelDelegates to send the input data back to the ViewController object. Which in turn will send the data to the A_Model object and process it. The model will then send it back to the controller to be sent to update the A_View object, and B_Model object as the input for the parameters of the tableView and imageView in B_View. Now the tableView is serialized from the net using AFNetworking library. So B_Model will get the data as a NSDictionary object and send it back to the controller via its delegate. And the controller will use it to populate and update the tableView in the B_View object.

Now my questions are:

1. Is this way of thinking for MVC is correct?

2. Is the controller's main job only as a container for the instances of models, views, and a (possibly very large collection of) their respective delegates. And it will only pass around data between them?

3. If we are using AFNetworking to get the data form the net in the B_Model object, there should be a success and failure blocks in it, right? And in the failure block, if we want to raise an alert dialog box, AFAIK we've got 2 different ways to do it, using UIAlertView in iOS 7 and UIAlertController in iOS 8. Where should we put it? The model? The controller? Or the view?
4. I was under the impression that it should be put inside the controller because with the UIAlertControllerthere's this line: [self presentViewController:alert animated:YES completion:nil]; Is this correct? So must I also put the UIAlertViewDelegate in the container and execute them from inside the model when needed (eg. in the failure box when the model failed to get the data form the net) via the model's delegate? What if there are many alert views?
5. And for the serialization of the tableView, where should I put the data source and delegates? The controller or the view? The model shouldn't know about the view so the data source and delegate shouldn't be put there, correct? If we want to put it in the controller, what if there were lots of tableviews that would be put into a different subviews? And if there were lots of table views, the data source and delegate methods would be quite big because all of the input / output of every table views would have to be put there.
6. Still in accordance to the question above. Is my way of serializing it correct? The model gets the data from the net and make them into a dictionary which will be passed to the controller via its delegate. And then the dictionary will be used to populate the table views.

Thanks in advance.

Answer 1

I'm not sure, if I understood your Q correct in all ways. Maybe the A will change after comments.

Is this way of thinking for MVC is correct?

Basically, but look to the rest of the answer.

Is the controller's main job only as a container for the instances of models, views, and a (possibly very large collection of) their respective delegates. And it will only pass around data between them?

No, it is more than the glue for data flow. It is additionally the glue for the control flow. I think that there you have a misunderstanding:

Even it is sexy to have logic inside the model, it is a dangerous think. Doing so you make your model more concrete to the application. Look at the model as a data collection only, having "code" only for its own consistency. Even the MVC is a common pattern, this does not mean that you have to fit to it all the time.

If we are using AFNetworking to get the data form the net in the B_Model object, there should be a success and failure blocks in it, right? And in the failure block, if we want to raise an alert dialog box, AFAIK we've got 2 different ways to do it, using UIAlertView in iOS 7 and UIAlertController in iOS 8. Where should we put it? The model? The controller? Or the view?

I was under the impression that it should be put inside the controller because with the UIAlertControllerthere's this line: [self presentViewController:alert animated:YES completion:nil]; Is this correct? So must I also put the UIAlertViewDelegate in the container and execute them from inside the model when needed (eg. in the failure box when the model failed to get the data form the net) via the model's delegate? What if there are many alert views?

You should put the code for getting data into the controller layer, not into the model layer. This is more than collecting data, because there can be errors that changes the control flow.

And for the serialization of the tableView, where should I put the data source and delegates? You do not serialize views. You serialize the model that is displayed using the table view (or another view, if you selected one item, or … You have typically one model and several views to display parts of it.)

The serialization is started from the controller layer. It handles picking-up the data, errors …

The controller or the view? The model shouldn't know about the view so the data source and delegate shouldn't be put there, correct? If we want to put it in the controller, what if there were lots of tableviews that would be put into a different subviews? And if there were lots of table views, the data source and delegate methods would be quite big because all of the input / output of every table views would have to be put there.

You can have a extra controller for serializing. A controller can be a delegate or an action-target, but need not to be one. A controller is simple an instance of a (possibly custom) class that controls the control flow.

Since the model is serialized, not the views, it is without any relevance, which view displays which information.

Still in accordance to the question above. Is my way of serializing it correct? The model gets the data from the net and make them into a dictionary which will be passed to the controller via its delegate. And then the dictionary will be used to populate the table views.

The controller gets the data from the net, stores it in the model and updates the views, if they cannot do that automatically.