Setting Up a MVC most of it works BUT

  • So I've spent the past few hours reading and am now trying to set up a simple MVC.

    I constructed a few buttons and textfields in a Window in IB
    The View will instantiate when the Xib is loaded (so I've read anyway)

    I created a MyController based on NSObject in the Xib SO once the Xib is loaded MyController is instantiated.
    NSLOGs indicate this is so.

    I connected the UI elements to MyController.

    NOW as MyController inits I have it THEN instantiate myDataModel object.
    NSLOGs indicate myDataModel comes up.

    The UI elements in Window capture data correctly.
    The save button retrieves the data from the Window and MyController sends the data to myDataModel.
    NSLOGs indicate that is working as expected.

    All that appears to be working.

    BUT how does one send data from myDataModel to MyController.
    OR is that by request from MyController only?

    I tried to send MyController's ID during MyDataModel initialization.
    That works NSLOGs indicate MyDataModel receives MyController's ID.

    When I have MyController call a method in MyDataModel and attempt to call a method in MyController
    I get an error during compile "! No Visible @interface for NSObject ...."

    I have MyDataModel do the [super init] initialization.
    At the moment I'm baffled -
    Any advise would be appreciated.

    Probably have taken the wrong tack - I tend to do that.

    YT
  • On 10/05/2013, at 10:35 AM, YT <yt...> wrote:

    > BUT how does one send data from myDataModel to MyController.
    > OR is that by request from MyController only?

    It can be, but not exclusively. Sometimes your data model might want to "push" a value to the interface for display. It all depends on what it does.

    > I tried to send MyController's ID during MyDataModel initialization.
    > That works NSLOGs indicate MyDataModel receives MyController's ID.
    >
    > When I have MyController call a method in MyDataModel and attempt to call a method in MyController
    > I get an error during compile "! No Visible @interface for NSObject ...."
    >
    > I have MyDataModel do the [super init] initialization.
    > At the moment I'm baffled -
    > Any advise would be appreciated.

    -init is too soon. The interface is loaded after initialization, which is why it isn't available then. Instead, override the -awakeFromNib method and do the necessary stuff there. That is called after the interface is loaded, and is provided for this purpose. It is guaranteed to be called only once all of the interface is available.

    --Graham
  • On 10/05/2013, at 10:35 AM, YT <yt...> wrote:

    > BUT how does one send data from myDataModel to MyController.
    > OR is that by request from MyController only?

    Just to elaborate on my previous answer, there are several techniques that are commonly used to update an interface when something in the data model changes. These are, in order of complexity/understandability/history:

    a) the data model explicitly calls a method of the controller to tell it about a change. This isn't great, because it sets up a strong dependency between the data model classes and the controller class(es).

    a+) the data model declares an informal or formal protocol that some designated object (called a delegate, and this could be your controller) can implement. The data model calls these delegate methods for certain specific activities. This is really just a more elaborate form of a), which is why I call it a+, though with care it can be more generic and anonymous, and therefore can have better decoupling than a.

    b) the data model uses the notification center to notify changes, and the controller listens for these notifications.

    c) the controller uses key-value observing (KVO) to monitor property changes of the model directly.

    d) Bindings, which are built on KVO.

    Searching the documentation with these terms should yield the relevant information.

    --Graham
  • On May 9, 2013, at 6:57 PM, Graham Cox <graham.cox...> wrote:

    > a) the data model explicitly calls a method of the controller to tell it about a change. This isn't great, because it sets up a strong dependency between the data model classes and the controller class(es).
    > a+) the data model declares an informal or formal protocol that some designated object (called a delegate, and this could be your controller) can implement. The data model calls these delegate methods for certain specific activities. This is really just a more elaborate form of a), which is why I call it a+, though with care it can be more generic and anonymous, and therefore can have better decoupling than a.

    Delegation is the tool I reach for most often for this type of communication. It avoids tight dependencies because the model doesn’t know about the controller, it just specifies what messages its delegate should understand. I find this style conveys a lot of information to someone reading the code, because it formalizes the “outgoing” API of the model class, and also makes it very clear what the parameters and their types are.

    This pattern is used all over Cocoa, especially in UIKit and AppKit, so there are tons of examples in the system headers. (For example, look at NSURLConnectionDelegate.) One gotcha to be aware of is that the reference from the model object to its delegate should be weak, i.e. unretained, to avoid setting up reference cycles.

    The drawback is that it’s a to-one relationship: a model object can have only one delegate, unless you put some work into supporting a collection of them. Generally, once you have a need for multiple observers to know about changes to one object, you reach for the NSNotification or KVO hammers instead.

    —Jens
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today