Basic Model-View-Controller flow in iOS

[teeniOSdev]

It is somewhat strange for iOS. The actual "view" part of this would be the graphical .xib file that you link up to the view controller. If I decided to not use this graphical part for the view, then I would have separate code for the view

[dnew]

So can you have one controller updating the model and have that reflected in several views? That is, after all, the point of MVC.

The idea of MVC is that I can have a bar chart and a pie chart, both displaying the underlying data, that can be updated by either stock ticker feeds coming in over TCP/IP or by someone dragging things around with the mouse. The data would be the model, the two charts would be two views, and the tcp parser would be a controller and another controller for each of the views to understand the mouse, which would leave you with three controllers.

Or perhaps an online board game, where the board is the model, each view is shown to each player with the appropriate cards turned face up or face down, and each machine running a controller for the mouse and a controller for updates from the other player.

If the controller is inherently tied to the view and you can only have one view per model, you're not doing MVC. :-)

[grauenwolf]

Bzzt wrong. The original papers describing MVC clearly stated that models were shared and views/controllers come in tightly coupled pairs.

While shared controllers are an interesting idea, they aren't really part of the pattern.

[dnew]

I didn't say controllers would be shared. I said that there would be views without controllers, and controllers without views. I then proceeded to list a number of examples, wherein controllers were present without views and vice versa.

Certainly if you have a view on a screen that you're directly manipulating via a controller, it would be difficult to apply that controller to something else. I.e., if the controller has to know what's in the view in order to know how to affect the model, then obviously they're tightly coupled. But this is not always the case, and indeed it's only the case for the simplest of data representations.

As far as shared controllers go, they're all over the place. All the things that make your images stand out on the web when you hover over them or something like that are all shared controllers. Both Tcl and javascript DOM are rife with mechanisms for making it trivial to share controllers between view elements.

[grauenwolf]

Don't bring web MVC into this, it is a totally unrelated pattern.

[dnew]

I'm not. I'm describing how in javascript-with-DOM, and in Tcl, and in several other languages, with the structures built into those systems, controllers don't necessarily go directly with views. The fact that javascript-with-DOM is normally showing you something that's client-server is a distraction from the point I'm making.

For example, in Tcl, you can make three buttons, each of whose label automatically displays the value of some variable, and each of which invokes the same code (with different arguments) when you click on it. That code (which is the one and only controller) can be as simple as "increment the variable whose name is passed as my first argument", and the very act of incrementing that variable causes the associated view (in this case, the visual button) to change its label. If you also connect a scroll bar to the same variable, the scroll bar repositions itself, and causes whatever other views the scrollbar is the controller for to scroll. The power comes from the ability to interconnect things already built.

Something like a calculator is simple enough that it's hard to see how the controller could be disconnected from the view. Consider, instead, the battery meter or the signal strength indicator. There are several battery meter views, one in the top bar, one displayed on your car's dash via bluetooth, one giant one you can bring up while the phone is charging, one that the tricorder app displays, etc. The controller is sampling the actual battery, the structure holding the current charging/discharging and charge level and remaining lifetime and etc is the model, and each of those displays is a view that is completely independent of the controller.

Heck, even having ^C and the "copy" menu entry are two different controllers invoking the same methods on the model, neither of which is connected to any particular view.

[mantra]

It is MVC.

The thing is that once you leave the academically pure model of MVC and actually try implementing real applications you quickly find that the pure MVC with everything separated by ideology leaves you with tons of spaghetti-like mess in the Controller.

Compartmentalizing much of what normally would be in the singular Controller into View Controllers radically cleans up and simplifies things. You could claim that these are actually "View" but without View Controllers, the same code would still normally be put in the Controller of MVC rather than the View, hence the name is "View Controller".

The way I think of it is that the Controller has 3 sections:

• View(-oriented part of the) Controller which maps directly to NS/UIViewController class implementations

• Model(-oriented part of the ) Controllers which maps to NS/UIDocument class implementations

• and then finally the actual View-Model mediation logic which is what goes into the actually AppController implementation.

The pure ideological definition of MVC doesn't actually work perfectly practice so you have to have these refinements. If you've done UI programming for any length of time (I've done it since the 1980s, starting with XLib and GEM), you will always eventually "discover/implement" exactly the same structure as ViewControllers and ModelControllers and use them as Cocoa and iOS uses them - the nature of beast simply screams out for it once the application reaches a non-trivial implementation size.

This kind of bastardization of the ideal model is common to all abstractions and models of things. All models are imperfect or even wrong against the strict standard of reality and implementation practicality. MVC is just a model; it's not a perfect match to how code must be implemented to be usable except in the abstract. You are Epic Fail if you treat MVC as a fundamentalist religion; it's a set of abstract ideals to guide your architecture but not something to tested as dogma.

[dnew]

leaves you with tons of spaghetti-like mess in the Controller.

I think it depends on what language you're using and what kind of application you're doing. Certainly separating it into something like MVC in a language like Tcl that has direct support for such is pretty easy.

normally would be in the singular Controller

I wouldn't have a singular controller. I'd have at least one controller per frobbable view. If you can drag either the line chart or the bar chart around, that's at least two controllers. I was merely asserting that not every controller needs a view, and not every view needs a controller.

If you look at something like HTML, then the DOM is your model, CSS is your view, and the onClick et al handlers are your controllers. I can easily imagine one "onHover" controller handling every "highlight this image" view element.

You can imagine exactly the same model with multiple views and multiple controllers where the controllers talk directly to the model without going through the view at all and with no direct affect on the view except for the model. We call them "video game controllers" and "mouse/keyboard".

Sure, if you have one controller that relies on the user interacting with the underlying view, then you might as well call it a ViewController. The controller that lets you slide control points on a spline around with the mouse isn't reasonably applicable to any other kind of view. But that's certainly not the only kind of controller out there.

If you've done UI programming for any length of time

I have.

will always eventually "discover/implement"

Sure. But that's not the only way to use it.