I need a little MVC Clarification

Discussion in 'iOS Programming' started by larswik, Sep 22, 2011.

  1. larswik macrumors 68000

    Joined:
    Sep 8, 2006
    #1
    I read about the MVC and looked at a couple tutorials. When I start a new iPhone project and make it WindowBased and call the project Basic. I get the BasicAppDelegate.h, BasicAppDelegate.m and a MainWindow.xib

    So in this example the MainWindow.xib would be my V in MVC for my view. I then create a new Class a UIViewControllerSubClass and call it lets say FirstPage. So now I just created FirstPage.h, FirstPage.m and FirstPage.xib

    Now FirstPage would act as my AppController? Or maybe a better name would be FirstPageAppController. So this this would be the C in MVC since it is my Controller.

    Now I get lost with the M in MVC. What I read and have seen says that the Model and the View never talk to each other directly but they talk to the controller. But most sample I have see people write code in the AppController and the View talks to that Controller? So there is no M in MVC? just a VC.l or is my AppDelegate my Controller?

    In this YouTube Video from Standford University, he is writing all the code in the AppDelegate http://www.youtube.com/watch?v=ZKOgBuELA8E&feature=relmfu and using the MainMenu.xib to add sliders, buttons and so on? I am confused?
     
  2. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #2
    Well, the question is how are you storing and manipulating whatever data the application works with? Maybe you have separate classes for that, in which case those would be your model. Maybe all you need is a plain NSArray, in which case you could just deal with it directly in your controller class and the array would be your model. AppDelegate and what you call "FirstPageAppController" (whose name should really be FirstPageViewController) both probably act mostly as controllers.
     
  3. larswik thread starter macrumors 68000

    Joined:
    Sep 8, 2006
    #3
    I kind of get it. So there is no set rule as to where the code should be written. I could write the code in my Controller or the AppDelegate if it is simple? But everything starts in the AppDelegate, right? I can then push / addSubView the UIImageView on top of the MainMenu.xib like this code

    Code:
    UIImageView *openingView = [[[UIImageView alloc] initWithFrame:CGRectMake(0.0f, 0.0f, 320.0f, 480.0f) ]autorelease]; //create imageview to screen size
    openingView.backgroundColor = [UIColor grayColor]; //sets the back ground color
    [_window addSubview: openingView]; //adds the view to the window
    
    [self.window makeKeyAndVisible];
    return YES;
    
    
    This I programmaticly wrote and pushed / added as a subView ontop of the MainMenu.xib, correct?

    If I choose to go to FILE NEW and create a new UIViewControllerSubClass I would then need to go back to my AppDelegate and tell it to add my new ViewController.xib as the subview to add as the first thing I see when my app launches.

    I think I am getting it.
     
  4. North Bronson macrumors 6502

    Joined:
    Oct 31, 2007
    Location:
    San José
    #4
    Try to think of your controllers as engines that take a block of data and use that to create a view that the user can see and edit. The controller should be a self-contained engine that is smart enough to take the data and go.

    If your parent view controller creates a child controller, the parent should give that child the knowledge it needs to go out and do its job, but the child has to be prepared to use that knowledge for itself. The parent should not be too directly involved with how the child uses that knowledge. Make sense?

    Suppose that you want to build a calculator. Create three classes:

    CalculatorController (UIViewController subclass)
    CalculatorModel (NSObject subclass)
    CalculatorView (UIView subclass)

    Your CalculatorController holds an instance of a CalculatorModel.

    Your CalculatorModel holds instance variables like NSArrays, NSStrings, and NSNumbers that you want to keep around.

    Your CalculatorController has a view property that returns a UIView. Override this property to return a CalculatorView. This will be the root view in your hierarchy.

    Your CalculatorView holds instance variables like UIButtons and UILabels.

    Why not give your CalculatorController instance variables pointing directly to NSStrings and NSArrays? Why not give your CalculatorController instance variables pointing directly to UIButtons and UILabels?

    By creating discreet objects around your models and your views, you can start to feel for why these separations become important. Your objects become more reusable. It will also reinforce these design patterns and help to encourage cleaner software.
     
  5. jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #5
    Good MVC separation is resilient to having one the layers being replaced.

    Examples:

    Do your controllers still work without any changes if you replace a model backed by an in-memory array with a model backed by an SQLite database?

    Can you reuse your model from an iOS app in a Mac Cocoa app without change?

    Can you change your ux design from a list view to a table view with minimal impact on the controller layer and zero impact on the model layer?
     
  6. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #6
    When you're starting out, you should generally figure that everything that goes on one screen of the app will be managed by one UIViewController subclass. You don't want to add random UIViews to the window, partly because the code would be a mess, but mostly because creating a proper view controller hierarchy gives you all sorts of useful functionality.
     
  7. larswik thread starter macrumors 68000

    Joined:
    Sep 8, 2006
    #7
    I see what you guys are saying. I think this will be a good weekend project to understand this better. I included my project here to better demonstrate what I am talking about. Jim pointed out the other night about my badly named 'makeNewLine' Class.

    I would say that my makeNewLine class could be stand alone and integrated into other projects and it is a sub class of NSObject. When you run the app it creates a bunch of rows on UITextFields, but this code I wrote it all in the AppDelegate.m. I should have a ViewController sub class that I write all this code in.

    So makeNewLine (which is not upper case (sorry) and named poorly) is my Model for creating the rows. I should move the code where I instantiate this object out of the AppDelegate and into a ViewController that I should create and use the ViewControllers.xib

    Now I have a Model, a ViewController and the View.

    Thanks again guys for your help. Somethings I get right away and other things take me asking the same question in different ways to get it.
     

    Attached Files:

  8. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #8
    makeNewLine has nothing to do with your model. It's basically just some helper code for creating UITextFields. It might as well go in a view controller or be done some other way in Interface Builder. In order to figure out what your model really is, you need to figure out what kind of data your application will be working with. It sounds like this is some kind of personal finance app, so the model might include some classes that represent expenses or budgets, or whatever people are supposed to type in those text fields. Right now you have no model.
     
  9. larswik thread starter macrumors 68000

    Joined:
    Sep 8, 2006
    #9
    Ok, I will keep reading and looking over tutorials till this sinks in. So far it seems that you have the View that users interact with and then the ViewController where I write all my code that receives messages and information from the view. The ViewController precesses the code and returns it to the viewer. Then if you need to you can have other Classes interact with the ViewController, in my case I created UITextFields. There will be a button that creates a new row of UITextFields so it slowly populates row by row as the user needs them.

    Thanks for your help
     
  10. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #10
    The UITextFields are just part of your view. How you create them doesn't really matter. At some point you will probably have some code that reads what is in those text fields. That will be part of your controller. This code will probably take the values from the text fields and store them in some variables and/or additional classes. That will be your model.
     
  11. larswik, Sep 23, 2011
    Last edited by a moderator: Sep 24, 2011

    larswik thread starter macrumors 68000

    Joined:
    Sep 8, 2006
    #11
    --- Click, the light bulb turned on with that statement. I can see the model right now and how it is evolving. I got the different views working now. I was so focused on the AppDelegate section and doing the code in there. I have my AppViewController doing the work now and calling other ViewControllers.

    I am in a little trouble right now since the UITextFields. Since I grammatically created them I am trying to release the first responder. When I try it crashed with the BAD_ACCESS. They are not being retained after they are created. I want to try and figure this out myself, I will ask for assistance if I really need it

    Thank you!
     

Share This Page