MVC model. Should the access control controller directly control?

Question

I study the material for iOS development, and what I found in textbooks and books is that at the controller level, there is usually access to View controls directly (text fields, labels, etc.). Consider this example:

Suppose the View has a label called lblResult and a text field called txtDataToAnalyze . In the management interface, we have something like this:

 @property (nonatomic, retain) IBOutlet UILabel* lblResult; @property (nonatomic, retain) IBOutlet UITextField* txtDataToAnalyze; 

and some @synthesize in the implementation file.

I have some JavaSwing development experience where most of them think that I write manually without any graphical constructors, and what I usually do in MVC is access to View controls via getters / setter. For example: void setResult(String resString); or String getDataToAnalyze(); . Thus, the controller only knows which pieces of information are displayed in the view, and not how they are displayed. I think it is more flexible (it is easier to change the view layer later).

I know that iOS has some specific rules, introduced XIB / NIB files, etc., so maybe my doubts are completely useless in the case of the development of iPhone / iPad. But I'm going to write another serious iOS app (actually “rewrite” it from Java Swing), and so I would like to ask you:

What do you think, I should change what I think and get used to this new (for me) approach (xib files, creating a graphical interface using drag & drop and providing the controller with information on how the data should be displayed in the field of view ) ?? Have you had similar doubts when starting with iOS?

Answer 1

Short answer:

Yes, I think you should spend some time getting used to working with Interface Builder (IB) to create NIBs and storyboards and let IB create IBOutlet and IBAction links for you for the controls you need to interact with. Once you master this, you will be impressed with your productivity when creating code with ease of support. Do not dissolve IB too quickly.

From the point of view that the controller interacts directly with IBOutlet and IBAction links, this is common practice for simple user interfaces. If you have examples of the real world, send a new question with a snapshot of the screen, and we can offer more practical recommendations.

Long answer:

• Part of your question is apparently due to concern when viewing view controllers that perform detailed interactions with view controls. The fact is that if you want to isolate your controller from some details of the implementation of a view, then go and subclass the view and put specific material in it. IB can interact with subclasses of both view controllers, as well as view subclasses. Thus, you can happily use IB and still isolate your view controller from some of these implementation details.

  Personally, I do this by subclassing UIView when the view falls on some threshold of subjective complexity (for example, for me this threshold is when I find myself complex animation, for example, using CADisplayLink , complex gesture recognizers, etc.). I will also subclass those subviews that are logical entities (e.g. UITableViewCell or UICollectionViewCell ). But for simple views, where I interact with my model with setting the properties of the control, interacting with text fields, etc., I think this is great. Having said that, if I have a lot of code for viewing in the controller that has nothing to do with integrating my model with my view, start a subclass of UIView and move only view code into it.

• Your question refers to the concept of software building, not the use of NIBs / storyboards. In my opinion, using the Builder (IB) interface to create a user interface is much easier to develop and maintain. Perhaps there is some pedagogical value for the implementation of the test project, where you create your views programmatically, so you really understand what is happening, but after that I think that you will quickly find yourself in storyboards. And you will have a lot of chances to write your own code, different from IB, when you start to do something other than the capabilities of standard IB controls (for example, complex user-friendly representations of containers, etc.). Of course, there are those who prefer to develop views programmatically, but I do not think that you can defeat the speed of development and ease of maintenance of user interfaces created by IB.

Answer 2

In general, the controller does not know about the view, but the view knows about the controller.

A gang of four books says:

“MVC also allows you to change the way you respond to user input without changing its visual presentation. You may want to change the way you respond to the keyboard, for example, or use the pop-up menu instead of MVC to encapsulate the response mechanism in the Controller object. There is a hierarchy of controller classes that makes creating a new controller as a variation of an existing one.

The view uses an instance of the Controller subclass to implement a specific response strategy; to implement a different strategy, simply replace the instance with another controller. It is also possible to change the view controller at run time to change the view in the way it responds to user input. For example, a view can be turned off so that it does not accept input, just passing it a controller that ignores input events.

The View-Controller relationship is an example of a Strategy design pattern (315). A strategy is an object that is an algorithm. This is useful when you want to replace the algorithm both statically and dynamically, when you have many variations of the algorithm, or when the algorithm has complex data structures that you want to encapsulate. "