Take the 2-minute tour ×

Is it good practice to hive off complicated tasks that manage or determine the information displayed in the view of a UIViewController and are not really concerned with the loading of the subviews and their layout to a "UIViewController delegate" as it were?

[Perhaps an example might be a game delegate and a full-screen game view controller (whose view is created programmatically say). The app delegate might know about the game delegate which knows about the game view controller.]

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

What you describe is essentially baked into the MVC design pattern, which is already heavily used on iOS.

Consider an app that visualizes network traffic. You might have a view that renders a continually updating graph, once every N milliseconds. The underlying calculations that determine the plot of the graph may be complicated and happen hundreds of times a second, whereas you may only want to update the UI 30 times a second.

Given this hypothetical app, you might put all of the code that monitors the raw network traffic and performs the calculations in a Model class. Then, depending on what variant of MVC you're using, you would either have the View observe changes to the Model directly (perhaps using KVO), or you'd have your Controller observing the Model and then directly triggering an update to the View with a new state.

share|improve this answer
I do get this in abstract but in practice I tend to end up phrasing this differently. As I understand and in the language of my question, the "M" of "MVC" would be the game delegate, the "V" would "the game display" and the "C" of "MVC" would the view controller mediating between the game delegate and the game view. So for instance, in general is it easier for someone else to understand my code if I declare a "GameModel" class in my view controller header rather than a "GameDelegate" so to speak? The difference is semantic but important. –  SK9 Dec 6 '10 at 9:27
Yes, the semantic differences are quite important here, mainly because (to me) you're mixing the MVC pattern terminology with the Delegate pattern and so I'm not exactly clear on your question any more. Let me pick out the last bit. If you had a GameDelegate class, that implies usage of the Delegate pattern, and the existance of a Game object that defers some of its behaviour to it. I don't think this is what you're intending. Think of the UITableView and its delegates, like UITableViewDataSource, which the table view uses to configure itself. –  Shaggy Frog Dec 6 '10 at 9:32
Right, that's a good example. My GameDelegate is really serving as a data source for the GameView. For instance I should bind the text for the game score label to an element of a data source. As you might have guessed I'm doing everything programmatically. I should look at IB again for the keywords. –  SK9 Dec 6 '10 at 10:21
add comment

Your Answer


