James Raitsev
James Raitsev

Reputation: 96421

On View and ViewController's responsibility and communication

I am working on a card game iPhone app and have a question about both method of communication and responsibility of various components.

In my application, the ViewController in it's viewWillAppear, creates instance of the View class and initializes it. ViewController creates the view and points strongly to it.

[self setGameView:[[GameView alloc] initWithFrame:CGRectMake(0, 0, 480, 300)]];

Inside the GameView, i lay out cards on the view and make sure they can be moved according to some rules.

A few questions:

Given that some cards can "beat" other cards, should View or View Controller be in charge of this decision? For instance, at this point, any card can be placed on top of any card, as long as they are in the same region, however, sometimes, cards should snap back and other times program should recognize that card has beaten another card.

In this event, should View notify the its Controller that "card A is placed on top of card B - go figure out if A actually beats B". If Controller decides that A can't beat B, Controller should instruct it's view to snap A back to stack, where as if A indeed has beaten B, it should remain where it is and some other things should happen?

How should communication happen here?

I am thinking that in it's - viewWillAppear method, ViewController should subscribe to NSNotificationCenter asking to be made aware the next time card is placed on top of another card. Since View is owned by ViewController it has access to all of it's public interface methods and can figure out from there what card is in what place and why.

Is NSNotification a good way to handle this, or is there a better way to do it?

As you can see from my question, i am a bit confused here. Please help clarify this for me.

Upvotes: 0

Views: 207

Answers (1)

Peter M
Peter M

Reputation: 7493

To start with, I'd say that neither the View or the ViewController are in charge of how cards behave. That should be the realm of the Model. Take a read of Model View Controller core competencies. Also take a look at Communicating with Objects

The View should feed user actions to the Model, and the the Model should tell the View how to react.

As to actual implementation of passing information around, NSNotifcations are a valid choice. However there are other choices such as creating custom protocols Protocols are another way of doing things. They require defining a delegate object that fulfills the messages supported by the protocol.

If you were going to use NSNotifications, I would structure it like:

On initialization the Model subscribes to "User Change" events

On the View's loadView(), the View subscribes to "Card change" events

On the View's viewWillAppear() method, the View sends and "update request" (as an overall "User change") to the Model, which replies with a sequence of "Card changes" that layout the card on the screen, which the View receives and then dutifully displays the cards

During game play the user interface sends "User change" events, to which the Model responds with more "Card change" events

This structure separates the View and Model and hence makes things cleaner to code and to debug. The ViewController is then left to do View Controller things like displaying other View Controllers that might show hi score histories etc.

Doing the above with Protocols would require creating "User Change" and "Card Change" protocols, with the Model implementing the "User Change" protocol and the View implementing the "Card Change" protocol. The Model would then have the View as its delegate and the View would have the Model as its delegate.

Upvotes: 1

Related Questions