Question

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.]

Answer 1

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.