iOS Communications between MVC?

[ArtOfWarfare]

I've started making a new game. The game has 3 classes so far:
- An app delegate, which doesn't do much.
- A view, responsible for drawing everything in the game and receiving touch events.
- A controller, responsible for processing the touch events and determining what needs to be drawn.

First question: are the responsibilities properly distributed between the two objects right now?

Second question: how should the view and controller communicate with each other? The view needs to be able to pass touch events to the controller, while the controller needs to pass what needs to be drawn to the view. Suggestions?

Edit:

After spending the better part of my Sunday, I appear to have found the answer to the second question.

Controllers are allowed to communicate directly with views. Views should use target/action to communicate with controllers. Or delegation.

 

[larswik]

ArtOfWarfare - I had a similar question, kind of. After making a few apps for myself I started to ask myself if I was doing them correctly with the MVC design. My very first app I even made for the OS X I pretty much had just 1 class and wrote all the code in that class and using the [self someMethod]; to send a message to it. Some one here pointed it out and I wasn't taking advantage of the object oriented programming basically.

Even now when I write an app I create a new file like a ViewController. In the .m file I write all my code and import data from my plists that I pass from ViewController to ViewController via plists.

I started wondering if I was really grasping the MVC design? When creating a new ViewController Class I get a View with an xib and I get a Controller. I am wondering if I should also be creating another Class that inherits from NSObject that I use as the Model which deals with all the data and the loading and saving of plists and any core data stuff I would use.

I know it is a little different then your question but still dealing with the MVC design. Next semester I take an iphone class, so everything I learn now is still from a book or this forum.

I'm just wondering your thoughts on it?

Thanks!

 

[chown33]

The M in MVC stands for Model. Where's the Model class or classes?

 

[ArtOfWarfare]

The M in MVC stands for Model. Where's the Model class or classes?

Thus far I haven't seen a need to make one... what exactly would it be responsible for doing?

(My Controller class does have some physics calculations in it... like, it calculates the angles that things should bounce off of each other after collisions... should that go in the model?)

 

[larswik]

Hi Chown33 - That is the heart of my question, the Model. Right now as I create a new View I go to FILE / NEW FILE and select the preset "UIViewController subclass" This gets me my View and Controller. In the list to the left, after I label it I get MyViewController.h and myViewController.m.

This is where I feel like I am doing it wrong still and learning the wrong way. Everything in this new Class, Methods and so I write in the .m file. My viewDidLoad I have code written like [Self MethodOneSomething]; [Self MethodTwoSomething];

In this myViewContrioller.m I will process all my data from loading plists to saving plists, which I use a lot to move data to another View.

I began to question if I am truly learning Object programming the correct way when I was copying and pasting the same Methods in to many views, to handle the same data. I don't think I was grasping the Model part of MVC design. But... My apps work just fine even though I process data the way I do, so how could it be wrong if it works I thought?

For a couple of weeks now I kept thinking I was doing it wrong. I then thought, would it not be better to create a new Objective C Class that was not a viewController to handle the data. I could then have that separate Class handle the interaction with the data, load and save plists. All I would have to do then is instantiate that object in my viewController and pass all the data to it to process. This way I can instantiate the same object in different Views to access my data instead of copy pasting my Methods and processing data in my UIViewController Class. Also hand off data to this new Class to process and return the results.

This seems a much sleeker approach and feel I might be getting an idea of the Model in MVC, maybe?

 

[ppilone]

If you're doing a lot of plist loading and accessing this would be a great time for a model wrapper class. Keeping this code in a separate model class makes it easier to re-use in multiple view controllers and easier to test (it's significantly easier to unit test a model than a view controller).

Think of it this way:

What if tomorrow you decided to write a Mac version of your app? You wouldn't be able to re-use any view controllers (since there is no UIViewController in AppKit) but all of your data (plists) could be shared. If you're writing all of the loading and parsing code of those plists in your view controllers you'll have to re-write the same code in the Mac version of your app.

 

[larswik]

After all of this coding I have been doing for 6 months I am starting to see how to use the Model now. I knew things should be reusable and all the coping and pasting of identical code began to feel wrong.

The think that through me off was all the code worked fine writing it in the ViewController. But all the excess redundant code I was using felt wrong. I think I am finally getting the Model part of MVC and how it works to my advantage. Now to break the habit of of writing all that code in the ViewController.

Thanks!