Is it okay to subclass a view controller?

Question

I'm a relative Objective-C noob, so please bear with me. The Apple documentation states that it is not a good idea to have two view controllers controlling a single view.

I am building a game which takes place within a single view. I want to create objects that can add themselves to the main view (as sub-views). Is it okay to create these objects as view controller subclasses, or do i have to create the objects as subclasses of NSObject and handle all the view and subview stuff from the view controller? This is what I am attempting to do right now, but it is turning into a structural mess...

Answer 1

Your subviews shouldn't be UIViewController's, but rather UIView's.

Answer 2

Yes, you will almost always need to subclass the view controller to handle the specifics of your view. The objects in the view should be UIViews or its subclasses.

Answer 3

You want one subclass of UIViewController to manage the whole screen. That controller's view will probably be a large container for everything that's going on. If you want other controllers, just create subclasses of NSObject for them, and have each of those own its own UIView (which is a subview of the master controller's view)

Don't have multiple subclasses of UIViewController running rampant at the same time. You'll get all sorts of wacky behavior because this is an unsupported setup.

Answer 4

The important part of a game design like this is to make sure you put most of the logic in the data model for the game and not in the view controllers or views. The data model should track where objects are in the game space, what logical attributes and visual attributes they should have and whether they interact with other game objects.

The function of the view controller should merely be to translate the logic of each object to the view. The view's sole function should be to dumbly draw whatever the controller tells it to.

For example: Suppose you have a simple game with two balls that bounce off walls or each other. When they collide with another ball they change color. Each ball and each wall would be represented by an individual object in the data model. Each object would be responsible for modeling the state of the ball/wall at any given time and determining its position and whether it collided or not.

In other words, the data model should handle everything about the game except the actual display. In principle, the data model should be wholly independent of any particular display. You should be able to play the game on a standard view, a webview or even a command line.

The role of the view controller is translate the logical position and logical state of game object into a subview on the game screen. E.g. using a UIImageView to display an image of a ball. The view controller simply tells the view to draw a ball at a certain location on the screen using a certain graphic. That's it. As the data model changes, the view controller changes what is drawn but it doesn't remember what it drew the last time or what and where it draw anything next. It simply reflex the data model.

To handle user input, it reverse the process converting UI changes to inputs to the data model. However, the view controller does not calculate the results or consequences of those inputs. That is the job of the data model.

By putting all the complex logic of the game in the data model you make it easy to change the view-controller/view pairs and to add, remove or modify many different views. For example, you might have the same game on iPhone, iPad and Mac. Most of the code would be the same on all three platforms but each would have custom view-controller/view pairs.

Model-View-Controller is very important and grows more important as the complexity of the app increases. It is very easy to cram to much data and logic in the controllers or views which overloads them and creates tangles of interrelationships when you try to extend the app. Write the data model first. Make the data model able to play the entire game with just text inputs. Then and only then, attach the graphical interface. If you follow this pattern, writing the graphical elements will prove very simple and be very flexible.

Answer 5

I'm going to imagine that you're writing a Pacman game, and your goal is to use the main view as the maze and these subviews to represent your game characters.

One way to represent this mix is to use one view controller (subclassed from UIViewController) to control all views. This is perfectly legal. So your one view controller is responsible for your main view(maze), and subviews (characters).

I would suggest however that you use Core Animation for this case, and treat everything as layers. In this way, you only have one view backing all of the layers, and use one controller responsible for managing character positions and user input. It should simplify your life greatly.